一、故障简述
故障描述: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: