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生成策略》
3、超大群面临的技术挑战
与百人群、千人群相比，万人、甚至十万人超大群，大幅提升了群的触达人数，对于很多业务场景来说，好处不言而喻。
然而单群成员如此之大，给 IM 系统的流量冲击非常巨大，技术难度可想而知。我们先来分析一下超大群的技术挑战。
以一个万人群的模型为例：
1）如果群中有人发了消息，那么这条消息需要按照 1:9999 的比例进行分发投递，如果我们按照常规消息的处理流程，那么消息处理服务压力巨大；
2）消息量大的情况下，服务端向客户端直推消息的处理速度将会成为系统瓶颈，而一旦用户的消息下发队列造成了挤压，会影响到正常的消息分发，也会导致服务缓存使用量激增；
3）在微服务架构中，服务以及存储（DB，缓存）之间的 QPS 和网络流量也会急剧增高；
4）以群为单位的消息缓存，内存和存储开销较大（消息体的存储被放大了万倍）。
基于这些技术挑战，要想真正达成超大群的技术目标，势必要做特定的技术优化来应对。
| 留言与评论（共有 0 条评论） “” |
