大型网站典型故障案例分析
来源：
本站
发布时间：
2017-03-30 22:10
阅读次数：
先讲一个小故事。有一次，笔者和几个网站架构师讨论问题，期间，一个架构师被他们部门总监叫去面试一个应聘者，这位架构师就回来了，我们都很奇怪：怎么这么快？他笑道：“这位老兄，工作十几年，什么都不会，没什么好问的”。我们问他都问了什么问题，结果都是一些如果没有经历过，就永远不会想到的问题，而这些问题只要在大型网站技术一线呆上两三年，就一定会碰到。
一位网站架构师曾经说过：在互联网公司呆上一年，相当于在传统软件公司呆上三年，他的意思大概就是在互联网公司遇到的问题比传统软件公司三年遇到的问题还多。而且随着网站业务的快速发展，问题也层出不穷，每年遇到的问题都不同，遇到问题，解决问题，经历了这个过程，技术才能升华，人和技术才能融合一体，才知道什么技术是真正有用的，什么技术是花拳绣腿。
大型网站的技术本质都很简单，没有很花哨的东西，掌握起来也不难。大型网站的架构师左右价值的地方不在于掌握了多少技术，而在于他们经历过多少故障。每一次故障都会给公司带来难以估计的利益损失，所以培养一个网站结构师的成本不单要看付了他多少薪水，给了多少股票，还要看为他引起的故障买了多少次单。
这里列举一些网站的典型故障，我们会发现埋在高并发和海量数据的情况下，很多一般情况不是问题的问题会涌向出来。
写日志也会引发故障
故障现象：某应用服务器集群发布后不久就出现多台服务器相继报警，硬盘可用的空间低于警戒值，并且很快又服务器宏机。登录到线上的服务器，发现log文件夹里的文件迅速增加，不断消耗磁盘空间
原因分析：这是一个普通的应用服务器集群，不需要存储数据，因此服务器里配置的是一块100GB的小硬盘，安装完操作系统、WEB服务器，Java虚拟机，应用程序后，空闲空间只有几十GB了，正常情况下这些磁盘
空间足够了，但是该应用的开发人员将Log输出的Level全局配置为Debug,这样一次简单的Web请求就会产生大量的log文件输出，在高并发的用户请求下，很快就消耗完不多磁盘空间。
经验教训；
应用程序自己的日志输出配置和第三方组件输出要分别配置。
检查log配置文件，日志输出级别至少为Warn,并且检查Log输出代码调用，调用级别要符合其真实的日志级别。
有些开源的第三方组件也会不恰当地输出太多的Error日志，需要关闭这些第三方库的日志输出，至于那些第三方库有问题，只有在遇到时才知道
一起设计吧
一起设计吧
