传统意义上的IM群聊，通常都是像微信这样的500人群，或者QQ的2000人群（QQ有3000人群，但那是单独收费的，也就意味着它并非无门槛标配，能用上的人并不多）。
自从国外某号称“世界上最安全的IM”搞出万人群聊之后，万人群迅速被国内的使用者们接受。伴随着移动互联网的发展，即时通讯服务被广泛应用于各个行业（以经不再局限于传统IM社交应用领域），随着业务快速发展，传统百人、千人上限的群聊已经无法满足很多业务场景需求，所以万人甚至十万人的超大群也算是相伴而生、顺应潮流。
IM群聊一直是IM应用中比较有难度的热点技术之一，通常意义的群聊，无非就是500人群、1000人群、2000人群这样，技术实现上比单聊要复杂不少。然而对于万人群聊（甚至十万人群聊）来说，相比百人、千人群聊，技术实现上那几乎是另一个技术维度的事情，难度要高很多。
与百人群、千人群相比，万人、甚至十万人超大群，大幅提升了群的触达人数，对于很多业务场景来说，好处不言而喻。
然而单群成员如此之大，给 IM 系统的流量冲击非常巨大，技术难度可想而之。我们先来分析一下超大群的技术挑战。
以一个万人群的模型为例：
1）如果群中有人发了消息，那么这条消息需要按照 1:9999 的比例进行分发投递，如果我们按照常规消息的处理流程，那么消息处理服务压力巨大；
2）消息量大的情况下，服务端向客户端直推消息的处理速度将会成为系统瓶颈，而一旦用户的消息下发队列造成了挤压，会影响到正常的消息分发，也会导致服务缓存使用量激增；
3）在微服务架构中，服务以及存储（DB，缓存）之间的 QPS 和网络流量也会急剧增高；
4）以群为单位的消息缓存，内存和存储开销较大（消息体的存储被放大了万倍）。
基于这些技术挑战，要想真正达成超大群的技术目标，势必要做特定的技术优化来应对。
先来看看普通群聊的消息投递模型。
当用户在普通群里发了一条消息后，投递路径是：
1）消息先到群组服务；
2）然后通过群组服务缓存的群关系，锁定这条消息最终需要分发的目标用户；
3）再根据一定的策略分发到消息服务上；
4）消息服务再根据用户的在线状态和消息状态来判断这条消息是直推、通知拉取还是转 Push，最终投递给目标用户。
普通群聊的消息投递，正像您期待的那样，基本上大家的实现手段都大差不差。然而对于万人群来说，这显然还不够。即时通讯聊天软件开发可以咨询蔚可云。
首先：我们会根据服务器的核数来建立多个群消息分发队列，这些队列我们设置了不同的休眠时间以及不同的消费线程数。
通俗来讲，可以将队列这样划分为快、中、慢等队列。
其次：我们根据群成员数量的大小来将所有群映射到相应的队列中。
规则是：
1）小群映射到快队列中；
2）大群映射到相应的慢队列中。
然后：小群由于人数少，对服务的影响很小，所以服务利用快队列快速的将群消息分发出去，而大群群消息则利用慢队列的相对高延时来起到控速的作用。
当一条群消息发送到 IM 服务器后，需要从群组服务投递给消息服务，如果每一个群成员都投递一次，并且投递的群消息内容是一致的话，那肯定会造成相应的资源浪费和服务压力。
那么针对这种情况，我们的解决方案就是进行消息合并投递。
原理就是：服务落点计算中我们使用的是一致性哈希，群成员落点相对固定，所以落点一致的群成员我们可以合并成一次请求进行投递，这样就大幅提高了投递效率同时减少了服务的压力。
十万、百万级的超大群处理方案
在实际群聊业务中，还有一种业务场景是超大规模群，这种群的群人数达到了数十万甚至上百万。
这种群如果按照上述的投投递方案，势必仍会造成消息节点的巨大压力。
比如我们有一个十万人的群，消息节点五台，消息服务处理消息的上限是一秒钟 4000 条，那每台消息节点大约会分到 2 万条群消息，这已大大超出了消息节点的处理能力。
所以为了避免上述问题，我们会将群成员上线超过3000的群识别为万人群、超级群，这种级别的群可以根据服务器数量和服务器配置相应做调整针对这种超级群会用特殊的队列来处理群消息的投递。
这个特殊的队列1秒钟往后端消息服务投递的消息数是消息服务处理上限的一半（留相应的能力处理其他消息），如果单台消息服务处理的 QPS 上限是 4000，那群组服务一秒往单台消息服务最多投递 2000 条。