核心指标

指标决定架构

设计直播弹幕系统时，重点看这些指标：

端到端延迟

直播的「实时感」取决于端到端延迟：

• 从用户按下发送，到其他观众看到，通常要求亚秒级。
• 延迟构成：客户端 → 网关 → 消息服务 → 广播 → 各网关 → 客户端。
• 每跳都要控制耗时，链路越短越好。

为了降低延迟，我们使用 WebSocket 长连接（而不是轮询），并把审核、落库、统计异步化，不让慢环节阻塞实时链路。

连接数

• 单网关能承载多少连接（几千到几十万，取决于语言与 IO 模型）。
• 单房间多少在线（决定要不要分片）。
• 全站同时在线（决定网关总量）。

连接数是容量规划的起点：它直接决定需要多少台网关。

广播吞吐

广播吞吐是弹幕系统最容易被低估的指标：

1 条入站消息 → N 个在线观众的出站消息

• 入站吞吐 = 用户发消息速率。
• 出站吞吐 = 入站 × 房间在线数（广播放大）。

这决定了下一章高并发弹幕的核心压力。

丢消息率

不同消息的丢消息率要求不同：

• 普通弹幕：允许少量丢失（采样 / 降级）。
• 礼物消息：几乎不能丢（可重试、可对账）。
• 管理消息：必须送达。

所以「丢消息率」要按消息类型分别统计，而不是看一个总平均。

治理命中率

• 敏感词是否被拦截。
• 刷屏用户是否被限速。
• 广告是否被识别。
• 恶意用户是否被禁言。

治理命中率低，房间体验和合规都会出问题。它是「内容治理」这条链路的指标。

一句话

这些指标会决定后续架构：延迟决定 WebSocket，连接数决定分片，吞吐决定采样，丢消息率决定分级投递，治理决定审核链路。先定指标，再谈架构。

下一节看最核心的设计依据：消息分级。

上一章节

直播弹幕的目标与边界

下一章节

消息分级