本文由融云技术团队原创分享，原题“技术实际丨万人群聊的音讯散发控速计划”，为使文章更好了解，内容有订正。
1、引言
传统意义上的 IM 群聊，通常都是像微信这样的 500 人群，或者 QQ 的 2000 人群（QQ 有 3000 人群，但那是独自免费的，也就意味着它并非无门槛标配，能用上的人并不多）。
自从国外某号称“世界上最平安的 IM”搞出万人群聊之后，万人群迅速被国内的使用者们承受。随同着挪动互联网的倒退，即时通讯服务被广泛应用于各个行业（以经不再局限于传统 IM 社交应用领域），随着业务疾速倒退，传统百人、千人下限的群聊曾经无奈满足很多业务场景需要，所以万人甚至十万人的超大群也算是相伴而生、顺应潮流。
▲“纸飞机”的万人群（开发人员颤动中 …）
IM 群聊始终是 IM 利用中比拟有难度的热点技术之一，通常意义的群聊，无非就是 500 人群、1000 人群、2000 人群这样，技术实现上比单聊要简单不少。然而对于万人群聊（甚至十万人群聊）来说，相比百人、千人群聊，技术实现上那简直是另一个技术维度的事件，难度要高很多。
本文依据融云技术团队的实践经验，总结了万人群聊音讯投递计划的一些思考和实际，心愿能给你带来启发。
学习交换：
- 即时通讯 / 推送技术开发交换 5 群：215477170 [举荐]
- 挪动端 IM 开发入门文章：《新手入门一篇就够：从零开发挪动端 IM》
- 开源 IM 框架源码：https://github.com/JackJiang2…
（本文同步公布于：http://www.52im.net/thread-36…）
2、相干文章
万人群聊无关的技术文章还可读一读以下这篇：
《网易云信技术分享：IM 中的万人群聊技术计划实际总结》
《企业微信的 IM 架构设计揭秘：音讯模型、万人群、已读回执、音讯撤回等》
《阿里钉钉技术分享：企业级 IM 王者——钉钉在后端架构上的过人之处》
融云技术团队分享的其它文章：
《融云技术分享：融云安卓端 IM 产品的网络链路保活技术实际》
《融云技术分享：全面揭秘亿级 IM 音讯的牢靠投递机制》
《融云技术分享：基于 WebRTC 的实时音视频首帧显示工夫优化实际》
《IM 音讯 ID 技术专题(三)：解密融云 IM 产品的聊天音讯 ID 生成策略》
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 技术分享：万人群聊音讯投递计划的思考和实际》
本文已同步公布于“即时通讯技术圈”公众号。
同步公布链接是：http://www.52im.net/thread-36…