融云IM技术分享：万人群聊消息投递方案的思考和实践

本文由融云技术团队原创分享，原题“技术实践丨万人群聊的消息分发控速方案”，为使文章更好理解，内容有修订。

1、引言

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

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


▲ “纸飞机”的万人群（开发人员颤抖中...）

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

本文根据融云技术团队的实践经验，总结了万人群聊消息投递方案的一些思考和实践，希望能给你带来启发。



本文已同步发布于“即时通讯技术圈”公众号，欢迎关注。公众号上的链接是：点此进入。

2、相关文章

万人群聊有关的技术文章还可读一读以下这篇：

• 《网易云信技术分享：IM中的万人群聊技术方案实践总结》
• 《企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等》
• 《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》
  

融云技术团队分享的其它文章：

• 《融云技术分享：融云安卓端IM产品的网络链路保活技术实践》
• 《融云技术分享：全面揭秘亿级IM消息的可靠投递机制》
• 《融云技术分享：基于WebRTC的实时音视频首帧显示时间优化实践》
• 《IM消息ID技术专题(三)：解密融云IM产品的聊天消息ID生成策略》
• 《IM开发干货分享：浅谈IM系统中离线消息、历史消息的最佳实践》
  

3、超大群面临的技术挑战

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

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

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

• 1）如果群中有人发了消息，那么这条消息需要按照 1:9999 的比例进行分发投递，如果我们按照常规消息的处理流程，那么消息处理服务压力巨大；
• 2）消息量大的情况下，服务端向客户端直推消息的处理速度将会成为系统瓶颈，而一旦用户的消息下发队列造成了挤压，会影响到正常的消息分发，也会导致服务缓存使用量激增；
• 3）在微服务架构中，服务以及存储（DB，缓存）之间的 QPS 和网络流量也会急剧增高；
• 4）以群为单位的消息缓存，内存和存储开销较大（消息体的存储被放大了万倍）。
  

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

4、一般群聊的消息投递模型

先来看看普通群聊的消息投递模型。

我们的普通群聊消息投递模型如下图所示：


如上图所示，当用户在普通群里发了一条消息后，投递路径是：

• 1）消息先到群组服务；
• 2）然后通过群组服务缓存的群关系，锁定这条消息最终需要分发的目标用户；
• 3）再根据一定的策略分发到消息服务上；
• 4）消息服务再根据用户的在线状态和消息状态来判断这条消息是直推、通知拉取还是转 Push，最终投递给目标用户。
  

普通群聊的消息投递，正像您期待的那样，基本上大家的实现手段都大差不差。然而对于万人群来说，这显然还不够。

下面来看看我们针对万人群聊消息投递的技术优化手段。

5、万人群聊消息投递优化手段1：控速

针对万人群的消息投递，我们的一个主要手段就是控速。



如上图所示。

首先：我们会根据服务器的核数来建立多个群消息分发队列，这些队列我们设置了不同的休眠时间以及不同的消费线程数。

通俗来讲，可以将队列这样划分为快、中、慢等队列。

其次：我们根据群成员数量的大小来将所有群映射到相应的队列中。

规则是：

• 1）小群映射到快队列中；
• 2）大群映射到相应的慢队列中。
  

然后：小群由于人数少，对服务的影响很小，所以服务利用快队列快速的将群消息分发出去，而大群群消息则利用慢队列的相对高延时来起到控速的作用。

6、万人群聊消息投递优化手段2：合并

在本文第3节中提到的万人群聊所面临的技术挑战，最主要的挑战其实就是消息进行扩散分发投递后，消息被克隆出N条，消息流量瞬间被放大。

举个例子：当一条群消息发送到 IM 服务器后，需要从群组服务投递给消息服务，如果每一个群成员都投递一次，并且投递的群消息内容是一致的话，那肯定会造成相应的资源浪费和服务压力。

那么针对这种情况，我们的解决方案就是进行消息合并投递。

原理就是：服务落点计算中我们使用的是一致性哈希，群成员落点相对固定，所以落点一致的群成员我们可以合并成一次请求进行投递，这样就大幅提高了投递效率同时减少了服务的压力。

下图是云信团队分享的万人群消息合并投递逻辑：

▲ 上图引用自《IM中的万人群聊技术方案实践总结》

如上图所示，云信团队的万人群消息合并投递方案是：按Link分组路由消息，同一Link上的全部群成员只需要路由一条消息即可。

7、十万、百万级的超大群处理方案

在实际群聊业务中，还有一种业务场景是超大规模群，这种群的群人数达到了数十万甚至上百万。

这种群如果按照上述的投投递方案，势必仍会造成消息节点的巨大压力。

比如我们有一个十万人的群，消息节点五台，消息服务处理消息的上限是一秒钟 4000 条，那每台消息节点大约会分到 2 万条群消息，这已大大超出了消息节点的处理能力。

所以为了避免上述问题，我们会将群成员上线超过3000的群识别为万人群、超级群，这种级别的群可以根据服务器数量和服务器配置相应做调整针对这种超级群会用特殊的队列来处理群消息的投递。

