在IM群聊产品中群组人数上限通常受到严格限制。微信正常群人数上限为500人QQ为2000人收费版本可达3000人。这里固然有产品层面的考量但技术成本和资源压力才是更深层的原因。当单个群组需要支撑百万人同时在线时技术挑战便从业务问题上升为系统架构的极限考验。本文将基于vivo互联网服务器团队的真实实践系统梳理构建百万级Web端群聊系统时需要解决的核心技术问题包括通信方案选型、消息存储模式、消息有序性保障、消息可靠性投递以及未读数统计等关键设计。一、产品场景与技术目标本文讨论的场景是一个纯H5承载的Web端IM产品要求单群成员支撑百万人、同时在线百万级且功能体验要接近纯客户端实现方案。这种轻量级、迭代快的业务特征决定了技术选型与传统的客户端IM有着本质差异。在实时通信技术选型方面短轮询和长轮询适用于实时性要求不高的场景SSE适用于服务器向客户端单向推送而WebSocket适用于实时双向通信实时性好且服务端和前端都有成熟的三方包支持。对于百万级群聊场景前后端使用WebSocket实现实时通信是必然选择。二、消息分发模式读扩散与写扩散的权衡群聊消息的分发方式直接决定了系统的存储成本、写入性能和功能扩展能力。主流方案分为读扩散和写扩散两种模式。2.1 写扩散模式写扩散模式下每个群成员拥有独立的信箱。每产生一条消息需要写入所有群成员的信箱群成员各自从自己的信箱内读取群消息。优点读取逻辑简单适合消息定制化处理不存在IO热点问题。例如展示用户对消息的已读未读状态、用户删除某条消息而其他人仍可见等场景实现起来相对直接。缺点写入效率低且随着群成员数增加效率降低存储成本大。百万人群一条消息需要写入百万次这种写入放大效应在超大群中不可接受。据了解微信采用写扩散模式但微信群设定为500人上限写扩散的缺点在有限群规模下影响较小。2.2 读扩散模式读扩散模式下所有群成员共用一个群信箱。当一个群产生一条消息时只需要写入这个群的信箱所有群成员从这一个信箱里读取群消息。优点写入逻辑简单存储成本低写入效率高。缺点读取逻辑相对复杂需要通过消息表与其他业务表聚合消息定制化处理复杂需要额外的业务表支持可能存在IO热点问题。当单群成员在万级以上时写扩散明显不太合适。写入效率太低且可能存在很多无效写入不活跃的群成员也必须拥有信箱存储成本极大。因此在百万级群成员场景下读扩散是必然选择。野火IM的超级群组方案同样采用读扩散模式理论上可支持无限制的群组成员和群消息量。三、整体架构设计3.1 核心组件百万级群聊系统采用分层架构设计各组件职责明确。连接服务是用户接入的第一层负责与客户端建立WebSocket长连接管理会话状态。连接服务在本地内存中使用哈希表维护群与用户的映射关系key为groupIdvalue为用户连接列表。需要注意的是同一个群的用户可能分布在不同的集群服务器上。群组服务负责管理群组路由信息接收连接服务上报的群组路由关系管理groupId与连接服务器内网IP的对应关系同时完成消息的频控、安全检查、格式转换等预处理。消息队列在连接服务与群组服务之间起到解耦和削峰的作用。连接服务收到用户消息后先写入消息队列群组服务从中消费处理有效应对百万级用户的并发写入。群组路由管理使用Redis作为远程中心缓存存储groupId与连接服务IP列表的映射关系并实现心跳检测机制超过3个心跳周期未上报则认为连接服务已断线。3.2 消息收发流程用户登录后通过负载均衡与连接服务建立WebSocket长连接。连接服务向群组服务上报群组路由信息包括其内网IP和所管理的groupId列表。为保证路由信息准确性采用两种策略并行用户在建立或断开长连接时即刻上报以及定时上报。用户发送消息时消息通过WebSocket送达连接服务再经过消息队列到达群组服务。消息在群组服务中经过频控、安全检查和格式转换后入库持久化。群组服务通过群组路由管理获取消息所属群的路由信息即一组连接服务的IP地址然后通过HTTP回调对应的连接服务通知它们有新消息产生此时只传递消息ID。连接服务收到HTTP请求后根据会话管理查询该群所有用户通过WebSocket下发新消息提醒。用户收到提醒后主动通过WebSocket拉取新消息详情根据消息协议展示在信息流中。这种推拉结合的方案核心是推送通知、拉取内容有效降低了服务端的推送压力同时避免了大量无效数据在连接上传输。四、消息有序性保障4.1 乱序问题的本质在群聊系统中消息乱序是一个必须解决的核心问题。如果群里有A、B、C、D四个用户A发送了三条消息顺序分别是MSG1、MSG2、MSG3但不同用户看到的消息顺序不一致产品体验将完全不可接受。乱序产生的主要原因是网络延迟差异、多服务器处理时序差异以及客户端拉取时机差异。4.2 推拉结合的解决方案采用推拉结合的方式来解决消息顺序问题。服务端为消息赋予全局递增序列号作为顺序的唯一依据。客户端维护本地消息队列和提醒队列的分隔设计。T1时刻用户本地最新的完整消息是MSG1已完整展示。T2时刻收到服务端推送的MSG2、MSG3、MSG4的新消息提醒先放入提醒队列此时用户看不到这些消息。T3时刻客户端向服务端拉取消息详情将消息详情同步写入消息队列用户才看到完整的消息内容。T4时刻如果再次收到同样的新消息提醒客户端校验消息队列中已有该消息详情便忽略该提醒。这种机制确保了服务端定义的消息顺序与客户端展示顺序的一致性同时避免了消息重复展示。五、消息可靠性投递消息可靠性是IM系统的生命线。在推拉结合模式下可靠性通过以下机制保障连接服务在收到用户消息并成功写入消息队列后向客户端返回确认。群组服务在消息持久化成功后才通过HTTP回调通知连接服务有新消息。客户端收到推送通知后主动拉取消息详情即使推送通知丢失客户端也可以在下次心跳或重连时补偿拉取。当用户WebSocket连接中断时连接服务立即更新群组路由信息将用户从群的活跃成员列表中移除。如果群组服务在路由信息更新前仍尝试向该连接发送推送会收到连接失败响应此时可选择将消息标记为待重推或依赖客户端重连后的拉取补偿。用户重连后客户端会拉取断线期间错过的所有消息确保消息不丢失。六、未读数统计优化6.1 读扩散模式下的未读数挑战在读扩散模式下未读数统计是真正的技术难点。每个群成员需要知道自己在群中有多少条未读消息而所有消息存储在公共群信箱中。在百万级成员的群中每次都通过SQL计算未读数会带来巨大的性能压力。一个直观的SQL实现是根据用户上次已读消息ID统计大于该ID的消息总数。但随着用户阅读进度不断前移SQL中的OFFSET值持续增大在MySQL这类数据库中OFFSET很大时SQL执行时间会急剧拉长。6.2 Redis Sorted Set优化方案采用Redis的Sorted Set来优化未读数统计。每个群构建一个有序集合Score和Member都使用消息ID。通过ZRANK命令可以快速获取某个消息ID在集合中的排名该排名值可以换算为未读数。这种方法将计算从数据库层迁移到缓存层将复杂度从O(n)降低到O(log n)且在百万级数据规模下依然保持毫秒级响应。结语百万级群聊系统的架构设计核心挑战集中在消息分发模式的选择和消息顺序的保证上。读扩散通过写入一次、多人读取的方式解决了写扩散在超大规模群组中写入效率低和存储成本高的问题。推拉结合的消息同步机制既保障了消息可达性又通过服务端序列号确保了全局顺序一致。在此基础上连接路由管理、消息可靠性保障和未读数优化共同构成了完整的百万级群聊技术方案。这套方案已在vivo互联网团队的实践中得到验证为Web端大规模群聊产品提供了可参考的技术路径。
