Redis Pub/Sub 与 Redis Streams
发布: (2025年12月22日 GMT+8 23:37)
6 min read
原文: Dev.to
Source: Dev.to
请提供您希望翻译的具体文本内容，我将为您翻译成简体中文。
什么是 Redis Pub/Sub 和 Redis Streams？
Redis Pub/Sub — 发送即忘的消息
发布者向 频道 发送消息。
订阅者仅在发布时保持连接才会收到消息。
没有消息存储、重试或回放机制。
关键特性
| Feature（特性） | Pub/Sub |
|---|---|
| Message persistence（消息持久化） | ❌ 否 |
| Delivery guarantee（投递保证） | At‑most‑once（至多一次） |
| Offline consumption（离线消费） | ❌ 否 |
| Consumer groups（消费者组） | ❌ 否 |
| Ordering（顺序） | Best effort（尽力而为） |
| Complexity（复杂度） | Very low（非常低） |
何时适合使用 Pub/Sub
- 实时 UI 更新（仪表盘、实时光标、在线状态）
- 对漏掉消息可接受的聊天系统
- 向已连接客户端广播系统状态
核心限制
如果订阅者断开、响应慢或崩溃，消息将永久丢失。
Redis Streams — 持久化事件日志
Redis Streams 引入了 持久化、追加式日志，用于可靠的事件处理。消息存储在 Redis 中，消费者可以按自己的节奏消费。
核心概念
- Stream（流） – 有序的消息日志
- Message ID（消息 ID） – 单调递增的唯一标识符
- Consumer Group（消费者组） – 跨多个消费者的协同消费
- ACK – 确认成功处理
- PEL（Pending Entries List，待处理条目列表） – 跟踪未确认的消息
关键特性
| Feature（特性） | Streams |
|---|---|
| Message persistence（消息持久化） | ✔ 是 |
| Delivery guarantee（投递保证） | At‑least‑once（至少一次） |
| Offline consumption（离线消费） | ✔ 是 |
| Consumer groups（消费者组） | ✔ 是 |
| Replay（回放） | ✔ 是 |
| Complexity（复杂度） | Medium–High（中等偏高） |
何时适合使用 Streams
- 作业队列和后台工作者
- 事件驱动的微服务
- 审计日志和事件溯源
- 需要恢复和重试的系统
并排比较
| Aspect（方面） | Pub/Sub | Streams |
|---|---|---|
| Persistence（持久化） | No（否） | Yes（是） |
| Replay（回放） | No（否） | Yes（是） |
| ACK support（ACK 支持） | No（否） | Yes（是） |
| Consumer groups（消费者组） | No（否） | Yes（是） |
| Failure recovery（故障恢复） | No（否） | Yes（是） |
| Latency（延迟） | Very low（极低） | Low–medium（低至中） |
| Operational complexity（运维复杂度） | Minimal（最小） | Moderate（适中） |
Pub/Sub 的内部工作原理
- 订阅者连接并订阅频道。
- 发布者发布消息。
- Redis 会立即将消息推送给所有活跃的订阅者。
如果订阅者在此时未连接，消息将被丢弃。没有 无背压处理 且 无消息历史。
Redis Streams 的内部工作原理
# Producer appends a message
XADD mystream * field1 value1 field2 value2
# Consumer reads messages (group mode)
XREADGROUP GROUP mygroup consumer1 COUNT 10 STREAMS mystream >
# Consumer acknowledges processing
XACK mystream mygroup 1526985054069-0- Redis 使用唯一 ID 存储消息。
- 消费者使用
XREAD或XREADGROUP读取消息。 - 未确认的消息会保留在 PEL（Pending Entries List）中以便恢复。
Streams 的行为类似于 Kafka 或 SQS，但完全嵌入在 Redis 中。
交付保证说明
Pub/Sub — 最多一次
- 消息的投递次数为零次或一次。
- 不会重试，也没有确认。
- 最适合非关键数据。
Streams — 至少一次
- 消息会被持久化。
- 处理可以重试。
- 消费者必须处理可能的重复。
扩展考虑
Pub/Sub
- 极快。
- 最小的内存开销。
- 随着订阅者数量增加，扇出成本上升。
Streams
- 更高的内存使用。
- 消费者组分配负载。
- 支持水平扩展和容错。
决策规则（在实际项目中使用）
| 场景 | 推荐选择 |
|---|---|
| 仅实时通知 | Pub/Sub |
| 业务关键处理 | Streams |
| UI 事件 | Pub/Sub |
| 分布式工作者 | Streams |
| 需要回放或恢复 | Streams |
| 最小延迟，无历史 | Pub/Sub |
实际案例
通知
- 只有在线用户才重要 → Pub/Sub
- 每个用户都必须收到消息 → Streams
订单处理流水线
- 库存、计费、发货协调 → Streams
常见错误
- 将 Pub/Sub 用作作业队列 ❌
- 期望 Pub/Sub 具备持久性 ❌
- 在 Streams 中忽视重复处理 ❌
- 从不修剪旧的流条目 ❌
摘要
Redis 提供两种消息模型：
- Pub/Sub — 简单、快速、瞬时
- Streams — 持久、可靠、可回放
根据 投递保证、容错能力 和 系统复杂度 来选择，而不是便利性。
经验法则：
- 可以接受消息丢失 → Pub/Sub
- 不能接受消息丢失 → Streams
进一步阅读
- Redis Pub/Sub 文档
- Redis Streams 文档
- Redis 消息模式的系统设计比较