第一版红包功能上线后，收集到不少问题。核心问题是消息延迟，导致有些人先看到红包，有些人晚看到红包，同时导致消息顺序混乱。
分析一下问题产生的原因：
消息量瞬间大增。抢红包时大家都比较活跃，不停在群里发消息，尤其群成员比较多的群（500人），每条消息都会给服务端带来大量的计算工作。
后台逻辑不够优化。比如红包消息没有单独的通道，时效性会受到其他消息影响；没有采用批处理方式；异步处理有些环节还不到位。
先看一下系统架构和消息处理流程（如下图）：
精确定位问题：
c2g模块没有采取批处理方式。1条群（500人群）消息到达c2g模块后，c2g模块为每个人写收件箱（这里时间延迟较大，优化点），然后将这条消息变成500条投递消息（需要批处理，就给Kafka放入一条消息），通过Kafka送给Deliver节点投递。
Deliver模块，会到Redis中逐条（500条）检索接收消息用户的在线状态（这个点需要批处理，根据用户Id分布，一次检索若干用户的在线状态），在线的投递消息（批处理），离线的发送第三方push（批处理）。
整体流程上，每条消息是先写了离线收件箱，再推送。这样效率也不高，需要对这个流程细化以及异步化。
看一看微信在这个逻辑上的一些优化思想：
微信在这块的一个重要优化思想是批处理，腾讯的做法是单次批量操作（我们本次优化目标）裸写，多条消息的聚合（MapReduce过程）下沉到了MQ中间件中。
具体怎么做：
- 红包逻辑单独部署
现阶段，当消息（尤其是大群消息）量大的时候，Deliver节点会成为瓶颈。红包对时效性要求很高，架构上采用独立为红包部署Deliver节点的方式确保红包消息走单独通道进行推送。即使其他消息出现延迟，红包消息依然能保证及时送达。
- 裸写批处理逻辑
处理一条群消息，服务端要进行大量的工作，需要查询所有群成员的路由表、在线状态，在线人员需要推送及时消息，离线人员需要推送第三方push（比如IOS的apns）。这些工作逐条执行，性能会非常差，如果遇到大群，系统会不可用。
批处理可以较好解决这个问题。比如用户状态及路由表数据，采用hash算法分布在几台服务器上。收到群消息后，根据群成员，计算出用户状态及路由表数据的分布情况，从缓存服务器中一次检索出该服务器可能存在的所有群成员状态及路由信息。这样可以极大减少RPC调用次数，及计算量。
推送操作也类似，批量向接入层投递消息即可。
- 离线消息异步写收件箱
在处理大群消息推送时，写离线消息也是一个非常影响性能的地方。现有的逻辑是先为每个人写一条离线消息，再执行推送。这样做的初衷是确保消息投递绝对可靠（参看《一个海量在线用户即时通讯系统（IM）的完整设计》的离线消息章节）。由于大群人数较多，写离线消息也有较多时间开销。
优化思路是现将消息及时推送给用户，再异步写离线消息，同时处理好写离线消息和推送消息的ack时序。
具体步骤如下图：
（1）Deliver节点收到一条群消息，检索用户在线状态及路由信息，用户在线（离线的逻辑相对简单，略过）
（2）批量推送消息（2、批处理逻辑）
（3）异步将消息写入消息总线，同时写入第三方push的延迟推送任务
（4）异步写离线消息（不影响在线用户收到消息的速度）
（5）第（2）步推送消息的ack信息回到服务端
（6）c2g模块将ack信息放入消息总线。（确保消息时序性，ack需要在写离线消息之后处理，否则可能出现消息重复）
（7）删除对应的离线消息
（8）第（3）步写入的延迟推送任务，在规定时间（如10秒）后生效，判断是否存在此条离线消息（如果ack回来了，离线消息会被删掉），如果离线消息还存在，发送第三方push
通过以上3个方面的优化，能够确保在并发消息量较大时，推送消息依然及时。
相关阅读：
基于消息总线的高可扩展性IM系统后台架构设计
IM系统海量消息数据是怎么存储的？
一个海量在线用户即时通讯系统（IM）的完整设计
