im即时通讯开发：万人群聊消息

传统意义上的IM群聊，通常都是像微信这样的500人群，或者QQ的2000人群（QQ有3000人群，但那是单独收费的，也就意味着它并非无门槛标配，能用上的人并不多）。

自从国外某号称“世界上最安全的IM”搞出万人群聊之后，万人群迅速被国内的使用者们接受。伴随着移动互联网的发展，即时通讯服务被广泛应用于各个行业（以经不再局限于传统IM社交应用领域），随着业务快速发展，传统百人、千人上限的群聊已经无法满足很多业务场景需求，所以万人甚至十万人的超大群也算是相伴而生、顺应潮流。

 

IM群聊一直是IM应用中比较有难度的热点技术之一，通常意义的群聊，无非就是500人群、1000人群、2000人群这样，技术实现上比单聊要复杂不少。然而对于万人群聊（甚至十万人群聊）来说，相比百人、千人群聊，技术实现上那几乎是另一个技术维度的事情，难度要高很多。

与百人群、千人群相比，万人、甚至十万人超大群，大幅提升了群的触达人数，对于很多业务场景来说，好处不言而喻。

然而单群成员如此之大，给 IM 系统的流量冲击非常巨大，技术难度可想而之。我们先来分析一下超大群的技术挑战。

以一个万人群的模型为例：

1）如果群中有人发了消息，那么这条消息需要按照 1:9999 的比例进行分发投递，如果我们按照常规消息的处理流程，那么消息处理服务压力巨大；

2）消息量大的情况下，服务端向客户端直推消息的处理速度将会成为系统瓶颈，而一旦用户的消息下发队列造成了挤压，会影响到正常的消息分发，也会导致服务缓存使用量激增；

3）在微服务架构中，服务以及存储（DB，缓存）之间的 QPS 和网络流量也会急剧增高；

4）以群为单位的消息缓存，内存和存储开销较大（消息体的存储被放大了万倍）。

基于这些技术挑战，要想真正达成超大群的技术目标，势必要做特定的