一次线上事故，记录打工人的生活

这都得从我接手的一个老项目（微服务架构）说起。

作为每一个打工人最讨厌的周一，我像往常一样熟练的开机、上微信、企微，打开各种IDE工具，程序还没启动完、我这屁股也还没坐热乎，微信那专属的橙色心悸图标闪了一下，我这心想早上九点钟一般没人给我发消息啊，不会是项目出问题了吧？打开一看，果然客户反馈群已经炸了

我首先想到的是看看微服务有没有问题，迫于是老项目又没有日志收集，只能看日志控制台，但那刷新频率显示器赫兹都没它快，不过我这熬夜熬出来的金光眼还是看了个大概，系统没有异常问题，都是正常日志，那估计就是数据库有问题了，这是双十一当天CPU的使用率，上午基本都是满的

按理说目前也就几千万的数据量不会有这么高的占用率，估计又是哪个牛马SQL导致的

一看果然，全表扫都上亿了，真是卧龙凤雏+五虎上将全出来了嘿

话不多说赶紧杀掉相关线程，保证客户正常使用才行

        1
2
3
4
5
6
        -- 筛选出所有非空闲的线程并且排序
SELECT * FROM information_schema.PROCESSLIST WHERE command != 'Sleep' ORDER BY time DESC

-- 拼接出需要杀死time时间比较高且不是空闲状态的线程语句
select concat('kill ', id, ';') from information_schema.processlist 
where command != 'Sleep' and time > 100 order by time desc

然后执行语句，CPU这才一点点落下来，我如释重负，心跳慢了下来，老板手里的刀也放了下去，大家都很开心。

总结下来这件事其实就是两个原因：

没有一个全链路的日志监控+报警系统。
数据库飙升后没有相关报警功能，导致满了业务卡死才发现。

最后相关业务的SQL处理，加索引，加缓存，以及万能处理办法：往Java里仍。

后端服务出问题的往往都是数据库层面，数据库不像微服务无状态，性能不够了堆机器就能解决，数据库不行，这玩意性能到顶了就得拆库拆表，搞索引搞缓存，解决成本直线增加，所以一开始写代码的时候像JPA思想一样面向对象操作，全是单表操作，需要什么字段再去关联查询，把压力都在Java层面拦住，这才是解决这类问题的关键