MQ消息积压CPU打满导致不同服务接口超时异常

一、问题现象

一天突然收到线上不同MQ消息积压告警，于是去消息界面查看积压情况，同一个服务所在的多个MQ出现不同程度的积压，应该不是业务导致的正常积压，猜测可能是服务出了问题

二、问题排查 

1、依赖rpc接口超时

于是去查看服务日志，调用多个不同方的rpc接口都出现超时，应该不是提供方接口问题，因为不可能所有提供方接口都出现问题

2、MQ消费请求超时

再往下看，发现MQ消费请求也出现请求超时，找不到消息ID

Not found future which msgId is 45 when receive response. May be this future have been removed because of timeout

3、CPU超负荷

不同种类的服务的都出现超时，确定和服务本身没有关系，猜测可能和服务器本身有关系，于是去查看服务器资源使用情况，发现CPU达到了99%，出现了超负荷，问题终于找到了。

三、问题解决

CPU超负荷，于是赶紧申请8台新机器，增加服务部署数量，观察一会儿，CPU有所降低，达到90%做左右。但是还不够，又增加了8台新机器部署。再观察一会后，CPU降到70%多。前后增加16台机器部署，经过了1个多小时，终于消费完毕。

四、原因分析

此次消息积压，正直618前后，服务里边的消息包括不限于图片、商品、促销等5种消息类型。都是非常大的消息流，一次消息来袭少则几千条，多则三五十万条不等，加之正直618电商大促，各种图片、促销等消息量猛增。机器数量少，导致CPU超负荷，不能正常工作。从而出现大量内外部接口请求超时。简单总结如下：

1、时候原因

正直618大促前后，消息量大大高于平时

2、业务原因

消息本身体量量大，多个topic一次消息来袭少则几千条，多则三五十万条不等

3、服务设计原因

多个大体量消息融合部署-应该根据业务及量级，充分考虑拆分不同服务部署，不应该多种消息融合部署

4、消息量预估不足

应当提前预估每个业务消息量级，合理部署服务数量，充分做好备战准备

5、监控不足

因为不是核心服务，没能对CPU、网路、磁盘、内存等服务器硬件指标做好监控，做到及时发现解决问题，从而避免消息长时间积压