This website requires JavaScript.

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

1 2021-11-12 16:33:19 74

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

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

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

https://yd-note.oss-cn-beijing.aliyuncs.com/blog/%E4%B8%80%E5%9C%BA%E7%BA%BF%E4%B8%8A%E4%BA%8B%E6%95%85/a.png

https://yd-note.oss-cn-beijing.aliyuncs.com/blog/%E4%B8%80%E5%9C%BA%E7%BA%BF%E4%B8%8A%E4%BA%8B%E6%95%85/b.png

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

https://yd-note.oss-cn-beijing.aliyuncs.com/blog/%E4%B8%80%E5%9C%BA%E7%BA%BF%E4%B8%8A%E4%BA%8B%E6%95%85/c.png

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

https://yd-note.oss-cn-beijing.aliyuncs.com/blog/%E4%B8%80%E5%9C%BA%E7%BA%BF%E4%B8%8A%E4%BA%8B%E6%95%85/d.png

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

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

        
  • 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层面拦住,这才是解决这类问题的关键

免责声明

本站提供Hack区的一切软件、教程和仅限用于学习和研究目的;不得将其用于商业或者非法用途,否则,一切后果由用户自己承担 您必须在下载后的24个小时之内, 从您的电脑中彻底删除。如果条件支持,请支持正版,得到更好的服务。 另如有侵权请邮件与我 联系处理。敬请谅解!

本文于   2021/11/12 下午  发布 

永久地址: https://madaoo.com/article/1459197626439307264

版权声明: 自由转载-署名-非商业性使用   |   Creative Commons BY-NC 3.0 CN