大型网站技术架构阅读笔记5
这一次主要阅读了本书的对大型网站典型故障案例的分析以及在架构师中架构师的领导艺术。
一般的故障现象，由于某应用发布后，数据库Load居高不下，远超于正常水平，持续报警。主要的原因分析是，检查数据库，发现报警是因为某条sql引起的，这条是一条简单的有索引的数据查询，不应该引发报警。继续检查，发现这条sql执行频率非常高，远远超过正常水平，追查这条sql，发现被网站应用调用，首页是被访问最频繁的网页，这条sql被首页调用，也就被频繁执行了。经验教训，首页不应该访问数据库，首页需要的数据可以从缓存服务器或者搜索引擎服务器获取。首页最好是静态的。
故障现象：某应用服务器不定时的因为响应超时而报警，但是很快又超时解除，恢复正常，如此反复，让运维人员非常苦恼。原因分析，程序中某个单例对象中多处使用了this，由于this对象只能有一个，所有的并发请求都要排队获得这唯一的一把锁。一般情况下，都是一些简单操作，获得锁，迅速完成操作，释放锁，不会引起线程排队，但是某个 需要远程调用的操作也被加了this，这个操作只是偶尔会被执行，但是每次执行都需要较长的时间才能完成，这段时间锁被占用，所有的用户线程都要等待，响应超时，这个操作执行完成后释放锁，其他线程迅速执行，超时解除。
故障现象：某些应用发布后，服务器立即崩溃，原因分析，应用程序web环境使用的模式，用户请求通过apache转发，在发布时apache和jboss同时启动，由于jboss启动时需要加载很多应用并初始化，花费时间较长，结果jboss还没有完全启动，apache就已经启动完毕开始接受用户请求，大量请求阻塞进程，最终导致崩溃，除了这种以外，网站还有类似的场景，都需要后台服务准备好，前台应用才能启动，否则就会导致故障，这种情况被内部人员，有位软件技术前辈曾经说过，软件设计有两种风格，一种是将软件设计的很复杂，以使其缺陷没那么明显，一种是将软件设计的很简单，以其没有明显的缺陷，就笔者观察，这两种风格的软件工程师都大有人在，只是在互联网公司，后一种更多一些，因为即使是不明显的缺陷在网站的快速发展冲击下，也会很快独显出来，令其作者疲于应对，狼狈不堪，吃一次亏，学一次乖，以后设计软件时就会设计的简单些，如果问题能够很快被发现，要解决也相对容易。
一定要坚信，一群优秀的人做一件他们热爱的事，一定能取得成功，不管过程多么曲折，不管外人看来多么不可思议不靠谱。寻找一个值得共同奋斗的目标，营造一个让大家都能最大限度发挥自我价值的工作氛围。