系统常见故障

# 系统常见故障

一位网站资深架构师曾经说过：在互联网公司呆一年，相当于在传统软件公司呆三年。他的意思大概是在互联网公司一年遇到的问题比传统软件公司三年遇到的问题还多。而且随着网站业务的快速发展，问题也层出不穷，每年遇到的问题都不同。遇到问题，解决问题，经历了这个过程，技术才能升华，人和技术才能融为一体，才知道什么技术是真正有用的，什么技术是花拳绣腿。

大型网站的技术本质都很简单，没有很花哨的东西，掌握起来也不难。大型网站的架构师最有价值的地方不在于他们掌握了多少技术，而在于他们经历过多少故障。每一次故障都会给公司带来难以估计的利益损失，所以培养一个网站架构师的成本不单要看付了他多少薪水，给了他多少股票，还要看为他引起的故障买了多少次单。

这里列举一些网站的典型故障，我们会发现，在高并发和海量数据的情况下，很多一般情况下不是问题的问题都会涌现出来。

# 写日志引发的故障

这个在初次上线的时候是很常见的错误，在线上遇到过多次，尤其在节约资源的情况下多个jar部署到同一台机器上，频繁打日志导致磁盘满了

# 故障现象

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

# 原因分析

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

# 经验教训

应用程序自己的日志输出配置和第三方组件日志输出要分别配置。
检查log配置文件，日志输出级别至少为Warn，并且检查log输出代码调用，调用级别要符合其真实日志级别。
有些开源的第三方组件也会不恰当地输出太多的Error日志，需要关闭这些第三方库的日志输出，至于哪些第三方库有问题，只有在遇到问题时才知道。
不输出到磁盘，直接输出到三方服务中，比如阿里云的SLS（要注意网络阻塞的问题）

# 高并发访问数据库引发的故障

高并发下常见的问题，SQL查询频繁，即使很简单的SQL也容易引发CPU暴涨

# 故障现象

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

# 原因分析

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

# 经验教训

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

# 高并发情况下锁引发的故障

并发下，容易形成资源竞争

大多数情况下不常见，有幸见过几次是在用activiti的时候前端连续点击重复请求，导致并发启动形成死锁

# 故障现象

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

# 原因分析

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

# 经验教训

使用锁操作要谨慎。

# 缓存引发的故障

这就是典型的缓存雪崩现象请求全部都打入数据库中。

可以看：《缓存雪崩解决方案》

# 故障现象

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

# 原因分析

缓存服务器在网站服务器集群中的地位一直比较低，服务器配置和管理级别都比其他服务器要低一些。

人们都认为缓存是改善性能的手段，丢失一些缓存也没什么问题，有时候关闭一两台缓存服务器也确实对应用没有明显影响，所以长期疏于管理缓存服务器。

结果这次一个缺乏经验的工程师关闭了缓存服务器集群中全部的十几台缓存服务器，导致了网站全部瘫痪的重大事故。

# 经验教训

当缓存已经不仅仅是改善性能，而是成为网站架构不可或缺的一部分时，对缓存的管理就需要提高到和其他服务器一样的级别。

# 应用启动不同步引发的故障

Spring Cloud中常用的Feign 组件，这个鬼东西是采用懒加载的方案，在用的时候才将Feign实例装载到Spring容器中。

所以，第一次请求过来的时候，会大量初始化Feign组件，导致请求缓慢，甚至于导致服务崩溃。

# 故障现象

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

# 原因分析

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

这种情况被内部人戏称作“姑娘们还没穿好衣服，老鸨就开门迎客了”。

# 经验教训

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

‍

# 大文件读写独占磁盘引发的故障

现在大多数文件读写会用到CDN厂商对应服务，比如七牛云的多媒体文件处理

专业的事情交给专业的人去做，就会少很多bug

# 故障现象

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

# 原因分析

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

# 经验教训

存储的使用需要根据不同文件类型和用途进行管理，图片都是小文件，应该使用专用的存储服务器，不能和大文件共用存储。批处理用的大文件可以使用其他类型的分布式文件系统。

# 滥用生产环境引发的故障

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

# 故障现象

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

# 原因分析

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

# 经验教训

访问线上生产环境要规范，不小心就会导致大事故。

# 不规范的流程引发的故障

规范的发布流程，可以避免至少50%的问题

# 故障现象

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

# 原因分析

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

# 经验教训

代码提交前使用diff命令进行代码比较，确认没有提交不该提交的代码。
加强code review，代码在正式提交前必须被至少一个其他工程师做过code review，并且共同承担因代码引起的故障责任。

# 不好的编程习惯引发的故障

# 故障现象

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

# 原因分析

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

# 经验教训

程序在处理一个输入的对象时，如果不能明确该对象是否为空，必须做空指针判断。
程序在调用其他方法时，输入的对象尽量保证不是null，必要时构造空对象（使用空对象模式）。

‍

link: 《大型网站技术架构》 (opens new window)

‍