商品秒杀场景下高并发由于jdbc连接池设置和dubbo线程池设置不合理导致的问题分析解决

问题描述：

早上9:00到9：30期间，电商运营同事反馈电商app做秒杀活动，打开时间较长，后续不断提示调用失败。同时有收到钉钉应用的告警信息，oaapi cpu过高。

 

问题分析：

由于电商页面会调用中台营销marketcenter系统，营销会调用oaapi接口获取营销活动区域信息。oaapi接口大批量超时，具体接口com.ncarzone.oa.biz.facade.DeptServiceFacade.findDeptInfos(List departmentIds); 根据部门id批量查询仓库信息接口

通过查看日志发现marketcenter在每次调用时都会传入所有的仓库id，oaapi会返回所有的仓库信息，数据量比较大,同时由于marketcenter对该接口请求并发量比较高(30分钟内请求量10w以上，是平时请求量大概5~6倍),响应时间变慢，同时没有缓存,最终导致数据库连接池被占满，负载增高，应用被这些线程拖垮，也无法正常响应其他接口请求。

解决方案：

1.对机器扩容，由之前的2台，在大促活动时候，扩容到4~6台

2.调整jdbc连接池数量，将maxActive =1 0 调整为maxActive = 100

3.与营销同事沟通，确认他们逻辑是不是有问题，经沟通，他们在调该接口传入门店id列表之前要做相应的过滤，不应该全量查询所有门店信息

4.对该接口增加缓存，将入参列表遍历 优先按照部门id从缓存取，如果缓存不存在再批量查询数据库，结果合并返回，同时限制入参id数量，最大不超过80个门店id，超过的只返回前80个; //（目前单个小区下门店最多为41个）

5.调整dubbo接口线程数，保护高并发下系统正常运行，threads=200--->threads=10

6.对于大促活动前需提前评估要压测的接口，并需要产品根据业务情况提供性能指标