广播与在线状态：低延迟协作能力

广播与在线状态：低延迟协作能力

数据库变更订阅适合「数据持久化的实时同步」，但有些场景并不需要落库——比如鼠标光标位置、临时聊天、谁在线。为此 Realtime 提供两种轻量能力：广播（Broadcast）与在线状态（Presence）。本节讲解它们的应用场景与使用思路。

为什么需要广播与在线状态

想象一个协作白板应用，需求包括：

• 每个人的光标在其他人屏幕上实时移动。
• 多人能看到当前谁在线。
• 某人画出一条线，要立刻出现在别人屏幕上。

这些信息有共同特点：临时性强、对实时性要求极高、无需长期存储。把它们每次都写进数据库再通过 CDC 推送，既慢又浪费。广播与在线状态正是为这类「即时但不持久」的需求设计：

• 广播（Broadcast）：客户端之间直接互发消息，低延迟，不落库。
• 在线状态（Presence）：跟踪并同步「谁在线」及其临时状态。

它们与数据库变更订阅共享同一连接，但走的是更轻的通道。

广播（Broadcast）：实时消息传递

广播的工作方式类似「聊天室」：客户端加入一个频道，向频道发送的消息会被频道内所有成员收到。

适用场景：

• 实时光标 / 选区：协作工具中各人光标位置的实时同步。
• 轻量聊天 / 弹幕：不要求历史记录的即时消息。
• 游戏中的状态广播：如位置、动作的即时同步。
• 指令下发：一个客户端通知其他客户端执行某操作。

广播的特点：

• 消息不写入数据库，断开即消失，无历史可查。
• 延迟极低，适合高频更新。
• 可配合「自我接收」开关：发送者是否也收到自己的消息。

设计广播时要想清楚「这条消息需要持久化吗」。需要持久化（如聊天记录）就应写入数据库并用变更订阅；不需要（如光标位置）才用广播。两者常结合使用。

在线状态（Presence）：谁在线

在线状态用于跟踪并同步频道中「当前有哪些成员、各自什么状态」。它的典型用途：

• 显示当前在线的协作者列表。
• 显示每个人的临时状态（如「正在输入」「正在编辑第 3 段」）。
• 检测某用户加入或离开。

与广播不同，在线状态由 Realtime 服务维护一份「当前成员及状态」的汇总，并在成员变动时自动同步给所有人。

在线状态的关键特性：

• 自动检测离开：客户端正常断开或异常掉线（超时），服务都会将其从在线列表移除。
• 临时状态同步：每个成员可声明一份临时状态（如正在输入），状态变化会同步给其他人。
• 无需手动维护：你不必自己实现「心跳」「超时清理」——Presence 服务已内置。

广播 + 在线状态 + 数据订阅的协作

三者常组合使用，覆盖协作应用的全部实时需求。以协作文档为例：

这种「持久数据走 CDC、临时信息走广播、成员状态走 Presence」的分工，是协作应用的通用架构。

设计协作应用的要点

• 频道划分：按房间、文档、项目等维度划分频道，避免无关消息互相干扰。
• 状态最小化：Presence 只放必要的临时状态，不要把大量数据塞进在线状态。
• 降级方案：网络不稳时，关键操作应有数据库兜底，不能只依赖广播。
• 一致性优先：真正需要一致性的关键数据，宁可走数据库变更订阅，也不用广播。

小结

广播用于低延迟、不持久化的消息互发；在线状态用于跟踪成员及其临时状态。它们与数据库变更订阅分工协作，共同支撑协作类应用。下一节讨论实时连接的工程化问题——性能、重连与连接管理。