案例八：3月25日前台下单报错服务器开小差

一、故障简述

故障描述：metadata-center为解决线上问题执行回滚，但因回滚不充分，引发当时版本和最新版本redis类型不兼容问题，导致网超，通用竞价，通用行业馆，企业购等下单失败

二、故障处理过程

发现问题 3月25日 9:30(-48) 线上元数据机器cpu飙高80%，有显示dubbo线程池满了，判断有死循环。
开始响应 3月25日 9:31(-47) 开发白杨，流云联系运维操作扩容保留现场，并开始执行回滚
故障发生 3月25日 9:49(-29) 开发白杨，流云完成回滚操作。但因回滚不充分，出现当前版本和最新版本redis类型不兼容问题
10:02(-16) 运维苏木发现报错：WRONGTYPE Operation against a key holding the wrong kind of value
10:08(-10) 开发，运维，架构等集中排查定位问题
故障开始3月25日 10:18(+0) 用户反馈网超等业务下单失败
故障处理3月25日
10:21(+3) 开发白杨，路遥等定位到key，并提供至运维操作。若谷在控制台用通配符的方式删除未成功。
10:29(+9)季木提供批量脚本，摩羯修改脚本传参，增加通配符及特殊字符转义!](https://img-blog.csdnimg.cn/93e149876d824583a879507d6e16e856.png)

故障恢复3月25日 10:36(+18)字段类型不匹配key删除完毕，报错消失，故障恢复。
三、影响产品线及影响面

网超，通用竞价，通用行业馆，企业购等下单失败

四、故障原因

开发发现线上版本cpu飙高，机器负载非常高，导致服务基本已经快不可用了，白杨判断必须立马回滚不然就会发生P1故障。但因相关人员信息未同步，导致回滚评估不充分，出现当前版本和最新版本redis类型不兼容问题，导致交易中心接口调用失败，无法下单。

漏测原因分析：
改动涉及底层逻辑，提测邮件未详细说明，面对面交流后评估改动影响面未考虑性能测试覆盖

3.25晚上2点收到告警，没人看到；早上6点多流云发现和季木沟通，确定为使用pipeline的方式，这个方式redis归还连接有点问题，导致redis连接耗尽。
3.24晚上发了一个去网超的版本，在此之前cpu负载一直很平稳，那天从8点多~9点多，cpu直线彪高, 业务方收到告警dubbo线程池耗尽(这个现象基本断定cpu高和线程池耗尽是发版导致的)

当时想和运维商量保留一台现场定位原因，运维反馈这个挺麻烦的需要挺长时间的，后来白杨和流云商量了下觉得回滚没有问题，决定还是立即回滚; 当时没有定位为什么cpu彪高，下面会说明

由于没有现场，无法有准确的证据证明dubbo线程池耗尽的原因；

中午12：30，在不断的排查中(通过pinpoint和日志,mysql数据库)，将问题逐渐锁定在一个dubbo接口上(GlConfigReadService:getInstanceAndDistrictValue)

分析过程如下：

先看了mysql数据库实例，发现cpu很平稳，这期间也没有慢sql，排查数据库引起的问题
2. 根据dubbo线程池耗尽这个说明，出问题的接口并发量一定不低，通过日志去找15分钟前10的接口锁定在了9个接口上面，其中最高的getInstanceAndDistrictValue并发每秒峰值能达到2000，当时很怀疑是这个接口

3. 逐一排查这9个接口(对比pinpoint发版前一天的trace和当天的trace), 发现getInstanceAndDistrictValue这个接口的链路普遍变多了，很多在3.24调用了一个SQL(rt在10多ms)，但是到了3.25以后需要好几个SQL(一般是4个), RT就变成了100多ms. 我觉得问题很有可能出在这个上面，带着疑惑去看代码果然发现了问题, 当时这段代码是这样的：


上面的代码先去读本地缓存，但是很奇怪的是读完缓存会马上有一段cache.removeCache的操作，这个很诡异；问了流云，这块代码是之前追马留下的，他也不太清楚；这一次优化的是else的逻辑，这意味着每一次调用这个方法其实走的都是else，而else的逻辑是查询数据库；这一次修改做了层级的概念，原来找当前实例+区划等级的配置即可找不到就返回空，现在找不到会去找实例，实例找不到会找业务类型，业务类型找不到会去找平台默认；而很多配置都是调用在平台级的逻辑的；这样就导致原来一次数据库搞定的事情现在变成了4次；看pinpoint的trace对于4个级别的调用量在8点多基本在100ms左右；随着流量涨上来到了9点半，这些rt在500多ms了

另一块就是回滚导致redis的模型不兼容了，这个是讲原来一个string类型的数据结构改成了hash, 回滚以后用redis.get的方式去读hash的值就报错了，导致下单完全失败；将所有hash的key回滚就处理完成了。

五、故障评级
故障等级P2

故障类别：技术评审不充分/流程问题-回滚不充分

六、后续ACTION：