超级会员免费看
本文讲述了阿里云ARMS排查一个由ACK容器环境中的Java事务阻塞导致的系统连锁雪崩故障。故障起因是运维手动结束并加入新节点，触发大规模FGC，进而引发数据库表锁和Redis分布式锁问题，导致多层服务不可用。通过日志和性能监控，分析出Lock wait timeout exceeded异常，并非死锁，而是事务超时。最终发现节点异常、数据库表锁和分布式锁问题交互作用，造成系统长时间延迟。解决方案包括检查数据库事务锁并kill，以及避免手动操作导致的系统不稳定。
说明：这是一个非常复杂的故障排查过程，也是非常有价值的经验分享。这是一个K8s环境，非常复杂的故障涌现过程，排障过程也很慌乱，整个过程现在整理起来看起来很轻松，不过当时却是另一番心情。
背景：线上N个微服务，之间调用关系复杂，简单的来说有上层服务，中层服务，底层服务。
上层服务实际上是N个不同的服务，这里简化为A服务（实际上是A1，A2等），中层服务也是简化为B服务，底层服务简化为C服务和D服务。
调用链关系：A-->B-->C->D A,B,C,D都-->数据库 C--->Redis分布式锁
现象：下午15:15分A1服务出现严重响应延迟。
下面是事件过程中完整的性能趋势图
从图中看出 多个系统都出现分钟级的延迟，持续很久。
<
订阅专栏 解锁全文
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
