Pub/Sub
Тема дорожной карты · Redis
Redis Pub/Sub реализует паттерн передачи сообщений, при котором издатели отправляют сообщения в именованные каналы, а подписчики получают их без прямой связи между производителями и потребителями. SUBSCRIBE channel [channel ...] переводит клиента в режим подписчика, а PUBLISH channel message доставляет сообщение всем активным подписчикам этого канала. Подписчики в Redis Pub/Sub получают сообщения в реальном времени, но не получают сообщения, опубликованные в период их офлайн — для надёжной доставки сообщений лучше подходят Redis Streams. Команда PUBSUB CHANNELS перечисляет активные каналы с хотя бы одним подписчиком, а PUBSUB NUMSUB channel сообщает количество подписчиков на каждый канал. Redis Pub/Sub широко используется для уведомлений в реальном времени, чат-приложений и рассылки сигналов инвалидации кэша в распределённых системах.
Как это работает
Pub/Sub реализует простой 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.
Типичные ошибки
Ловушки Pub/Sub: event sourcing на pub/sub (он забывает — Streams); SUBSCRIBE на соединении, которое также делает обычные команды (нельзя — соединение в subscribe-mode); не обрабатывают reconnect (упавший TCP пропускает все сообщения за gap); высокий publish rate, который consumer не догоняет (нет backpressure — тихая потеря).