一次线上问题记录，以及后续优化思路梳理

        当天上午10点左右有部分客户反馈收不到消息，看日志一直再报消息数量超限，当时没有当回事，因为这种错误每天都有，当一个客户同时发消息超过5条，wX就会返回发送消息超过5条消息错误。到了中午吃饭时，有大量商户出现这种报错，才意识到问题的严重性，开始着手排查。最后发现是因为大量商户活动消息进入到消息队列造成消息堆积，用户发送聊天消息一直消费不到，导致大批量商户无法正常聊天。最后经过一下午折腾总算是解决了，然而只是临时解决，风险依然存在。

线上问题梳理：

1、商户搞活动运营没有报备，而WX的机制是所有消息都会推到一个队列里，对于直接影响方，没有收到任何的通知。

2、系统吞吐量太小，消费消息太慢。这套老系统的消费机制是消息发送端6个线程将消息推送到这个系统，而这个系统没有做任何的缓冲。用户首条消息消费的链路是很长的。

首条消息执行完成至少需要200ms，更可怕的是老系统的消息消费逻辑是同步的，tps最多仅有30。如果消息队列里有6千条用户首条消息，消费完所有消息至少需要200s，这样的吞吐量可以用龟速来形容。

3、这套系统采用的是单核架构。所有模块公用资源，核心模块使用资源受限，无法根据模块的需要进行伸缩。即便你将pod数量扩充数倍，但核心模块可使用的资源依然很有限。而且单核应用可靠性很差，任何一个模块出现如死循环、内存溢出等导致pod崩溃情况，都会使整个系统不可用。已经2022年了还能看到这种应用确实令人诧异。

优化放案：

1、大客户运营活动要及时报备给相关系统

2、修改消息消费机制，由消费端同步推送消息改为系统主动去队列拉取消息

3、修改消息处理逻辑，在拉到消息后仅对消息进行解析和常规校验，其他操作改为异步执行

4、拆分系统，将单核系统根据业务拆分成  会话消息、分配引擎、用户信息、系统配置、报表统计五个服务

5、修改首条消息处理逻辑，将创建用户和创建会话流程前置，用户点击聊天按钮时即创建临时会话。

原逻辑

新逻辑：将创建/新增动作前置：

        消费消息新逻辑：

        增加消费分配结果逻辑：