这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
完整系统
系统演进路线
从轮询聊天室到生产级直播互动平台
第 1 版
单房间轮询
几十个观众时先让页面每 2 秒拉一次消息。
- HTTP API
- MySQL 弹幕表
- 客户端轮询
延迟高，热门房间会把数据库扫穿。
第 2 版
WebSocket 长连接
观众开始抱怨“弹幕慢半拍”，需要把消息主动推到客户端。
- 连接网关
- 心跳保活
- 鉴权
- 断线重连
网关既管连接又管业务，单机连接数和发送队列成为瓶颈。
第 3 版
房间分片广播
万人直播间一条弹幕要发给几万连接，不能让单网关承担全量广播。
- 房间路由
- 网关分片
- 本机连接表
- 热点房间隔离
普通弹幕、礼物、管理消息混在一起，高峰时无法取舍。
生产版
分级消息平台
礼物、禁言、抽奖和风控都进入直播间，弹幕系统变成实时互动平台。
- 消息队列
- 优先级通道
- 审核风控
- 礼物幂等
- 监控告警
必须用分级、降级和审计保证体验与账务安全。
完整的直播弹幕系统可以拆成四层：
连接层 -> 消息处理层 -> 分发层 -> 异步治理与统计层连接层维护 WebSocket，消息处理层做鉴权、限流、审核和分级，分发层按房间和网关广播，异步层负责落库、统计、风控、回放和榜单。
最终架构
一次普通弹幕发送流程：
- 客户端通过 WebSocket 连接到网关。
- 用户发送弹幕，网关做基础限流和鉴权。
- 消息服务生成
message_id，执行敏感词和禁言检查。 - 普通弹幕进入实时分发通道。
- 房间分发服务把消息发布到各网关分片。
- 网关推送给本机连接的观众。
- 异步消费者处理落库、统计和审核复盘。
礼物和管理消息会走更高优先级通道，并带有更严格的幂等和审计。
消息分级策略
| 消息 | 优先级 | 可靠性 |
|---|---|---|
| 普通弹幕 | 中 | 低延迟优先，允许采样 |
| 系统公告 | 高 | 必须送达或重试 |
| 礼物消息 | 高 | 以支付结果为准，幂等展示 |
| 管理消息 | 最高 | 强审计、快速生效 |
| 点赞事件 | 低 | 聚合统计，不逐条广播 |
这张表是直播弹幕系统的核心设计依据。没有分级，系统会在高峰时无法取舍。
关键决策
- WebSocket 还是轮询：实时性要求决定使用 WebSocket，轮询只适合低频场景。
- 每条弹幕都广播吗：大房间不能。需要采样、限流和优先级。
- 网关是否处理业务逻辑：网关应轻量，复杂逻辑放到消息服务和异步消费者。
- 礼物是否和弹幕同链路：展示可以共用分发能力，资金链路必须独立可靠。
- 在线人数是否强准确：展示可以近似，结算和统计要有后端校验。
上线检查清单
- WebSocket 是否有鉴权、心跳、重连和连接清理？
- 单网关连接数、发送队列和推送失败率是否有监控？
- 大房间是否有分片、限流和热点隔离？
- 普通弹幕、礼物、管理消息是否分通道或分优先级？
- 消息队列积压时是否有降级策略？
- 礼物事件是否以支付订单为准并保证幂等？
- 敏感词、禁言、黑名单是否在实时链路生效？
- 弹幕落库、回放、统计是否异步解耦？
课程总结
直播弹幕系统的本质是实时消息分发平台。它既要低延迟，又要能承受热点；既要让房间热闹，又要能治理内容；既要展示礼物动效，又不能破坏账务一致性。
设计这类系统时，始终先问：
- 哪些消息必须可靠，哪些可以采样？
- 哪些链路要求毫秒级，哪些可以异步？
- 热门房间是否会拖垮全站？
- 付费和管理消息是否有独立保障？
回答清楚这些问题，直播弹幕系统才具备生产级架构基础。