早上上班收到了很多线上防刷警告。马上想到上去看看服务器日志数据和服务状态。
一、日志数据，无异常
二、服务状态发下docker进程 自动重启我们这边业务上有个逻辑，触发一定值会开始防刷逻辑，防刷会自动重启服务，所以服务重启有2个方面：
1）防刷开启
2）代码bug
很不幸，这两种，这次线上事故都出现。下面讲解下怎么处理这类问题。
1）防刷开启。这种问题是业务层面问题，是代码实现问题，这是正确流程，看日志就能确定这里就不做赘述
2）代码层面上的bug
查看重启日志上下文，怎么找？比如重启初始化有打印日志，在看看上面就做了哪些操作
docker 控制台日志输出，初始化日志为加载完成，向上推测。找到报错信息，太多的文件打开
too many open files in system 什么意思呢？可自行百度
谈谈如何解决问题：
（1）进入容器 sudo docker exec -it 28f050dsx56xr sh 当然如果是二进制程序文件部署略过
（2）查看docker内进程PID 本次进程PID 7
（3）lsof -p | wc -l 统计当前打开文件数。socket链接才100多，其他文件打开1W多
（4）lsof -p > test.log 导出日志，vim test.log查看，从下图可以查看到大量的日志文件被打开而没有关闭。疯了疯了，改代码吧。关闭日志文件。
（5）修复代码，close打开的文件，在验证（重复上述操作）就正常了。
三、扩展，就算是too many open files in system进程也不应该会退出，为什么会退出呢？我们找问题不仅要找到问题，而且有的引申问题也要去挖掘，这样才能为后期维护做好准备。
上图为go语言实现，我们公司底层自己封装了下accept，也就是说accept失败报错，会直接os.Exit(1)当前进程。这才是为什么没有core文件，但是程序退出了。想想socket都链接不上了，不退出又能干嘛，这样还能方便查询定位问题。而不是等着预警来提示这样会增加查询的复杂度。
