现在IM群聊产品多种多样，有国民级的微信、QQ，企业级的钉钉、飞书，还有许多公司内部的IM工具，这些都是以客户端为主要载体，而且群聊人数通常都是有限制，微信正常群人数上限是500，QQ2000人，收费能达到3000人，这里固然有产品考量，但技术成本、资源成本也是很大的因素。而笔者业务场景上需要一个迭代更新快、轻量级（不依赖客户端）、单群百万群成员的纯H5的IM产品，本文将回顾实现一个百万人量级的群聊，服务器侧需要考虑的设计要点，希望可以给到读者一些启发。

不同的群聊产品，采用的技术方案是不同的，为了理解接下来的技术选型，需要先了解下这群聊产品的特性。

即时通信常见的通信技术有短轮询、长轮询、Server-Sent Events(SSE)、Websocket。短轮询和长轮询适用于实时性要求不高的场景，比如论坛的消息提醒。SSE 适用于服务器向客户端单向推送的场景，如实时新闻、股票行情。Websocket 适用于实时双向通信的场景，实时性好，且服务端、前端都有比较成熟的三方包，如 socket.io，所以这块在方案选择中是比较 easy 的，前后端使用 Websocket 来实现实时通信。

群聊消息的保存方式，主流有2种方式：读扩散、写扩散。图1展示了它们的区别，区别就在于消息是写一次还是写N次，以及如何读取。

写扩散就是每个群成员拥有独立的信箱，每产生一条消息，需要写入所有群成员信箱，群成员各自从自己的信箱内读取群消息。
优点是读取逻辑简单，适合消息定制化处理，不存在IO热点问题。缺点是写入效率低，且随着群成员数增加，效率降低；存储成本大。

所以当单群成员在万级以上时，用写扩散就明显不太合适了，写入效率太低，而且可能存在很多无效写入，不活跃的群成员也必须得有信箱，存储成本是非常大的，因此采用读扩散是比较合适的。

先来看看群聊的架构设计图，如图2所示：

从用户登录到发送消息，再到群用户收到这条消息的系统流程如图3所示：

1. 用户登录，通过负载均衡，与连接服务建立 Websocket 长连接。

2. 连接服务管理会话，管理群与用户的映射关系，在本地内存里使用哈希表存储，key为groupId，value为List<SocketIOClient>，同一个群的用户可能会在不同的集群服务器上。

3. 连接服务向群组服务上报群组路由，上报它的内网IP和它所管理的 groupIdList 的关系，这里需要2种同步策略并行保证群组路由信息的准确性：a.在用户建立、断开长连接时即刻上报；b.定时上报。

4. 群组服务管理群组路由，使用远程中心缓存 Redis 管理 groupId 和连接服务器IP的关系，key 为 groupId，value 为 List，该IP为连接服务的内网IP地址，这里会做上报的心跳判断，超过3个心跳周期不上报，则认为已断线。

5. 用户在群里发布一条消息，消息通过 Websokcet 送达连接服务，然后经过连接服务——>消息队列——>群组服务，消息在群组服务里经过频控、安全检查、格式转换等一系列流程后入库，持久化。

6. 群组服务通过群组路由管理获取这条消息所属群的路由信息，即一组连接服务的IP地址，然后通过 HTTP 回调对应的连接服务，通知它们有新消息产生，这里只简单传递消息ID。

7. 连接服务收到 HTTP 请求后，根据会话管理查询该群所有用户，给用户发送新消息提醒。

8. 用户收到新消息提醒，通过 Websocket 来连接服务拉取该新消息具体详情，然后根据消息协议展示在信息流里。

用户应该连接到哪一台连接服务呢？这个过程重点考虑如下2个问题：

1. 尽量保证各个节点的连接均衡；

2. 增删节点是否要做 Rebalance。

保证均衡有如下几个算法：

