设计一个支持万人在线的语音聊天室，如何保证房间状态（如麦位信息、在线人数）的实时一致性？

面试记录 2026-10-14

题目：设计一个支持万人在线的语音聊天室，如何保证房间状态（如麦位信息、在线人数）的实时一致性？

难度：high

标签：practice/business, architecture/realtime

评分：⭐⭐⭐⭐☆（4/5）

我的回答

直播间这个东西本身就是一个独立的个体。然后直播间状态、麦位信息、在线人数这些，属于直播间个人的、直播间的属性，独立的进行维护。当用户上线或者申请麦位的时候，检查直播间属性上的值，然后进行更新。这个更新使用 Redis 更新，然后同步的展现就可以了。

用户上线的时候，对应的用户在线人数进行原子增，就可以更新上线在线的人数。当用户下线的时候，对应的更新对应的 Redis 就可以实现了。有时候为了保证业务更新，可能会用到 MQ。当用户上线下线的时候，发对应的消息到 MQ，然后监听 MQ 的变更，对应的去更新房间状态，来达到数据的最终一致性;

万人直播间的数据更新，直接用 Redis 本身就可以，并不一定需要 MQ 再去异步处理。在 MQ 异步处理可以提升它更高的兼容性，但是 Redis 本身万人直播间的更新就可以扛得住。新用户获取信息的时候直接获取直播间的信息,这个信息的更新通过长连接,进行对应的实时更新,或者使用服务端推送给客户端进行更新;但是不能使用客户端轮询,这样的客户端轮询产生的并发会让业务服务器崩溃

点评

优点：

• 抓到了核心：直播间是独立个体，状态属性独立维护
• 数据更新用 Redis 原子增（在线人数）
• 明确反对客户端轮询（会让业务服务器崩溃）——这是正确的工程判断
• 区分了 Redis 同步 vs MQ 异步的适用场景（最终一致性 vs 强一致）
• 有架构意识：长连接/服务端推送是实时同步的正确方向

不足：

• 未提分布式广播机制：用户长连接挂在不同服务器时，怎么广播状态变更（Redis Pub/Sub 或独立消息总线）
• 未提麦位管理的复杂性：麦位数量限制、排队机制、麦位冲突（多用户同时申请）、自动释放
• 未提在线人数统计细节：心跳保活（30s）、超时清理、分布式会话
• 未提具体技术选型：WebSocket 网关（Netty）、Redis Pub/Sub、IM 系统（融云/环信）

补充：

• 广播机制：用户连接挂在 WS 网关 A，状态变更发生在服务器 B → 用 Redis Pub/Sub 或 Kafka 广播到所有 WS 网关
• 麦位管理：
• 麦位数量有限（4-10 个），用 Redis Set 存当前麦位
• 申请麦位用 SADD + 唯一索引 防并发（SETNX 占位）
• 排队机制：申请失败进入排队列表（List），有空位时按顺序分配
• 自动释放：用户下线/心跳超时触发释放
• 在线人数：
• 心跳保活：客户端 30s 心跳，服务器 60s 超时清理
• 分布式会话：用户连接挂服务器 A，状态存 Redis，任意服务器可读
• 计数器：INCR/DECR 原子操作
• 实时同步协议：
• WebSocket（全双工、低延迟）
• SSE（Server-Sent Events，单向推送）
• 长轮询（兜底，延迟高）
• 一致性模型：
• 强一致：写 Redis + 同步广播（延迟 100ms 内）
• 最终一致：写 Redis + 异步广播（可能短暂不一致，秒级）

完整讲解

第一部分：知识重点剖析

核心考点定位：考察"分布式实时系统"的设计能力——状态存储、广播机制、一致性模型三者的权衡。

知识点拆解：

1. 系统架构分层：

• 接入层：WebSocket 网关（Netty），用户长连接挂在这里
• 业务层：房间状态服务（麦位、在线人数、聊天消息）
• 存储层：Redis（状态 + 计数器 + 麦位集合）
• 广播层：Redis Pub/Sub 或 Kafka（跨服务器状态同步）

1. 状态存储设计：

• 在线人数：INCR/DECR 原子操作，key 为 room:{roomId}:online
• 麦位集合：SET 存当前麦位用户列表，key 为 room:{roomId}:mics
• 麦位排队：LIST 存排队用户，key 为 room:{roomId}:mics:queue
• 用户状态：HASH 存用户详细信息，key 为 room:{roomId}:user:{userId}

1. 广播机制：

