一次线上事故,记录打工人的生活
这都得从我接手的一个老项目(微服务架构)说起。
作为每一个打工人最讨厌的周一,我像往常一样熟练的开机、上微信、企微,打开各种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层面拦住,这才是解决这类问题的关键