共计 1722 个字符，预计需要花费 5 分钟才能阅读完成。
传统意义上的 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 条。
