当前阶段，群聊已成为主流 IM 软件的基本功能，不管是亲属群，朋友群亦或是工作群，都是常见场景。随着移动互联网的发展，即时通讯服务被广泛应用于各个行业，客户业务快速发展，传统百人甚至千人上限的群聊已经无法满足很多业务发展需求，所以超大群的业务应运而生。
超大群面临的挑战
我们以一个万人群的模型进行举例：
1.如果群中有人发了消息，那么这条消息需要按照 1:9999 的比例进行分发投递，如果我们按照常规消息的处理流程，那么消息处理服务压力巨大。2.消息量大的情况下，服务端向客户端直推消息的处理速度将会成为系统瓶颈，而一旦用户的消息下发队列造成了挤压，会影响到正常的消息分发，也会导致服务缓存使用量激增。3.在微服务架构中，服务以及存储（DB，缓存）之间的 QPS 和网络流量也会急剧增高。4.以群为单位的消息缓存，内存和存储开销较大（消息体的存储被放大了万倍）。
基于这些挑战，我们的服务势必要做一定的优化来应对。
群消息分发模型
整体的群聊服务架构如下图所示：
用户在群里发了一条群消息后，消息先到群组服务，然后通过群组服务缓存的群关系，锁定这条消息最终需要分发的目标用户，然后根据一定的策略分发到消息服务上，消息服务再根据用户的在线状态和消息状态来判断这条消息是直推、通知拉取还是转 Push，最终投递给目标用户。
超大群消息分发解决方案
1.分发控速
第一，首先我们会根据服务器的核数来建立多个群消息分发队列，这些队列我们设置了不同的休眠时间以及不同的消费线程数，这里可以理解为快、中、慢等队列。如下图所示：
第二，我们根据群成员数量的大小来将所有群映射到相应的队列中，规则是小群映射到快队列中，大群映射到相应的慢队列中。第三，小群由于人数少，对服务的影响很小，所以服务利用快队列快速的将群消息分发出去，而大群群消息则利用慢队列的相对高延时来起到控速的作用。
2.合并分发
一条群消息发送到 IM 服务器后，需要从群组服务投递给消息服务，如果每一个群成员都投递一次，并且投递的群消息内容是一致的话，那肯定会造成相应的资源浪费和服务压力。
服务落点计算中我们使用的是一致性哈希，群成员落点相对固定，所以落点一致的群成员我们可以合并成一次请求进行投递，这样就大幅提高了投递效率同时减少了服务的压力。
3.超大规模群的处理方案
在实际群聊业务中，还有一种业务场景是超大规模群，这种群的群人数达到了数十万甚至上百万，这种群如果按照上述的分发方案，势必也会造成消息节点的巨大压力。比如我们有一个十万人的群，消息节点五台，消息服务处理消息的上限是一秒钟 4000 条，那每台消息节点大约会分到 2 万条群消息，这超出了消息节点的处理能力。
所以为了避免上述问题，我们的超大群（群成员上线超过 3000，可以根据服务器数量和服务器配置相应做调整）会用特殊的队列来处理群消息的分发，这个特殊的队列一秒钟往后端消息服务投递的消息数是消息服务处理上限的一半（留相应的能力处理其他消息），如果单台消息服务处理的 QPS 上限是 4000，那群组服务一秒往单台消息服务最多投递 2000 条。
写在最后
后续，我们也会针对群消息进行引用分发，对于大群里发的消息体比较大的消息，我们给群成员只分发和缓存消息的索引，比如 MessageID，等群成员真正拉取群消息时再从将消息组装好给客户端分发下去。这样做会节省分发的流量以及存储的空间。
随着互联网的发展，群组业务的模型和压力也在不停地扩展，后续可能还会遇到更多的挑战，届时我们服务器也会通过更优的处理方式来应对。
