Ably — 是什么，实时 Pub/Sub 平台及其工作原理

什么是 Ably？

Ably — 一个成立于 2014 年的基于云的实时平台，为实时消息交换提供基础设施。与简单的发布服务不同，Ably 提供企业级交付保证、全球存在点网络（POP）以及为数百万同时在线客户端提供内置状态同步。

该平台用于 交付可靠性至关重要的项目中：金融行情器、物流追踪器、医疗监控系统和多人游戏。Ably 基于其专有的分布式消息代理技术，通过全球 15+ 个数据中心的网络复制数据。

根据 Ably 官方网站（2025 年），该平台每月为 50,000+ 个活跃应用处理超过 2000 亿条消息。客户包括财富 500 强公司：丰田（汽车远程信息处理）、HubSpot（CRM 同步）、Designity（协作编辑）。

Ably 的架构

Ably 的架构构建在通过高速通道连接的分布式消息代理（路由器）网络上。每个代理服务一部分通道，并通过 Ably 协议（一种针对最小开销优化的基于 WebSocket 的二进制协议）复制状态。客户端通过 DNS 负载均衡连接到最近的路由器。

Ably 与竞争对手的关键区别在于内置的 全局日志（global log），它为每个通道存储消息历史记录。这允许新的订阅者不仅接收新消息，还能接收以前的消息（重放），这对于审计和重新连接后的状态恢复至关重要。

Ably 如何工作

Ably 的交互模型遵循发布者-订阅者模式，并具有额外功能。发布者通过 Ably REST API 或 SDK 向通道发送消息。消息进入通道的全局分布式日志，并通过订阅者活跃的连接分发给所有订阅者。

Ably 的传输层支持多种协议：WebSocket（主要，使用二进制 Ably 协议）、Server-Sent Events（用于单向接收）、HTTP 流式传输（用于受限环境）和 MQTT（用于物联网设备）。客户端自动选择延迟最低的可用传输方式。

每条消息都经过 Ably 端的 验证 — 检查 API 密钥签名、通道配额、访问权限。验证在边缘路由器上 1-5 毫秒内完成，之后消息被复制到全局日志。根据 Ably 技术博客（2024 年），在洲际传输中，95% 的消息端到端延迟低于 65 毫秒。

通道和订阅

Ably 的通道 — 用于消息交换的命名主题。每个通道可以有无限数量的订阅者，但为了稳定性能，建议每个通道在一个区域内不超过 10,000 个。通道可以是单向的（仅从服务器发布）或完整的（客户端发布消息）。

Ably 的通道和 Pub/Sub 模型

Ably 中的 Pub/Sub 模型通过额外功能扩展了经典模式：订阅者在线状态（presence）、消息历史记录（history）、通道状态（channel state）和命名空间（namespaces）。每个通道属于一个命名空间，该命名空间定义了配额和访问权限。

在线状态（Presence） — 自动跟踪通道参与者。每个订阅通道的客户端都会在在线状态映射中注册，包含 clientId、状态（在线、离开、离线）和任意数据。当客户端断开连接时（通过超时或明确断开），在线状态会自动更新。

消息历史记录 — 每个通道默认存储消息历史记录（免费计划中最多 2 分钟或 100 条消息）。在付费计划中，历史记录可以延长到 72 小时，并可进行任意回溯访问。历史记录以不可变性保证（只追加）存储在分布式日志中。

Ably 的交付保证

交付保证 — Ably 与大多数实时服务的关键区别。该平台支持多种交付模式，可在发布消息时选择。模式决定了消息将被交付多少次以及如何处理连接错误。

At-least-once — 消息至少交付一次，可能存在重复。此模式用于通知和非关键数据，重复不会造成损害。Exactly-once — 通过客户端和服务器端的去重，消息严格交付一次。此模式对于金融交易和设备管理是强制性的。

Last-value 缓存 — 一种特殊模式，其中通道存储每个命名消息的最后一个值。新订阅者无需等待下一个事件即可立即获取当前状态。这是通过每个路由器上的全局键值存储实现的。根据 Ably 文档（2025 年），last-value 缓存将重新连接后的状态恢复时间从 2-5 秒减少到 50-100 毫秒。

如何在项目中使用 Ably

开始使用 Ably需要注册、创建应用程序和获取 API 密钥。库适用于所有主要平台。让我们看一个使用 JavaScript SDK 进行发布和订阅的示例。客户端使用 API 密钥连接，订阅一个通道，并附加事件处理器。

根据 Ably 文档（2025 年），建议为服务器端和客户端使用不同的 API 密钥，并具有最小权限（最小权限原则）。服务器密钥可以在任何通道发布，客户端密钥只能订阅特定的命名空间。

订阅 Ably 通道

import * as Ably from 'ably';

const client = new Ably.Realtime({
    key: 'YOUR_API_KEY',
    clientId: 'user-123'
});

const channel = client.channels.get('test-channel');

channel.subscribe('update', (message) => {
    console.log('已接收:', message.data);
});

channel.publish('update', {
    text: 'Hello from Ably',
    priority: 1
});

从服务器发布

const Ably = require('ably');

const rest = new Ably.Rest({ key: 'SERVER_API_KEY' });

const channel = rest.channels.get('test-channel');

channel.publish('server-event', {
    type: 'notification',
    payload: { userId: 100, text: 'Server message' }
}).then(() => {
    console.log('通过 REST 发布的消息');
});

Ably 与 Pusher 对比

在 Ably 和 Pusher 之间的选择取决于项目需求。两个平台都提供托管的实时基础设施，但在架构、保证和定价方面有所不同。Ably 面向对可靠性有高要求的企业，Pusher 则面向快速启动和简单性。

Ably 为每个通道使用 全局分布式日志，确保 exactly-once 交付和对历史记录的回溯访问。Pusher 使用具有 at-least-once 保证的代理架构。对于大多数应用程序，差异不明显，但对于金融和医疗系统，exactly-once 至关重要。

根据 Ably 与 Pusher 对比测试（2024 年），由于拥有更多的数据中心，Ably 在洲际传输中延迟降低 20-30%。Pusher 在集成速度上胜出 — 基本设置需要 10-15 分钟，而 Ably 由于更多的配置选项需要 20-30 分钟。

Ably 移动集成

适用于移动平台的 Ably SDK 支持 iOS (Swift)、Android (Kotlin/Java)、Flutter 和 React Native。移动客户端与 Ably 服务器端完全兼容，并支持所有功能：发布/订阅、在线状态、历史记录、推送通知。Android 可与 Firebase Cloud Messaging 集成，用于离线推送通知。

针对移动网络的优化 — Ably SDK 使用自适应心跳：在 Wi-Fi 上间隔 15 秒，在移动网络上 — 最多 60 秒以节省流量。当连接丢失时，SDK 会切换到备用传输方式（HTTP 流式传输），用户不会察觉到延迟。平均流量消耗 — 待机模式下每分钟 0.5-1 KB。

推送通知 — Ably 支持通过 APNs (Apple) 和 FCM (Firebase) 发送推送。推送可以定向到特定通道或 clientId。如果客户端处于活动状态（WebSocket 已连接），消息通过通道交付。如果客户端已断开，消息作为推送通知交付。这确保用户永远不会错过重要消息。