这个特殊的队列1秒钟往后端消息服务投递的消息数是消息服务处理上限的一半（留相应的能力处理其他消息），如果单台消息服务处理的 QPS 上限是 4000，那群组服务一秒往单台消息服务最多投递 2000 条。

8、写在最后

未来，我们也会针对群消息进行引用投递，对于大群里发的消息体比较大的消息，我们给群成员只分发和缓存消息的索引，比如 MessageID。等群成员真正拉取群消息时再从将消息组装好给客户端分发下去。这样做会节省分发的流量以及存储的空间。

随着互联网的发展，群组业务的模型和压力也在不停地扩展，后续可能还会遇到更多的挑战，当然也会不断迭代出更优的处理方式来应对。

附录：更多IM群聊技术文章

《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《如何保证IM实时消息的“时序性”与“一致性”？》
《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》
《IM群聊消息如此复杂，如何保证不丢不重？》
《微信后台团队：微信后台异步消息队列的优化升级实践分享》
《移动端IM中大规模群消息的推送如何保证效率、实时性？》
《现代IM系统中聊天消息的同步和存储方案探讨》
《关于IM即时通讯群聊消息的乱序问题讨论》
《IM群聊消息的已读回执功能该怎么实现？》
《IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？》
《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》
《[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗？》
《IM群聊机制，除了循环去发消息还有什么方式？如何优化？》
《网易云信技术分享：IM中的万人群聊技术方案实践总结》
《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》
《IM群聊消息的已读未读功能在存储空间方面的实现思路探讨》
《直播系统聊天技术(一)：百万在线的美拍直播弹幕系统的实时推送技术实践之路》
《直播系统聊天技术(二)：阿里电商IM消息平台，在群聊、直播场景下的技术实践》
《直播系统聊天技术(三)：微信直播聊天室单房间1500万在线的消息架构演进之路》
《直播系统聊天技术(四)：百度直播的海量用户实时消息系统架构演进实践》
《企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等》
《融云IM技术分享：万人群聊消息投递方案的思考和实践》
>> 更多同类文章 ……

JackJiang大佬好，由于我本身不是做服务端开发的，所以对文章中提及的几个地方有些疑问，烦请您能帮忙解答一下

引用：服务落点计算中我们使用的是一致性哈希，群成员落点相对固定，所以落点一致的群成员我们可以合并成一次请求进行投递，这样就大幅提高了投递效率同时减少了服务的压力。

这里是说IM服务集群下有多个服务，比如5个，通过计算得出同一个群的群成员分别落在哪一个服务上，这样发送消息时只需要投递到这几个服务上，
然后由这几个服务再分发给对应的群成员吗？这样就把原本1:9999的消息分发分散为9999/5以减轻压力是吧？

引用：1秒钟往后端消息服务投递的消息数是消息服务处理上限的一半（留相应的能力处理其他消息），如果单台消息服务处理的 QPS 上限是 4000，那群组服务一秒往单台消息服务最多投递 2000 条。

就是通过识别超大群，针对这种超大群进行限流，限流标准是1秒钟投递的消息数最多只允许到达消息服务处理上限的一半，避免到达瓶颈是吧？

引用：椎锋陷陈 发表于 2021-08-31 09:28
JackJiang大佬好，由于我本身不是做服务端开发的，所以对文章中提及的几个地方有些疑问，烦请您能帮忙解答 ...

那上面说的落点，其实不太靠谱，因为一个用户有好多群，该以哪个群计算落点这显然没法固定。
识别大群这个大致是这样。

干货

引用：JackJiang 发表于 2021-08-31 09:38
那上面说的落点，其实不太靠谱，因为一个用户有好多群，该以哪个群计算落点这显然没法固定。
识别大群这 ...

落点我是这么理解的，每个用户长连所在的机器对于他们的架构来说是固定的，优化前一条消息从投递服务一条消息到长连服务，优化后合并了uids。

融云？！？

引用：beijingit 发表于 2021-09-16 16:19
融云？！？

有啥问题

引用：JackJiang 发表于 2021-09-16 17:01
有啥问题

它家的国产化即时通水平太差，优化了半年，就搞不定两万用户树，加载速度超一分钟，特别的佩服。

能不能说说消息队列订阅的思路呢，不同的群聊进入同一个队列的话，那我是所有的IM服务都需要订阅所有的队列么?还是有针对性的订阅呢？

引用：beijingit 发表于 2021-10-13 10:53
它家的国产化即时通水平太差，优化了半年，就搞不定两万用户树，加载速度超一分钟，特别的佩服。

哈哈哈，真的啊

它家的国产化即时通水平太差，优化了半年，就搞不定两万用户树，加载速度超一分钟，特别的佩服。
本来想研究下,算了

引用：服务落点计算中我们使用的是一致性哈希，群成员落点相对固定，所以落点一致的群成员我们可以合并成一次请求进行投递，这样就大幅提高了投递效率同时减少了服务的压力。

我理解的是 根据 群id 落点到同一组或一台服务

引用：Frank 发表于 2023-02-21 23:24
它家的国产化即时通水平太差，优化了半年，就搞不定两万用户树，加载速度超一分钟，特别的佩服。
本来想研 ...

买的融云私有化部署？