大型网站架构阅读(九)网站故障案例分析

浅浅的花香味﹌ 2024-02-19 13:52 46阅读 0赞

**1.写日志也会引发故障**  
  
故障现象:

某应用服务器集群发布后不久就出现多台服务器相继报警,硬盘可用空间低于警戒值,并且很快有服务器宕机。登录到线上服务器,发现log文件夹里的文件迅速增加,不断消耗磁盘空间。

原因分析:

这是一个普通的应用服务器集群,不需要存储数据,因此服务器里配置 的是一块100GB的小硬盘,安装完操作系统、Web服务器、Java虚拟机、应用程序后,空闲空间只有几十GB了,正常情况下这些磁盘空间足够了,但是该应用的开发人员将log输出的 level全局配置为 Debug。这样一次简单的Web请求就会产生大量的log文件输出,在高并发的用户请求下,很快就消耗完不多的磁盘空间。

经验教训

应用程序自己的日志输出配置和第三方组件日志输出要分别配置。●检查log配置文件,日志输出级别至少为wam,并且检査log输出代码调用,调用级别要符合其真实日志级别。有些开源的第三方组件也会不恰当地输出太多的Eror日志,需要关闭这些第三方库的日志输出,至于哪些第三方库有问题,只有在遇到问题时才知道。

**2.高并发访问数据库引发的故障：**  
  
故障现象:

某应用发布后,数据库Load居高不下,远超过正常水平,持续报警。

原因分析:

检查数据库,发现报警是因为某条SQL引起的,这条SQL是一条简单的有索引的数据查询,不应该引发报警。继续检査,发现这条SQL执行频率非常高,远远超过正常水平。追査这条SQL,发现被网站首页应用调用,首页是被访问最频繁的网页这条SOL被首页调用,也就被频繁执行了。

经验教训：

首页不应该访问数据库,首页需要的数据可以从缓存服务器或者搜索引擎服务器获取。

首页最好是静态的。

**3.高并发情况下锁引起的故障：**  
  
故障现象:

某应用服务器不定时地因为响应超时而报警,但是很快又超时解除,恢复正常,如此反复,让运维人员非常苦恼。

原因分析:

程序中某个单例对象( singleton object)中多处使用了 synchronized(this,由于this对象只有一个,所有的并发请求都要排队获得这唯一的一把锁。一般情况下,都是一些简单操作,获得锁,迅速完成操作,释放锁,不会引起线程排队。但是某个需要远程调用的操作也被加了 synchronized(this),这个操作只是偶尔会被执行,但是每次执行都需要较长的时间才能完成,这段时间锁被占用,所有的用户线程都要等待,响应超时,这个操作执行完后释放锁,其他线程迅速执行,超时解除。

经验教训:

使用锁操作要谨慎。

**4.缓存引起的故障：**  
  
故障现象:

没有新应用发布,但是数据库服务器突然Load飙升,并很快失去响应。DBA将数据库访问切换到备机,Load也很快飙升,并失去响应。最终引发网站全部瘫痪。

原因分析:

缓存服务器在网站服务器集群中的地位一直比较低,服务器配置和管理级别都比其他服务器要低一些。人们都认为缓存是改善性能的手段,丢失一些缓存也没什么问题,有时候关闭一两台缓存服务器也确实对应用没有明显影响,所以长期疏于管理缓存服务器。结果这次一个缺乏经验的工程师关闭了缓存服务器集群中全部的十几台Memcached服务器,导致了网站全部瘫痪的重大事故  
经验教训:  
当缓存已经不仅仅是改善性能,而是成为网站架构不可或缺的一部分时,对缓存的管理就需要提高到和其他服务器一样的级别。

**5.应用启动不同步引起故障：**  
  
故障现象:

某应用发布后,服务器立即崩溃。

原因分析:

应用程序Web环境使用 Apache+ JBoss I的模式,用户请求通过 Apache转发 JBoss。在发布时, Apache和 JBoss同时启动,由于 JBoss启动时需要加载很多应用并初始化,花费时间较长,结果 JBoss还没有完全启动, Apache就已经启动完毕开始接收用户请求,大量请求阻塞在JBos进程中,最终导致 JBoss崩溃。除了这种 Apache和 JBoss启动不同步的情况,网站还有很多类似的场景,都需要后台服务准备好,前台应用才能启动,否则就会导致故障。这种情况被内部人戏称作“姑娘们还没穿好衣服,老鸨就开门迎客了”。

经验教训:

老鸨开门前要检査下姑娘们是否穿好了衣服。就本例来说,在应用程序中加入个特定的动态页面(比如只返回OK两个字母),启动脚本先启动 JBoss,然后在脚本中不断用curl命令访问这个特定页面,直到收到OK,才启动 Apache

**6.大文件读写占磁盘引发的故障：**  
  
故障现象:

某应用主要功能是管理用户图片,接到部分用户投诉,表示上传图片非常慢,原来只需要一两秒,现在需要几十秒,有时等半天结果浏览器显示服务器超时。

原因分析:

图片需要使用存储,最有可能出错的地方是存储服务器。检査存储服务器,发现大部分文件只有几百KB,而有几个文件非常大,有数百兆,读写这些大文件一次需要几十秒,这段时间,磁盘基本被这个文件操作独占,导致其他用户的文件操作缓慢

经验教训:  
·  
存储的使用需要根据不同文件类型和用途进行管理,图片都是小文件,应该使用专用的存储服务器,不能和大文件共用存储。批处理用的大文件可以使用其他类型的分布式文件系统。  
  
**7.滥用生产环境引发的故障**  
  
故障现象:

监控发现某个时段内,某些应用突然变慢,内部网络访问延迟非常厉害。

原因分析:

检查发现,该时段内网卡流量也下降,但是没有找到原因。过了一阵子才知道,原来有工程师在线上生产环境进行性能压力测试,占用了大部分交换机带宽。

经验教训:  
· 访问线上生产环境要规范,不小心就会导致大事故。

网站数据库有专门的DBA维护,如果发现数据库存在错误记录,需要进行数据订正,必须走数据订正流程,申请DBA协助。于是就有工程师为避免麻烦,直接写一段数据库更新操作的代码,悄悄放到生产环境应用服务器上执行,神不知鬼不觉地订正了数据但是如果不小心写错了SQL,后果可想而知。  
  
 **8.不规范的流程引发的故障：**  
  
故障现象:

某应用发布后,数据库Load迅速飙升,超过报警值,回滚发布后报警消除

原因分析:

发现该应用发布后出现大量数据库读操作,而这些数据本来应该从分布式缓存读取。检査缓存,发现数据已经被缓存了。检査代码,发现访问缓存的那行代码被注释掉了。原来工程师在开发的时候,为了测试方便,特意注释掉读取缓存的代码,结果开发完成后忘记把注释去掉,直接提交到代码库被发布到线上环境。

经验教训:  
  
代码提交前使用dif命令进行代码比较,确认没有提交不该提交的代码。

加强 code review,代码在正式提交前必须被至少一个其他工程师做过 code review,并且共同承担因代码引起的故障责任。  
  
**9.不好的编码习惯引发的故障**  
  
故障现象:

某应用更新某功能后,有少量用户投诉无法正常访问该功能,一点击就显示出错信息。

原因分析:

分析这些用户,都是第一次使用该功能,检查代码,发现程序根据历史使用记录构造一个对象,如果该对象为nu,就会导致 NullPoint Exception

经验教训  
·  
程序在处理一个输入的对象时,如果不能明确该对象是否为空,必须做空指针判断。  
·  
程序在调用其他方法时,输入的对象尽量保证不是nul,必要时构造空对象(使用空对象模式)。