记一次线上文件数打开过多的问题（一）

问题

线上服务忽然宕机，导致应用全部异常退出拒绝服务，运维同学反馈线上app无法登录了。

查找原因

直觉告诉我，又是数据库挂了（之前有过先例），已经做好了最坏的打算，准备去kill process了，打开阿里云后台，结果发现数据库一切正常。

然后去看应用服务的监控，结果发现没有任何监控数据，开始以为是monitor也一起挂掉了，后来才知道是因为应用挂掉，导致数据无法采集才产生了CPU、内存等数据全部为0的现象。

那么本着优先恢复线上故障的逻辑，先弹出2台机器应付线上流量，保留故障现场，开始分析问题，但是故障机器已经没有任何监控数据输出了，只能登录进服务器查看数据，top命令发现CPU，内存一切正常（后来才知道buffer/cache占用过大也会造成异常），磁盘也是正常的。那会不会是恶意攻击呢，造成了网络堵塞（虽然可能性也不是很大），但还是尝试看了下SLB的流量，发现宕机前果然是有流程峰值的，但这个也好像说明不了什么，毕竟服务器宕机也是会造成流量堆积的现象的。然后去看mongo或redis的网络情况， 也没有发现任何异常，这个问题就很诡异了。

后台查看新弹出的机器，发现一个异常的地方， java进程打开的文件数（lsof的结果），持续在增长，当达到1000+后，服务器就开始崩溃了。但是很奇怪，近期上线的代码里没有操作文件的地方（开始不知道网络句柄也算文件数），查看lsof（list open files）命令，发现里面有很多“sock”，猜想这个应该是哪个地方的连接溢出了， 首先想到的是redis是否有问题，查看redis的连接数，发现并没有很大。

分析代码

最后没办法，就看发生问题之前都上线过哪些代码，一个版本一个版本的看，发现出问题那天上线的版本一共合并了4个功能，然后对每个版本分别部署测试环境，查看文件数的变化。

一共发现了3个地方的改动

1. 分布式锁
2. 异步定时任务
3. 异步写日志

采用控制变量法，这些改动一个一个还原回去查看效果，具体执行结果的原因分析见下文。