• Redis Pub/Sub：轻量、无持久化，适合状态广播（延迟 < 10ms）
• Kafka：可靠、有持久化，适合聊天消息（延迟 < 100ms）
• WebSocket 网关集群：多 WS 网关订阅 Pub/Sub，收到消息后推送给本地连接

1. 麦位管理的复杂性：

• 并发申请：多用户同时申请同一麦位，用 SETNX 或 Lua 脚本保证原子性
• 排队机制：申请失败进队列，空位时按顺序分配
• 自动释放：用户下线/心跳超时触发释放，释放后通知下一个排队用户
• 麦位转让：用户主动让麦，释放后分配给下一个人

1. 在线人数统计：

• 心跳保活：客户端 30s 心跳，服务器 60s 超时清理（EXPIRE 自动过期）
• 分布式会话：用户连接挂服务器 A，状态存 Redis，任意服务器可读
• 计数器维护：INCR/DECR 原子操作，避免并发错乱

1. 实时同步协议：

• WebSocket：全双工、低延迟（< 100ms）、生产环境首选
• SSE：单向推送、HTTP 兼容、延迟略高
• 长轮询：兜底方案、延迟高（10s）、连接开销大

1. 一致性模型：

• 强一致：写 Redis + 同步广播（所有服务器同时收到），延迟 100ms 内
• 最终一致：写 Redis + 异步广播（通过 MQ），可能短暂不一致，秒级收敛

第二部分：考察方向与延伸递进

考察方向：

• 深度：Redis Pub/Sub 的实现原理、Kafka 的分区与消费者组、WebSocket 的心跳机制
• 广度：与 IM 系统（融云/环信/腾讯云 IM）对比；与弹幕系统（WebSocket + 分片）对比
• 应用：实时弹幕、在线游戏房间、协同编辑（CRDT）、直播互动

延伸递进面试题：

1. 万人在线的 WebSocket 连接怎么横向扩展？

• 解答要点：WS 网关无状态化（状态放 Redis），多副本部署；用 Redis Pub/Sub 广播状态变更；客户端通过域名访问，LB 做 WebSocket 路由

1. 麦位申请高并发怎么保证原子性？

• 解答要点：Redis SETNX 占位（key 为 mic:{micId}），失败则排队；Lua 脚本保证"检查 + 占位"的原子性；空位时 BLPOP 阻塞等待下一个申请

1. 强一致和最终一致怎么选型？

• 解答要点：麦位状态用强一致（同步广播），聊天消息用最终一致（MQ 异步）；核心是"用户能感知到的实时"其实是"准实时"（秒级），不必追求毫秒级强一致

第三部分：面试者参考回答（三步法口语化，300-400 字）

【一句话结论】

面试官您好，万人在线的核心是"状态存 Redis + 广播走 Pub/Sub + 长连接走 WebSocket"，麦位管理用 SETNX + Lua 保证原子性，在线人数用心跳保活 + 超时清理。

【三点展开】

第一，架构分层：WebSocket 网关（Netty）负责用户长连接，无状态化便于横向扩展；房间状态服务负责业务逻辑，状态全部存 Redis（在线人数 INCR/DECR、麦位 SET、排队 LIST）；Redis Pub/Sub 负责跨服务器广播状态变更——用户连在 WS 网关 A，状态变更发生在服务器 B，B 发消息到 Pub/Sub，A 订阅后推送给本地连接。

第二，麦位管理有并发陷阱：多用户同时申请同一麦位，用 SETNX mic:{micId} userId 原子占位，失败则进排队队列（LIST）；空位时 BLPOP 阻塞等待下一个申请；用户下线/心跳超时触发释放，释放后通知排队用户。Lua 脚本保证"检查麦位空 + 占位"的原子性，避免竞态。

第三，在线人数用心跳保活：客户端 30s 心跳，服务器 60s 超时清理（EXPIRE 自动过期，避免死连接）；新用户进房直接读 Redis 拿当前状态，之后通过 WebSocket 订阅房间状态变更，秒级感知。不能用客户端轮询——万人 QPS 会打爆服务器。强一致（麦位状态同步广播，延迟 < 100ms）和最终一致（聊天消息走 MQ，秒级收敛）按场景选型。

【一句边界】

当然，如果是百万级并发（YY 语音、KOOK），自建成本高，直接用 IM 云（融云/环信/腾讯云 IM）+ WebSocket 自建弹幕系统更划算——核心是"麦位状态自建，聊天消息用云"。