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到底是什么原因啊。

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

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

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