im即时通讯开发：群消息推送如何保证实时性

众所周之，群聊是移动端IM的服务端技术难点所在，难在哪？大量的群聊消息，是一条条推给群内成员还是可以使用什么样的优化策略？试想一个2000人大群，一条消息的发出，如果瞬间被扩散写成2000条一对一消息的投递，对于接收方而言不过是一条消息而已，而服务端是以对相对比单聊消息的2000倍处理压力后的结果。那么服务端在保证消息投递的同时，面对这么大的压力该如何解决好效率问题？解决不好效率问题那实时性就不能保证！

当然，实际在生产环境下，群消息的发送都会想尽办法进行压缩，并开展各种改善性能的处理办法，而不是像上述举例里的直接扩散写（即2000人群里，一条消息被简单地复制为2000条一对一的消息投递）。

先大致分析一下问题产生的原因。

1）消息量瞬间大增：

抢红包时大家都比较活跃，不停在群里发消息，尤其群成员比较多的群（500人），每条消息都会给服务端带来大量的计算工作。

2）后台逻辑不够优化：

比如红包消息没有单独的通道，时效性会收到其他消息影响、没有采用批处理方式、异步处理有些环节还不到位等等。

精确定位问题的原因

我们尝试精确定位问题的根本原因，原因分析如下。

1）c2g模块没有采取批处理方式：

1条群（500人群）消息到达c2g模块后，c2g模块为每个人写收件箱（这里时间延迟较大，优化点），然后在把这条消息变成500条投递消息（需要批处理，就给Kafka放入一条消息），通过Kafka送给Deliver节点投递。
 

2）Deliver模块的处理没有批量合并：

Deliver模块会到Redis中逐条（500条）检索接收消息用户的在线状态（这个点需要批处理