0%

X通双11事故总结

本来想着双11就是买买买,结果今年接了X通这样的客户,这简直是灾难啊。

首先是rabbitmq挂了,原因是突然consummer下降一半,倒是queue message迅速提升,然后越积越多,导致最后都没法正常使用了。

而在这个之前我们对于rabbitmq这个一直没有关心,使用的都是默认的配置。而看到的日志就是client意外断开连接。

而从程序侧看到的日志是,重启consumer,但是一直连原先的exchange,但是那个exchange已经不存在了,导致无法连接成功。

然后也看到在这个情况下,mysql的慢日志里有一些大的查询,都是结果集比较大,有些连表的慢查询原先情况下是没有的,但是在高负载下是都显现出来了。

熬了2个通宵,改了rabbitmq server端的参数,改了client端重连exchange的逻辑,终于在第二天早上彻底把这个问题给解决了。

但是后面居然又出现事故了,这次是redis的问题,虽然用哨兵做了主从的切换,还用本地haproxy进行了代理,但是突然就连接不上了。后来一看是redis的cpu负载比较大导致的。

我们已经把很多redis进行了拆分,可怎么还有这个问题呢。后面查下来是X通不在线的人太多了,导致很多进行无谓的计算了。这个东西可不好改,只能临时进行redis的拆分,可一拆分后发现redis一天进行了好几次的主从切换,这TMD到底是什么原因啊。

这个就是用的什么破物流云导致的。

虽然这里总结的很简单,但是要找到这些问题都是多少人花费了多少个日日夜夜啊。

微服务如何快速定位问题,如何整理出所有的业务逻辑,这个貌似是一个不可能完成的任务。