现场会系统服务挂掉了，要挨批斗

1.现场会系统展示

今天上午开现场会，需要展示系统功能。
因为老板千叮咛万嘱咐，要保证当天的服务正常，
近期的一些服务端调整都没敢大刀阔斧，都只做一些样式上的优化。

最近一段时间来，系统都没出现过什么大问题，偶尔服务慢了也不是声明重启服务解决不了的问题；
而且系统已经上线两年多了，也经过了时间的验证。

2.服务挂掉

就在我觉得一切都没什么问题的时候，问题还是出现了！

我在上班的路上收到用户反馈，说系统登录不上了。
我大惊失色，正要联系人员重启服务，就接到了老板的电话，说怎么回事，这么关键的时间点上出问题了！
我连忙回复到：马上处理。这个时候心理还有一点底，心想重启一下应该就没问题了。

3.重启服务

后来公司副总重启了系统服务，系统瞬间回复了往日的健壮。
我兴致勃勃的通知用户：服务已经正常，可以登录了。

没想到在几分钟后，系统服务再次瘫痪！

这个时候开始怀疑是数据库哪个表的数据量太大，今天大量的用户涌入导致查询压力。

把能删除的数据都删了，服务还是会几分钟后就挂掉！
这下着实开始发慌了，现场会上第一波人员已经到达；
这一波是无法展示系统了，1小时后还有第二波，要是第二波也无法展示系统那最近的工作就相当于白做了！

4.应急处理

情急之下，我们指得将可能出现问题的接口直接返回，不做任何业务操作。
调整后重新启动服务，一切终归于平静。

5.问题分析

以往出现服务挂掉多半的症状是服务器CPU或者内存使用率爆掉了，但是这次的CPU和内存都只有很低的占用率，倒是磁盘一直处于全速读写状态。

最后发现问题出来一个日志文件上，业务代码中有数据锁，前一个未操作完后一个就等待，等待时间长了就会报错，一报错就会读取日志文件。
然后报错一直爽，一直报错一直爽！
以前整个读写量再磁盘的极限范围内，所以没有太大问题；这次用户翻倍了，就出现了本次事故。

6.处理方案

定位到了问题，那就八字有一撇了，接下来进行代码优化。

• 调整原来的数据锁逻辑，改为使用缓存方式。
• 取消生成环境下不需要的日志记录
• 调整日志保存策略，尽量不要有一条就马上读取写入日志文件。

7.问题总结

该做的压力测试不能少！
不在问题中倒下必在问题中成长 。