案例一7月6日 交易心metadata_center CPU 跑满100%故障review

问题描述

交易中心-配置中心应用 metadata_center 应用 CPU 跑满 100%，导致部分用户登录不稳定，项目采购项目开评标解密失败，竞价单报价受影响

故障处理过程

【故障发现】
09:27 线上故障快速处理群告警： sql执行有40多秒


【故障响应】

1. 9点28分，徐四应急处理，快速重启应用

2. 9点29分，片风从pinpoint查看到metadata-center有很多慢请求，并且有异常报错

9点30分，徐四找到片风，紧急kill 慢SQL

9点31分，片风连续kill 慢SQL 3次，发现pinpoint慢请求没有减少的迹象

9点33分，徐四紧急添加索引，CPU100%索引加不上去

9点34分，初步定位为别名服务引起的

9点36分，找虚竹紧急对别名dubbo服务紧急限流
9点38分， 片风对服务metadata-center进行重启，并同时进行sql会话停止，问题依然没有消除

9点40分，数据库100%依然没有缓解

【故障定位】
9点47分，子龙紧急对关键字dubbo服务，进行mock，并发版

9点48分，数据库100%依然没有缓解

9点50分，子龙怀疑关键字请求入口还有rest接口，通过肉包慢SQL提供的traceId溯源后发现是rest请求


9点50分，徐四对配置中心web服务紧急下线

9点52分，数据库CPU100%已经下来了，徐四重新添加索引

9点52分，徐四对web服务开始恢复

9点57分，子龙对关键字dubbo接口进行复原，并且发版

三、影响产品线及影响面
影响产品线：
1.用户中心
2.交易寻源
3.交易前台
影响面：
1.部分竞价单供应商无法报价
2.首页大厅顶通展示异常，部分内容丢失
3.部分用户登录加载缓慢受影响

四、故障原因
起因是因为慢SQL优化


具体慢SQL:

select

id,prop_id,level_key,industry_id,industry_code,instance_id,instance_code,hall_id,district_code,org_id,group_concat(category) as category,

key,value,search_key,creator,create_time,modifier,modify_time
from sp_instance_config
WHERE

prop_id= 1009
and level_key= 'PLATFORM'

group by key
order by modify_time desc
limit 0,10

因为prop_id 和level_key 都没有索引

根据真线数据查询后发现 prop_id 的有一定的离散度，故在测试环境添加索引后验证，然后在真线添加索引
具体慢SQL:

select

 id,prop_id,level_key,industry_id,industry_code,instance_id,instance_code,hall_id,district_code,org_id,group_concat(category) as category,

key,value,search_key,creator,create_time,modifier,modify_time
from sp_instance_config
WHERE

level_key= 'INSTANCE_DISTRICT'
and is_custom= '0'

limit 5000,5000

该SQL是夜里的定时任务拉取数据库配置，刷新redis缓存的。level_key没有索引，所以在测试环境添加索引后验证效果，然后在真线添加索引

由于添加了上述的两个索引，导致别名查询场景下的，索引效率降低了，在大流量场景下触发了CPU100%

/* Traceid: fb3f98a5eb3d7c2e12597dbf5b804803 */

SELECT id, prop_id, level_key, industry_id, industry_code , instance_id, instance_code, hall_id, is_custom, district_code , org_id, category, key, value, origin_value , search_key, creator, create_time, modifier, modify_time

FROMsp_instance_config

WHERE prop_id = 1009 AND level_key = ‘DISTRICT’ AND district_code = ‘330602’ AND category = ‘BIDDING’

因为所有的别名都指向prop_id = 1009 ，数据量为：17087。原先已存在的索引 idx_instance_code_key(category,key)，散列情况如下

由于新增加了prop_id的索引，导致原先的idx_instance_code_key(category,key)的所有失效，区分度不如之前的效果，在大批量流量的场景下，导致CPU100%

别名大量请求击穿缓存，落到数据库的原因：

该段代码逻辑如下

影响面分析

如果业务接了sdk，会走二级缓存拿配置，不影响业务。未接sdk的会因metadata-center-serv短时间不可用导致超时。
运营配置时因为调用meta-center超时导致失败。
大厅前台页，顶通因为拿不到配置导致超时。

为什么配置中心的问题会影响登录？

目前的请求流量拓扑如下：

请求从waf设备进入，经由SLB, nginx集群到容器网关Istio Gateway, Istio Gateway对应的是业务应用。

nginx集群的upstream server是istio gateway

upstream在0s的时间间隔内如果失败三次，就设置该server为不可用, 如果是所有节点都不可用，就会重置fail计数, 所有节点都可用。

因为metadata-center的http请求5xx错误过多，导致所有server都不可用了，影响到正常的http请求502 “no live upstream”; 因为设置了fail_timeout=0s， 很快server重新加入upstream，可以接收新的请求，导致今天真线环境偶发502的请求。

以下是各个时间点"no live upstream"的日志：

在出问题期间非502的流量日志

在出问题期间502的流量日志

9:27到10:00开标的项目，目前查到有7家供应商未完成解密

2022年扬尘在线监测设备（PM10、PM2.5）增设项目
CNDL2022159 代理机构 开标过程中 解密中 经常显示系统升级 报错 时好时坏

SZQL-TL2022GK-003

项目名称：**县分水江治理提升工程可研方案编制
采购单位：**县林业水利局
组织实施机构：**群伦项目管理有限公司 用户反馈在做这个项目的专家抽取的时候，提示她服务器内部错误，无法完成请求

五、漏测分析
可以事先进行接口的性能测试，排除此次故障发生的可能

六、定级定责依据

七、故障评级

八、监控告警描述（有监控告警发现的需要提供的资料）

九、后续Action

十、快速恢复预案

原因分析：

起因是因为两个慢SQL优化，给sp_instance_config表添加 level_key和key两个索引；通过慢sql，发现查询别名的sql --prop_id有一定的离散度，且prop_id=1009就是代表别名，于是添加索引：prop_id。刷新redis缓存的SQL没有索引，因此添加索引：level_key。
由于上述的两个索引（主要是prop_id ）在别名查询场景下的（另一场景的别名查询）指向prop_id = 1009 （数据量为：17087），但是原先已存在索引 idx_instance_code_key(category,key)，反而导致索引效率降低了，在大流量（一小时内请求了17w次）场景下触发了CPU100%.

真线查询别名具体慢sql:

select 
id,prop_id,level_key,industry_id,industry_code,instance_id,
instance_code,hall_id,district_code,org_id,
group_concat(category) as category,`key`,`value`,search_key,creator,create_time,modifier,modify_time
from sp_instance_config  WHERE  
     prop_id= 1009 
     and level_key= 'PLATFORM' 
     group by `key`
order by modify_time desc limit 0,10


真线夜里的定时任务拉取数据库配置刷新redis缓存的SQL是：
 select 
 id,prop_id,level_key,industry_id,industry_code,instance_id,instance_code,hall_id,
 district_code,org_id,group_concat(category) as category,
   `key`,`value`,search_key,creator,create_time,modifier,modify_time
from sp_instance_config
WHERE
    level_key= 'INSTANCE_DISTRICT'
    and is_custom= '0'
limit 5000,5000


当天触发故障的sql:
SELECT 
id, prop_id, level_key, industry_id, industry_code , instance_id, 
instance_code, hall_id, is_custom, district_code , org_id, category, `key`, `value`, origin_value , search_key, creator, create_time, modifier, modify_time
FROM sp_instance_config
WHERE 
prop_id = 1009 
AND level_key = 'DISTRICT' 
AND district_code = '330602' 
AND category = 'BIDDING'

修改索引（增加联合索引）：
![在这里插入图片描述](https://img-blog.csdnimg.cn/0485599ce71640aea6e7cd22872fd540.png)

故障当天请求日志：
![在这里插入图片描述](https://img-blog.csdnimg.cn/837bf3b00972421ab654a908dd4acb83.png)

# 解决方案：
>提示：这里填写该问题的具体解决方案：

例如：新建一个 `Message` 对象，并将读取到的数据存入 `Message`，然后 `mHandler.obtainMessage(READ_DATA, bytes, -1, buffer).sendToTarget();`换成 `mHandler.sendMessage()`。

这篇好文章是转载于：学新通技术网