性能与连接管理：让实时能力稳定可靠

性能与连接管理：让实时能力稳定可靠

实时连接是长连接，比一次性请求更「脆弱」——网络波动、后台休眠、并发过多都会带来挑战。本节讨论生产环境中必须处理的工程问题：连接生命周期、重连、节流、并发与配额。

长连接的特性

Realtime 基于 WebSocket 这类长连接：客户端与服务端建立一条持续保持的通道，事件通过它双向流动。这与普通 HTTP 请求（一问一答即断）很不一样：

• 保持状态：连接维持期间，订阅、身份等状态都保留。
• 对网络敏感：一旦网络中断，连接会断开，需要重新建立。
• 持续占用资源：每个连接都占用服务端资源，不能无限开。

因此，实时应用的工程重点，在于管理这条长连接的生命周期与稳定性。

连接生命周期管理

一个健壮的实时客户端应处理连接的各个阶段：

• 建立连接：带上认证令牌，与 Realtime 服务握手。
• 认证：连接建立后用 JWT 鉴权，确定身份与可订阅范围。
• 订阅：在已认证的连接上发起各类订阅。
• 运行：持续接收事件，保持连接。
• 断开与清理：主动离开时关闭连接、取消订阅。

客户端库通常会封装这些步骤，但开发者要理解背后的阶段，才能在出问题时定位。

重连与令牌续期

网络不稳定时，连接会断开。健壮的客户端应：

• 自动重连：断线后按一定策略（如指数退避）自动重连，避免用户手动刷新。
• 重连后恢复订阅：重连成功后，重新发起之前的订阅，恢复实时监听。
• 令牌续期：访问令牌过期时，重新鉴权连接，避免因令牌失效而掉线。

客户端库大多内置了自动重连，但你需要了解它的行为，特别是在弱网环境下的表现。

节流与批量

某些场景下事件会非常密集，例如：

• 高频写入的表，每秒产生大量变更事件。
• 协作工具中光标频繁移动。

如果把每个事件都直接反映到界面，会造成卡顿。常见优化：

• 节流（throttle）：限制界面更新频率，例如最多每 100 毫秒刷新一次。
• 批量处理：把短时间内多个事件合并成一次更新。
• 选择性订阅：只订阅真正需要的事件类型与过滤条件，减少无关事件。

对光标这类极高频率的广播，发送端也应节流，避免淹没频道。

并发与配额

实时连接是有成本的，平台通常对每个项目、每个客户端的并发连接数、订阅数有限制（配额）。设计时要注意：

• 共享连接：一个客户端尽量复用同一条连接承载多个订阅，而不是每个订阅开一条。
• 按需订阅：只在需要实时更新的页面/组件订阅，离开即取消。
• 避免全表订阅：能加过滤就加过滤，全表订阅在数据量大时会产生海量事件。

一个常见反例是「打开应用就订阅所有表的所有变更」。这在数据量小时看似正常，一旦上线数据增长，事件量会爆炸，既耗资源又拖垮前端。务必精细订阅。

安全与权限复核

实时能力的便捷不应让人忽略安全：

• 订阅受 RLS 约束，前提是表已启用 RLS 并开启 Realtime。
• 广播频道也应考虑权限——并非所有客户端都应能加入任意频道。
• 令牌过期后，连接的权限范围会随之变化。

上线前，应像测试普通查询一样，测试实时订阅的权限边界，确保用户收不到无权看到的数据。

监控与排错

实时问题往往难复现，做好监控与排错准备：

• 连接状态日志：记录连接、断开、重连事件，定位稳定性问题。
• 事件计数：统计各类事件数量，发现异常暴增。
• 客户端反馈：界面给出「连接中断、重连中」等提示，避免用户误以为应用卡死。

小结

实时能力让应用「活」起来，但长连接也带来重连、节流、并发等工程负担。健壮的自动重连、精细的订阅过滤、合理的节流与配额管理，是实时应用稳定运行的保障。把这些处理到位，你的实时功能才能在生产环境可靠服务用户。

至此，第 6 章完成了对 Realtime 三大能力及工程管理的讲解。第 7 章将转向非结构化数据的托管——文件存储。