案例五：9月18日 商品中心、依赖商品交易异常

一、故障简述

故障描述：

标准cpu100%，导致商品、交易业务受影响

二、故障处理过程

事件开始

10:46 【监控告警】应用ERROR级别日志过多,app_errorlog_count_1m >= 50
10:48 【技术支持】反馈商品开发
10:49 【运维】反馈故障快速处理群
10:50 【商品研发】查看告警详情、分析trace链路、分析应用流量、db cpu 100%，大量慢sql：品牌表 like 查询
10:52 【运维】查看告警邮件和RDS告警信息, 将慢日志列表发送到告警
10:53 【客服】反馈运营账号协议商品查询报错，服务器内部错误，无法完成请求
10:54 【运维】查看分析慢SQL
10:55 【运维】将慢sql的对应的url发送到9月18日的商品告警群里
10:55 【商品研发】根据慢sql traceId找到接口，进行限流（cn.gov.zcy.service.brand.facade.BrandReadServiceFacade#findBrandList）

10:58 【运营】反馈发布商品，提示内部错误
10:59 【技术支持】与安全确认 流量正常，无爬虫行为
11:00 【运维】基于分析慢SQL结果对parada_brand表，parana_brands~like进行限流
11:00 【运维】将活跃session 批量kill
11:01 【质量】反馈商品详情页无法打开，服务器开小差

P2故障开始
11:03 【客服】后台跳转前台大厅失败
11:05 【运营】反馈反向竞价到时间提示系统升级
11:10 【技术支持】基于用户反馈影响交易线及商品详情页，发送P2故障通告

11:13 【商品研发】item-standard 应用重启完成

故障恢复
11:13 【故障恢复】应用重启完毕，db cpu使用率降下来
11:15 【客服】反馈商品详情页无法打开，服务器开小差未解决【反馈有延迟】
11:16 【运营】反馈医疗商品发布报错【反馈有延迟】
11:17 【内部】测试反馈 商品详情页反馈前台、需求单、预购单、订单、加购都正常
11:22 【技术支持】验证商品详情页正常，发送P2故障恢复通告

三、影响产品线及影响面

商品发布、审核等；

前台大厅、商品详情页、商品搜索、购物车、直购、通用采购计划组件等；

在线询价、通用定点、反向竞价业务线均受到影响，影响功能主要针对下单、报价等功能，查询供应商、商品详情信息等等；

订单，履约业务线均受到影响，影响功能主要订单列表，订单详情，履约详情的查询等等。

四、故障原因

4.1、大量高扇出数据库调用，导致cpu飙升到100%

数据库cpu日志(内存无明显变化)如下

   时间         百分比

10.41分 16.21%，
10.42分 67.59%，
10.43分 100%，

4.2、调用链路如下，

09-18 10:41:46 运营审核品牌，恰巧遇到高扇出数据id=1723909（一次操作2988次数据库查询与插入，此操作一共操作了30次，因为后端已经报错，运营侧尝试多次提交，周五晚已经复现)，同时多个运营同时操作了品牌审核，spu 审核（巡检故障导致所有运营审核品牌、spu，诱因非主要原因）
id=1723909 开始与结束

3.09-18 10:42:20 另一高扇出数据id=1723910被执行

4、引发问题代码

每次调用查询两次授权表，内部还有2次其他查询，出问题多的数据，约3000个类目，一下子就把CPU 打满了，后续的多次同样的请求只是加剧了cpu

解决方案：对长度超过100的，返回错误码

5、故障过程亮点与痛点回滚回顾：

亮点

（运维）尝试使用db 限流，从一定程度上缓解cpu 压力（虽然cpu未下降，但是防止了进一步恶化）

（研发）应用重启：采用了dubbo 限流，db限流，未能本质上促使db cpu 下降，应用重启后释放了连接，db cpu 才真正下降，系统恢复正常
痛点

db cpu 100%，导致没有问题的sql 大量变成慢sql，干扰了迅速定位问题的方向，同时为后续的根因分析带来了杂音，如图

五、故障评级
故障等级

P2

故障类别

性能问题-慢接口-循环操作数据库

六、后续ACTION：