记录一个诡异的线上宕机事故，大佬们帮忙排查一下问题呀
source link: https://www.v2ex.com/t/800791
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
二三十个微服务 SpringBoot+Dubbo 部署在阿里的 K8S 上，数据库也是买的阿里的 RDS，听领导说配置还挺高的，支持主备自动切换什么的。
事故起因和经过
大版本上线，改了用户的缓存数据结构，凌晨上线时把 Redis 用户缓存全清了，上线当晚验证功能正常，白天运行也十分稳定。
下午 5 点多业务高峰的时候运营反馈系统蹦了，看后台是数据库负载正常、Dubbo 调用全部超时，领导首先怀疑是系统被攻击了，然后在阿里的后台打开了防火墙增强模式（具体叫什么不懂，效果是可以阻拦大部分到 Nginx 的请求），开完观察了好久后台调用还是超时，老板都开始炸锅了跑来了解情况，领导开始尝试万能的重启大法，ZK 的三个节点都重启了，微服务也挨个重启，绝望的是重启依然没有任何效果。
一顿瞎搞时间很快就到了晚上 8 点，这时候已经宕机 2 个多小时了还没找到原因，也不知道怎么恢复。然后我试着用 Arthas 监控了一下调用时间，发现主要业务流量入口 M 服务调用 Cache 服务一直超时，调用 C 主要是 M 从 Redis 获取不到用户缓存，需要 C 构建缓存放 Redis 。监控 C 服务的时候发现所有请求数据库的耗时都要 2000ms 以上，然后我们构建缓存需要读 8~9 次数据库但是 Dubbo 的超时时间设的是 10s 所以一直超时。
首先怀疑是 SQL 写的有问题，但是有一个根据主键 ID 查询单表的居然也要 2000+ms，这就非常离谱了，后面我把参数打出来自己拼接 SQL 用 Navicat 查询只要十几毫秒，领导说可能是工具监控有问题，然后当场给这个查询加调用时间的日志验证，从 master 拉的分支，只加了一行日志！！！
然后，重新发包观察，诡异的是，系统恢复正常了！！！没有调用超时的日志，新加的那行日志打印出来的也是十几毫秒，其他服务也能正常调用了！！！
领导给的事故报告是晚上清除用户缓存，没有预先跑脚本构建缓存导致业务高峰期系统宕机。
为什么那个时间点 Navicat 和微服务查询同一条 SQL 时间差这么多？然后加了行日志系统又自动恢复了？诡异，太诡异了，说没有鬼我是不信的
大佬们来帮忙排查一下这可能是什么原因呀
第 1 条附言 · 7 小时 38 分钟前
[img][/img]
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK