Как работает Redis Pub/Sub?

Question

Accepted Answer

**Pub/Sub** (Publish/Subscribe) — это паттерн обмена сообщениями в Redis, где **издатели** (publishers) отправляют сообщения в **каналы** (channels), а **подписчики** (subscribers) получают сообщения из каналов, на которые они подписаны — при этом издатели и подписчики ничего не знают друг о друге. Это позволяет реализовать обмен сообщениями в реальном времени и слабо связанное взаимодействие между сервисами.

## Модель 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)
```

## Важное ограничение: fire-and-forget

```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 обеспечивает **обмен сообщениями в реальном времени**, где издатели транслируют в каналы, а подписчики получают сообщения мгновенно, при этом издатели и подписчики **слабо связаны** (не знают друг о друге) — это используется для отправки уведомлений в реальном времени, чата, обновления живых панелей мониторинга и слабо связанного взаимодействия между сервисами (часто в сочетании с WebSockets для отправки обновлений в браузеры).

Это делает Redis простым и быстрым решением для функций трансляции в реальном времени.

Однако **самый важный момент** — понимание **ограничения fire-and-forget** в Pub/Sub: это доставка «максимум один раз» — сообщения достигают только подписчиков, подключённых в момент отправки, а оффлайн-подписчики **навсегда теряют сообщения** (нет персистентности, воспроизведения, подтверждения или гарантии доставки).

Это критическое ограничение: Pub/Sub непригоден, когда важна надёжная доставка или история сообщений, и непонимание этого приводит к багам с потерей сообщений.

Знание альтернатив — **Redis Streams** (надёжный, логический, с группами потребителей и подтверждениями) или выделенные брокеры (Kafka, RabbitMQ) для надёжного обмена сообщениями — и выбор Pub/Sub только для простой трансляции в реальном времени, где потеря сообщений приемлема, отражает здравое суждение.

Поскольку обмен сообщениями в реальном времени — частая потребность, а Redis Pub/Sub обеспечивает простое решение с важными ограничениями надёжности (требуя Streams или брокера, когда нужны гарантии), понимание Pub/Sub — как он работает, его случаи использования и особенно ограничение fire-and-forget и когда использовать Streams вместо него — это ценное, практически актуальное знание для правильной реализации функций обмена сообщениями в реальном времени, где понимание ограничения столь же важно, как понимание возможностей.