SUBSCRIBE и PUBLISH
Тема дорожной карты · Redis
SUBSCRIBE и PUBLISH — основные команды Redis Pub/Sub, лёгкого паттерна передачи сообщений, встроенного в in-memory хранилище и разделяющего производителей и потребителей сообщений. Клиент подписывается на один или несколько каналов через SUBSCRIBE channel [channel ...] и переходит в режим прослушивания, получая любое сообщение, которое другой клиент отправит в эти каналы командой PUBLISH channel message. Redis доставляет Pub/Sub сообщения не более одного раза без персистентности — если в момент публикации нет ни одного подписчика, сообщение отбрасывается — что делает его подходящим для уведомлений в реальном времени, живого чата и сигналов инвалидации кэша, но не для надёжной очереди. Для подписок по шаблону PSUBSCRIBE pattern позволяет клиентам получать сообщения из всех каналов, соответствующих glob-шаблону, что удобно в архитектурах распределённых кэшей, где события инвалидации кэша именуются по префиксу ключа. Когда требуется гарантированная доставка или воспроизведение сообщений, вместо SUBSCRIBE и PUBLISH следует использовать Redis Streams (с XADD и XREAD), поскольку Streams сохраняют сообщения в in-memory журнале.
Как это работает
SUBSCRIBE и PUBLISH реализует простой pub/sub: SUBSCRIBE channel слушает; PUBLISH channel message шлёт. Подписчики получают сообщения в порядке прибытия; если subscriber медленный, сообщение сбрасывается (fire-and-forget). Паттерны: PSUBSCRIBE channel.* — wildcard. Для durable, replayable потоков с consumer groups + acks — Redis Streams (XADD/XREAD/XREADGROUP); они вытеснили pub/sub в большинстве production-кейсов.
Когда применять
Pub/sub — для fan-out уведомлений, где потеря допустима (live dashboard updates, "пользователь X печатает"). Redis Streams — когда важны гарантии доставки, порядок между consumer или replay (это большинство production-сценариев). Для cross-region или cross-cloud сообщений — Kafka или NATS; Redis это single-cluster.
Типичные ошибки
Ловушки SUBSCRIBE и PUBLISH: event sourcing на pub/sub (он забывает — Streams); SUBSCRIBE на соединении, которое также делает обычные команды (нельзя — соединение в subscribe-mode); не обрабатывают reconnect (упавший TCP пропускает все сообщения за gap); высокий publish rate, который consumer не догоняет (нет backpressure — тихая потеря).