Redis Pub/Sub 如何工作？

Question

Redis Pub/Sub 如何工作？

Accepted Answer

**Pub/Sub**（发布/订阅）是 Redis 的消息传递模式，其中**发布者**向**频道**发送消息，**订阅者**从他们订阅的频道接收消息——发布者和订阅者彼此不知道对方。它支持实时消息传递和服务之间的解耦通信。

## Pub/Sub 模型

```bash
# Subscriber listens on a channel
SUBSCRIBE news                    # subscribe to the "news" channel

# Publisher sends a message to the channel (in another connection)
PUBLISH news "Breaking story!"    # all subscribers to "news" receive this instantly

# Pattern subscriptions (wildcards)
PSUBSCRIBE news.*                 # subscribe to news.sports, news.tech, etc.
```

发布者 `PUBLISH` 到一个频道；订阅者 `SUBSCRIBE` 到频道并实时接收消息。它们是**解耦的**——发布者不知道谁（如果有的话）在监听。

## 使用场景

```text
✓ REAL-TIME notifications — push events to interested services/clients instantly
✓ Chat / messaging — broadcast messages to subscribers
✓ Live updates — dashboards, feeds, multiplayer (broadcast state changes)
✓ Decoupling services — services communicate via channels without direct coupling
✓ Often paired with WebSockets (Redis pub/sub → server → WebSocket → browser)
```

## 重要限制：即发即忘

```text
⚠️ Redis Pub/Sub is FIRE-AND-FORGET (at-most-once delivery):
  → Messages are delivered ONLY to subscribers connected AT THAT MOMENT.
  → If a subscriber is offline/disconnected, it MISSES the message (no storage/replay).
  → No persistence, no acknowledgment, no delivery guarantee.
→ NOT suitable when you need reliable delivery or message history.
```

## 当你需要可靠性时：使用 Streams

```text
For RELIABLE messaging (persistence, replay, consumer groups, acknowledgments):
  → use Redis STREAMS (a durable, log-based structure) instead of Pub/Sub
  → or a dedicated message broker (Kafka, RabbitMQ)
Pub/Sub → simple real-time broadcast where missing messages is acceptable
Streams → when you need durability and delivery guarantees
```

## 为什么这很重要

理解 Redis Pub/Sub 对于**实时消息传递和解耦通信**很有价值，因此它是有用的知识——但至关重要的是，同样重要的是理解它的局限性，以便恰当地使用它。

Pub/Sub 支持**实时消息传递**，其中发布者广播到频道，订阅者实时接收，发布者和订阅者**解耦**（彼此不知道）——为实时通知、聊天、实时仪表板更新和解耦服务通信等使用场景提供支持（通常与 WebSocket 配合使用以将更新推送到浏览器）。

这使 Redis 成为实时广播功能的简单、快速的选择。

然而，**最重要的一点**是理解 Pub/Sub 的**即发即忘限制**：它是至多一次交付——消息只到达那一刻连接的订阅者，离线订阅者**永久丢失消息**（无持久化、重放、确认或交付保证）。

这是一个关键的约束：当可靠交付或消息历史很重要时，Pub/Sub 不适用，不理解这一点会导致消息丢失的 bug。

了解替代方案——**Redis Streams**（持久的、基于日志的、支持消费者组和确认）或专用消息代理（Kafka、RabbitMQ）以实现可靠消息传递——并仅在丢失消息可接受的简单实时广播场景中选择 Pub/Sub 体现了正确的判断。

由于实时消息传递是常见的需求，而 Redis Pub/Sub 为其提供了简单的解决方案但具有重要的可靠性限制（当需要保证时需要 Streams 或消息代理），理解 Pub/Sub——它如何工作、它的使用场景，尤其是它的即发即忘限制以及何时改用 Streams——是实现实时功能的宝贵的、实用相关的知识，其中理解限制与理解功能同样重要。