当应用在扩缩容或重启升级时，在该节点上的客户端怎么处理？
由于设计有心跳机制，当心跳不通或监听连接断开时，就认为该节点有问题了，就尝试重新连接；如果客户端正在发送消息，那么就需要将消息临时保存住，等待重新连接上后再次发送。

将连接服务里的IO线程与业务线程隔离，提升整体性能，原因如下：

在这样的场景中不像 HTTP 那样是无状态的，需要明确知道各个客户端和连接的关系。比如需要向客户端广播群消息时，首先得知道客户端的连接会话保存在哪个连接服务节点上，自然这里需要引入第三方中间件来存储这个关系。通过由连接服务主动上报给群组服务来实现，上报时机是客户端接入和断开连接服务以及周期性的定时任务。

设想这样一个场景：需要给群所有成员推送一条消息怎么做？
通过群编号去前面的路由 Redis 获取对应群的连接服务组，再通过 HTTP 方式调用连接服务，通过连接服务上的长连接会话进行真正的消息下发。

连接服务直接接收用户的上行消息，考虑到消息量可能非常大，在连接服务里做业务显然不合适，这里完全可以选择 Kafka 来解耦，将所有的上行消息直接丢到 Kafka 就不管了，消息由群组服务来处理。

为什么要讲消息顺序，来看一个场景。假设群里有用户A、用户B、用户C、用户D，下面以 ABCD 代替，假设A发送了3条消息，顺序分别是 msg1、msg2、msg3，但B、C、D看到的消息顺序不一致，如图4所示：

这时B、C、D肯定会觉得A在胡言乱语了，这样的产品用户必定是不喜欢的，因此必须要保证所有接收方看到的消息展示顺序是一致的。

所以先了解下消息发送的宏观过程：

1. 发送方发送消息。

2. 服务端接收消息。

3. 服务端返回 ACK 消息。

4. 服务端推送新消息或客户端拉取新消息。

在上面的过程中，都可能产生顺序问题，简要分析几点原因：

通过上面的分析可以知道，其实无法保证或是无法衡量不同用户之间的消息顺序，那么只需保证同一个用户的消息是有序的，保证上下文语义，所以可以得出一个比较朴素的实现方式：以服务端数据库的唯一自增ID为标尺来衡量消息的时序，然后让同一个用户的消息处理串行化。那么就可以通过以下几个技术手段配合来解决：

举例，图5表示服务端的消息顺序，图6表示用户端拉取消息时本地消息队列和提醒队列的变化逻辑。

1. t1时刻用户本地最新的完整消息是 msg1，即这条消息已经完整展示给用户。

2. t2时刻收到服务端推送的 msg3 新消息提醒，放到提醒队列，此时用户看不到这条消息。

3. t3时刻向服务端拉取消息详情，请求参数为 startId：msg1，endId：msg3，服务端会按顺序一起返回2个消息区间内的所有消息的详情即 msg2、msg4、msg3，将消息详情同步写入到消息队列，此时用户可以看到刷新出3条消息。

4. t4时刻用户还会收到 msg2、msg4 的新消息提醒，用户端校验消息队列已经存在 msg2、msg4 的详情，忽略该新消息提醒。

在IM系统中，消息的可靠性同样非常重要，它主要体现在：

1. 传输协议保障：首先 TCP 是可靠的协议，能较大程度上保证消息不丢失。

2. 增加ACK机制：服务端在执行完消息处理的所有流程后，给发送者发送 ACK；假如发送者在超时时间内没有收到 ACK 消息，则进行一定次数的重试，重新发送；当重发次数超过预设次数，就不再重发，消息发送失败。

3. 最终一致性：这是对接收者而言，如果某条新消息提醒因网络等其他原因丢失，用户没有收到这条消息提醒，那么用户就不会去拉消息详情，在用户视角就是没有看到这条消息。但是当后续的新消息提醒送达时，可以依赖前面提到的拉取机制拿到一个区间内的消息列表，这里就包含了丢失的消息，因此能达到最终一致性。

