Какие плюсы и минусы Redis Pub/Sub с точки зрения устойчивости?

Redis Pub/Sub: Плюсы и минусы устойчивости

Redis Pub/Sub — это паттерн обмена сообщениями "издатель-подписчик". Это мощный инструмент, но у него есть серьезные ограничения с точки зрения надежности.

Основной механизм

import redis

# Издатель
publisher = redis.Redis(host='localhost', port=6379)

publisher.publish('news', 'Breaking news!')
publisher.publish('news', 'Another update')

# Подписчик
subscriber = redis.Redis(host='localhost', port=6379)
pubsub = subscriber.pubsub()
pubsub.subscribe('news')

for message in pubsub.listen():
    if message['type'] == 'message':
        print(f'Received: {message["data"]}')

Плюсы Pub/Sub

1. Простота и скорость

# Минимальная задержка (обычно < 1мс)
# Очень простой API
pubsub.subscribe('channel')
publisher.publish('channel', 'message')

• Очень быстрая доставка сообщений
• Низкие накладные расходы на обработку
• Простая и интуитивная API

2. Поддержка паттернов

# Подписка на паттерн
pubsub.psubscribe('news.*')

# Издатель отправляет в разные каналы
publisher.publish('news.tech', 'Tech news')
publisher.publish('news.sports', 'Sports news')
publisher.publish('news.politics', 'Politics news')

# Подписчик получит все три сообщения

3. Горизонтальная масштабируемость издателей

# Можно иметь много издателей
for i in range(100):
    publisher.publish('orders', f'Order {i}')

# Один подписчик получит все сообщения

4. Низкое использование памяти

• Сообщения не хранятся, только передаются
• Нет накопления сообщений в памяти
• Redis просто проксирует данные

Минусы Pub/Sub (критические!)

1. Нет гарантии доставки сообщений

Это главный минус. Если подписчик не подключен в момент отправки, он не получит сообщение:

# Издатель отправляет сообщение
publisher.publish('orders', 'Order #123')

# Подписчик подключается ПОСЛЕ отправки
pubsub = subscriber.pubsub()
pubsub.subscribe('orders')

# Сообщение потеряно навсегда!
# Подписчик НЕ получит "Order #123"

Проблема в распределенных системах:

# Сценарий сбоя
# 1. Издатель отправляет сообщение
publisher.publish('notifications', 'Important event')

# 2. Подписчик был подключен, но упал до обработки
# 3. Сообщение потеряно при восстановлении

2. Отсутствие персистентности

Сообщения полностью теряются при перезагрузке Redis:

# Издатель отправляет
publisher.publish('alerts', 'Critical alert')

# Redis перезагружается (maintenance, crash, failover)
# Все сообщения исчезли из памяти

# Подписчики не получат эти сообщения

Аже RDB и AOF не спасают:

# RDB snapshots НЕ сохраняют состояние pub/sub
# AOF НЕ записывает publish сообщения
# Только значения в памяти (хэши, строки, списки)

3. Нет гарантии порядка при множественных подписчиках

# Если несколько подписчиков
subscriber1.pubsub().subscribe('chat')
subscriber2.pubsub().subscribe('chat')

# Они могут получить сообщения в разном порядке
# нет гарантии FIFO
publisher.publish('chat', 'Message 1')
publisher.publish('chat', 'Message 2')

4. Сложность обработки ошибок

# Нет встроенного механизма retry
# Если обработка сообщения упала
try:
    message = pubsub.get_message()
    process(message)  # Может упасть
    # Нет способа переотправить сообщение!
except Exception as e:
    # Сообщение потеряно
    pass

5. Нет истории/replay сообщений

# Новый подписчик подключается
new_subscriber.pubsub().subscribe('events')

# Но старые сообщения он НЕ получит
# Нет способа получить историю
# (в отличие от Kafka или RabbitMQ)

6. Одноранговое соединение

Проблемы с надежностью при разрыве соединения:

# Подписчик подключен
pubsub = redis.pubsub()
pubsub.subscribe('channel')

# Сетевой сбой или таймаут
# Соединение разрывается

# Подписчик НЕ знает, что произошло
# Потеря сообщений неизбежна

Когда использовать Redis Pub/Sub

Приемлемо для:

# 1. Live уведомления (можно потерять)
publisher.publish('live-scores', 'Goal! 1-0')

# 2. Broadcast обновлений в режиме реального времени
publisher.publish('user-activity', f'User {id} logged in')

# 3. Кэширование инвалидации
publisher.publish('cache-invalidate', 'product:123')

# 4. Синхронизация статуса между сервисами
publisher.publish('service-status', 'service:ready')

Когда НЕ использовать Redis Pub/Sub

Неприемлемо для:

# 1. Критичные бизнес-события (заказы, платежи)
# НЕПРАВИЛЬНО:
publisher.publish('orders', json.dumps(order))

# ПРАВИЛЬНО: использовать очередь
queue.put(order)  # RabbitMQ, Celery, Kafka

# 2. Гарантированная обработка
# НЕПРАВИЛЬНО: удаление из БД без подтверждения
publisher.publish('delete-user', user_id)

# 3. Требуется история сообщений
# НЕПРАВИЛЬНО: логирование событий
publisher.publish('events', event_data)

# ПРАВИЛЬНО: использовать Kafka или EventLog

Альтернативы для устойчивости

1. Redis Streams (лучше для очередей)

# Сохраняет сообщения (персистентность)
stream_key = redis.xadd('orders', {'data': order})

# Читать сообщения
messages = redis.xrange('orders')

# Consumer groups для отслеживания обработки
redis.xgroup_create('orders', 'order-workers', id='0')
result = redis.xreadgroup({'orders': '>'}, 'order-workers')

2. RabbitMQ (production-ready)

import pika

connection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()

# Гарантированная доставка
channel.queue_declare(queue='orders', durable=True)
channel.basic_publish(
    exchange='',
    routing_key='orders',
    body=json.dumps(order),
    properties=pika.BasicProperties(delivery_mode=2)  # persistent
)

3. Apache Kafka (масштабируемость)

from kafka import KafkaProducer, KafkaConsumer

producer = KafkaProducer(bootstrap_servers=['localhost:9092'])
producer.send('orders', json.dumps(order).encode())

consumer = KafkaConsumer('orders', bootstrap_servers=['localhost:9092'])
for message in consumer:
    process(message.value)

Итоговая таблица

Вывод: Redis Pub/Sub отлично подходит для real-time уведомлений, где потеря нескольких сообщений приемлема. Для критичных операций нужно использовать более надежные системы обмена сообщениями.