WebSocket 通信

如果用 HTTP 轮询做弹幕，客户端要不断请求“有没有新消息”，延迟高、浪费资源。直播弹幕更适合使用 WebSocket：客户端和服务端建立长连接，服务端可以主动推送消息。

浏览器/APP <-> WebSocket 网关 <-> 房间消息服务

连接建立

连接建立时要做三件事：

1. 校验用户身份或游客身份。
2. 校验用户是否有权进入房间。
3. 记录连接和房间的映射关系。

连接状态通常保存在网关内存里：

connection_id -> user_id, room_id, device_id, connected_at
room_id -> connection_id 列表

这些状态变化很快，不适合每次都写数据库。数据库只保留关键事件和审计记录。

心跳与断线

长连接需要心跳机制。客户端定期发送 ping，服务端返回 pong；如果一段时间没有心跳，就认为连接失效并清理。

心跳间隔要平衡：

• 太短：心跳流量大，浪费带宽。
• 太长：断线发现慢，在线人数不准确。

移动网络下还要考虑前后台切换、弱网和 NAT 超时。客户端断线后应自动重连，并重新订阅房间。

网关职责

WebSocket 网关应该尽量保持轻量：

• 维护连接。
• 做基础鉴权。
• 接收用户消息。
• 推送房间消息。
• 执行连接级限流。

复杂审核、落库、统计、推荐等逻辑不要放在网关里，否则网关会变重，扩容和稳定性都会变差。

横向扩展

一台网关无法承载所有连接。多网关部署后，要解决“某个房间的用户分散在多台网关上”的问题。常见方式是：

消息服务 -> 发布房间消息 -> 多台网关各自推给本机连接

也就是说，广播不是由一台服务直接推给所有人，而是先发布到房间频道，再由各网关本地 fan-out。

连接可观测

长连接系统要监控：

• 当前连接数。
• 每秒新建连接和断开连接。
• 心跳超时率。
• 单网关发送队列长度。
• 推送失败率。

WebSocket 解决了实时通道，下一章要处理热门房间的高并发广播问题。