为了提醒用户有新消息，需要给用户展示新消息提醒标识，产品设计上一般有小红点、具体的数值2种方式。具体数值比小红点要复杂，这里分析下具体数值的处理方式，还需要分为初始打开群和已打开群2个场景。

如上图8所示，每个群都会构建一个长度为100，score 和 member 都是消息ID，可以通过 zrevrank 命令得到某个 offset 的排名值，该值可以换算成未读数。比如：用户1在群89的未读消息数，'zrevrank 89 1022' = 2，也就是有2条未读数。用户2在群89的未读数，'zrevrank 89 890' = nil，那么未读数就是99+。同时消息新增、删除都需要同步维护该数据结构，失效或不存在时从 MySQL 初始化。

当同时在线用户数非常多，例如百万时，会面临如下几个问题：

1. 消息发送风暴：极端情况下，用户同时发送消息，假设服务端承载住了这些流量，那么瓶颈其实在用户端，第一用户端会经历网络风暴，网卡带宽能否支撑是一个大问题；第二假设网卡能通过这些流量，用户端上百万条消息该如何展示，要是瞬间刷出这些消息，用户端 CPU能否撑住又是个问题，即使能抗住用户体验也很糟糕，根本就看不清消息，一直在飞速刷屏。因此服务端可以在发送消息风暴时做好限流、丢弃策略，给到用户友好的提示。

2. 消息提醒风暴：一条新消息的产生，就要推送提醒消息百万次，对服务器来说，要考量整体推送完成的时效性，如果时效性差，对有些用户来说，就是消息需要较长时间才刷出来，出现明显的延迟。新消息持久化后，群组服务 HTTP 回调一组连接服务，单群百万在线用户，需要50台连接服务集群，那么回调50次，为了保证时效性，因此这里要并发回调，并设置合理的线程池，然后连接服务收到回调后也需要并发完成对群用户的新消息提醒推送。

3. 消息拉取风暴：连接服务收到拉取消息事件，需要去群组服务获取消息详情，QPS 就非常高了，理论上集群达到 100wQPS，20台群组服务，那么每台群组服务就是 5wQPS。这里的策略是在链路前端连接服务上进行流量过滤，因为用户都是请求同一个群的同一条消息或附近的消息，那么就可以在连接服务里设计群消息的本地缓存，所有用户都只从本地缓存里读，如果本地缓存里没有，就放一个线程去群组服务请求加载缓存，其他线程同步等待，这样就大大降低了打到群组服务的 QPS。

在本文中，笔者介绍了从零开始搭建一个生产级百万级群聊的一些关键要点和实践经验，包括通信方案选型、消息存储、消息顺序、消息可靠性、高并发等方面，但仍有许多技术设计未涉及，比如冷热群、高低消息通道会放在未来的规划里。IM开发业界没有统一的标准，不同的产品有适合自己的技术方案，希望本文能够带给读者更好地理解和应用这些技术实践，为构建高性能、高可靠性的群聊系统提供一定的参考。

粉丝福利

vivo互联网技术为开发者朋友们提供了 iQOO & NBA 联名款周边（各1个），快来领取吧！

✦

✦

✦

iQOO x NBA 联名洗漱包 x1

iQOO x NBA 联名运动水杯 x1

参与方法：

转发本篇内容到朋友圈，截图保存界面，再到vivo互联网技术微信后台发送“v爱技术”参与抽奖，上传截图即可。（请保留朋友圈分享链接至开奖当天）

开奖时间：2024年2月28日 20:00

奖品将通过邮寄发放，中奖者需在5天内提供收货信息。(联系本号后台）

注意：

1.我们将会通过人工审核截图进行校对。未及时提供收货信息或未完成所有步骤的参与者将视为自动放弃。

2. 活动解释权归vivo互联网技术所有。