实时通信关注在线用户
WebSocket 类服务会保持实时连接,让服务器能立刻把变化推送到浏览器或 App。
实时通信服务面向在线用户体验:聊天、在线状态、协作文档、看板、通知和多人状态。免费层瓶颈通常是同时连接数和消息峰值,而不是存储。
Postgres 变更驱动 UI 更新时,用 Supabase Realtime。
聊天、在线状态和协作,优先看 Ably。
如果工作必须持久且可重试,应使用 MQ。
WebSocket 类服务会保持实时连接,让服务器能立刻把变化推送到浏览器或 App。
对实时应用来说,200 个峰值连接可能比每月几百万条消息更关键。
实时服务能告诉你谁在线并广播变化,但持久消息和历史记录仍需要存储。
持久异步任务用队列;用户界面需要即时反馈时用 WebSockets。
表格用于查看连接数和消息限制。真实应用还要单独设计重连、降级和持久历史。
| 提供商 | 免费存储 | 月流量 | 规格 / 算力 | 连接限制 | 关键限制 | 操作 |
|---|---|---|---|---|---|---|
Supabase Realtime数据库 CDC / WebSocket | 峰值 200 连接 | 每月含 2,000,000 条实时消息 | 原生 PostgreSQL CDC 追踪;数据库变更后自动推送到前端 | 监听通道硬上限 200 | 并发活跃用户超过 200 时,新用户会直接失去实时能力 | 访问官网 ↗ |
Ably Realtime企业级 Pub/Sub | 峰值 200 连接 | 每月 6,000,000 条消息(免费层额度非常高) | 全球边缘状态同步网络,原生智能重连追踪 | 活跃客户端连接硬锁为 200 | 突发上限为每秒 500 条消息;高峰超出后可能被静默丢弃 | 访问官网 ↗ |
AWS AppSyncGraphQL 订阅 | 60 万连接分钟 | 前 12 个月每月免费 250,000 次更新 | 托管 GraphQL 与无服务器 Pub/Sub 事件 API,深度集成 AWS IAM | 动态自动扩缩容连接能力 | 并非永久免费;12 个月后到期,之后按调用计费规则较复杂 | 访问官网 ↗ |
Azure Web PubSub托管 WebSocket | 峰值 20 连接 | 每天 20,000 条消息(永久免费层) | 原生 WebSocket 回退协议编排,零基础设施运维 | 并发活跃 Socket 连接严格上限 20 | 连接上限极低;第 21 个监听者会直接收到 503,且不支持自定义域名 | 访问官网 ↗ |
Pusher Channels标准 WebSocket | 峰值 100 连接 | 滚动沙箱每天 200,000 条消息 | 行业标准 WebSocket API,第三方 SDK 包装生态丰富 | 物理 Socket 并发监听数硬上限 100 | 第 101 个用户会直接收到连接错误,需要立即升级套餐 | 访问官网 ↗ |
实时服务免费层通常受同时连接数限制。一个消息不多但在线用户多的应用,也可能超限。
实时通道负责即时更新,持久消息历史和审计记录应放在数据库或对象存储。
移动网络会断,浏览器会休眠。应用需要重同步逻辑、序列号或重连后的数据库刷新。
输入状态、光标移动、在线状态、反应和文档编辑,会比想象中更快放大消息量。
心跳、进入/离开事件和重连,即使没有可见聊天消息,也会制造大量消息。
第 201 个用户无法连接时,实时功能会直接在 UI 上失败。需要设计降级状态。
把每个表变更推给每个客户端会快速消耗额度。应过滤 channel,只发送有用变化。
许多实时服务优化的是在线投递。离线用户需要补齐时,要把事件持久化到别处。
适合看板和协作数据视图,数据库变更后 UI 自动更新。
Ably 做实时广播,数据库存消息历史、搜索、审核和审计。
在线投递用实时通信,后台处理、重试和持久流程用 MQ。
它们在客户端和服务器之间保持实时连接,让应用即时更新:聊天、在线状态、协作、通知、看板、多人状态和实时光标。
实时通信面向用户且以连接为中心;MQ 是后端基础设施,用于持久异步处理。
小应用可以,尤其是消息存在 Postgres 时。要注意峰值连接、消息额度和离线补齐行为。
监控活跃连接、连接错误、重连率、每秒消息、丢消息、延迟和每个 channel 的广播量。
传输本身不解决持久历史。聊天历史、审计日志和离线事件应存入数据库或对象存储。