统计队列 重大生产事故 解决历程
全线崩溃
2020-8-11号晚上上线内容：统计项目优化2.0.1 大改版2.0后的一次个优化版本 主要改了到期时间交集及脱保30天等内容
晚上10点-11点上线完毕后 监控正常 1点时统计mq积压4w （第一个问题暴露） 早上9点半后整个crm全线崩溃 统计队列积压以达40W
紧急处理
应急处理方案：回滚统计相关代码 删除mq队列 -唯一吐槽的点时为了稳住客户 删掉了40W的对列
当天看日志排查问题首先定位到 连接池数量超过最大限制数：
User 'ci_car_insurance_odds' has exceeded the 'max_user_connections' resource (current value: 10000)
跟dba对接后将得知dba晚上临时把数量调小且没有跟研发部门沟通
这是第一个节点初步定位为 dba对数据库的调整问题。
蛛丝马迹
作为统计项目的唯一开发人员，我在看日志的时候发现有一个异常数据 ：12号1点到5点的日志里显示 本该又16个事件的mq日志里99%都在跑一个业务 【分配业务】，而且是一个商户id=18595 的商户 一直再跑，同样的数据20分钟内跑了128次，针对这个情况我第一时间判断是否为恶意攻击。通过排查日志系统发现客户在11号-12号整个事件内并没有进行任何与分配相关的操作，没有批量导入（会设计分配业务），最后定位到 应该是系统自动作业里的【系统预测】业务，自动作业1点开始跑，所以1点后有大量的数据 ，且有一个循环出了问题：list 数据循环处理 后根据buid （业务唯一id）取出新list后推送【分配业务】，本来第一个List128个应该触发128次【分配业务】，结果发了128*128次，我他娘的差点崩溃。
连忙改好了bug，提测，配合测试。
结果测试人员说过两天再上吧，OJBK.
再露狰狞
2020-8-19终于盼来上线的我很开心，上完毕了线后感觉已经消灭了这个差点毁灭了整个系统的bug。
2020-8-20 9：20开开心心到了公司的我决定再在线上看一下对列 2000+积压 每秒消费40个 问题不大 10分钟后 4000+积压 每秒消费40个，有点慌了 5分钟后增长到了8000+（by the way 9点后客户开始上班 9-11点使用高峰期）
于是又开始了回滚和看日志。
我严重怀疑是本次需求里的 交叉到期事件 没有加对应索引导致的数据库查询过慢后导致的整个系统的响应时间慢。
查了 批量修改客户信息事件 （上次笛卡尔积的哪个）结果没发现问题。
9点15分是一个分界线 15之前 每个事件的处理都是毫秒级别的 15之后都是3s 6s 10s 30s 120s 。。。 又是一波毁灭
寻找真凶
找到leader 了解到，他不管删过mq还重启过项目 但是mq积压任然居高不下，但是代码回滚后却没问题，旧的是6台负载，新的是14台负载。结论：新代码导致了这个问题。
我的心态是崩溃的，因为线下测试人员跑的时候并没有问题，所以怀疑是不是业务量上来后遇到了性能瓶颈，居我早上看我们的并发在每秒50-100。数据库分库100个，统计表里交大的1000W数据 。
难道真的遇到了业务量与机器性能的差距了。
日志按照小时记录在不同的文件里 ，我决定看看8点的日志，功夫不负有心人，8点系统稳定的时候有一个事件耗时6s很稳定，要知道这是不正常的，偶尔的高耗时还能理解但是稳定的就是搞事情了。
排查后发现本版需求改了这个增加了一些io操作，且开启了3个链接。
我决定分两个方向，1：记录每一步日志，线上跑一下（线下亲测没问题0.1s以内）2：将3个链接改为1个简化业务。
就在我还没精简完业务的时候 ，leader上了新代码且mq飙升贼快，拿到日志后看了一下，果然一个地方消耗6s。
一个方法内请求另一个系统拿数据因为数据几乎不变所以做了reids缓存。而且第三个系统也会拿这个同名的redis.
问题：配置文件中接口路径没写对，导致方法访问不成，线下测试中估计是有第三个系统已经建立了redis。所以线上没拿到reids后会等待http6s 后 显示返回的result=”“。
解决了问题 重新上了一个站点后mq回归平静。
总结：
本次暴露两个问题：
1：循环嵌套循环时的逻辑问题造成了大量的重复业务造成了对列数激增。
2：开启数据库链接内部 访问http其他网站接口但是五相应后 数据库链接被长时间占用 ，在使用频率最高的业务流中造成数据库链接得不到释放，最终连接数超过最大限制，数据库链接缓慢导致系统全线宕机。
原因：
1：高并发下的关注点已经不仅仅时业务是否正确，需要考虑每一个方法的实现异常是是否会导致系统崩溃。
2：从研发到测试并没有能力检查这个问题
3：解决掉一个问题后会失去 继续排查问题的耐心
2020-8-20 一个会被开掉的程序员