Устранение распространенных проблем конфигурации Redis Pub/Sub

Redis Pub/Sub настолько прост, что команды часто относятся к нему как к крошечному брокеру сообщений, не требующему обслуживания. Издатель вызывает PUBLISH, подписчики получают сообщения, и все кажется мгновенным.

Проблемы начинаются, когда в дело вступают реальные сети, медленные клиенты, переподключения и общие экземпляры Redis. Pub/Sub не имеет истории сообщений, подтверждений и очереди повторных попыток. Это механизм прямой трансляции. Если подписчик отключен, сообщение для него теряется. Если подписчик подключен, но не может читать достаточно быстро, Redis вынужден удерживать ожидающие вывода данные для этого клиента, пока настроенный лимит не отключит его.

Это делает Redis Pub/Sub отличным выбором для инвалидации кэша, обновлений присутствия, информационных панелей в реальном времени и уведомлений о «последнем значении». Он плохо подходит для рабочих процессов, где каждое сообщение должно быть обработано ровно один раз или воспроизведено после сбоя. Для этого используйте Redis Streams, RabbitMQ, Kafka или другой брокер с отслеживанием доставки.

Симптом: рост памяти при высокой нагрузке Pub/Sub

Наиболее распространенная ошибка Pub/Sub — медленный подписчик. Издатель работает нормально. Redis поначалу тоже в порядке. Один потребитель отстает, потому что его процесс приостановлен, его сеть медленная или он выполняет ресурсоемкую работу внутри обработчика сообщений. Redis продолжает записывать сообщения в выходной буфер этого клиента. Если буферу позволено расти без полезного ограничения, давление на память распространяется от одного плохого подписчика на весь экземпляр.

Проверьте клиентов:

redis-cli CLIENT LIST

Ищите клиентов с командами Pub/Sub и большим объемом выходной памяти:

id=88 addr=10.0.4.12:51244 flags=P db=0 sub=3 psub=0 omem=13421772 obl=128 oll=64 cmd=subscribe

Полезные поля:

flags=P указывает на клиента Pub/Sub.
sub и psub показывают количество подписок на каналы и шаблоны.
omem — объем памяти выходного буфера в байтах.
obl и oll показывают детали журнала выходного буфера.
cmd=subscribe или cmd=psubscribe подтверждает, что делает клиент.

Не паникуйте из-за idle для подписчиков. Подключение Pub/Sub может простаивать с точки зрения команд, но при этом все еще получать отправляемые сообщения.

Исправление медленных потребителей с помощью лимитов выходного буфера

Redis предоставляет класс лимита выходного буфера для клиентов Pub/Sub:

client-output-buffer-limit pubsub 32mb 8mb 60

Это означает:

Немедленно отключить, если выходной буфер клиента Pub/Sub достигает 32 МБ.
Отключить, если он остается выше 8 МБ в течение 60 секунд.

Точные числа должны соответствовать вашему трафику и поведению клиентов. Распространенная ошибка — установка лимита 0 0 0, потому что отключения раздражают во время тестирования. Это убирает предохранитель. В продакшене отключение обычно лучше, чем позволить одному застрявшему подписчику потреблять память до тех пор, пока Redis не станет нестабильным.

После изменения redis.conf перезагрузите или перезапустите в соответствии с вашим процессом развертывания. Вы также можете проверить текущее значение:

redis-cli CONFIG GET client-output-buffer-limit

Если вы используете управляемый сервис Redis, эта настройка может быть доступна через группу параметров или интерфейс конфигурации провайдера, а не через прямое редактирование файла.

Симптом: подписчики подключаются, но ничего не получают

Начните с самого простого возможного теста. Откройте один терминал:

redis-cli SUBSCRIBE test.channel

Откройте другой:

redis-cli PUBLISH test.channel hello

Если это работает с хоста Redis, но не из вашего приложения, вероятно, проблема на стороне клиента или в сети. Если это не работает везде, проверьте аутентификацию, ACL, маршрутизацию кластера и фактическое имя канала.

Имена каналов — это точные строки байтов. events.user, events:User и events:user — это разные каналы. В больших системах я предпочитаю константы или небольшой модуль именования каналов вместо строк, введенных вручную и разбросанных по сервисам.

Подписки по шаблонам добавляют еще один источник путаницы:

PSUBSCRIBE events:*

Это соответствует events:user.created, но не prod:events:user.created. Если ваше приложение добавляет префикс имени окружения, включите префикс в шаблон.

Проблемы аутентификации и ACL

Современные развертывания Redis часто используют пользователей ACL вместо одного общего пароля requirepass. Клиенту Pub/Sub требуется разрешение на подключение, аутентификацию, подписку на шаблон канала, а иногда и на публикацию.

Быстрая проверка через CLI:

redis-cli -u redis://app-user:[email protected]:6379 PING
redis-cli -u redis://app-user:[email protected]:6379 SUBSCRIBE events:test

Распространенные симптомы аутентификации:

NOAUTH Authentication required: клиент отправил команду до аутентификации.
WRONGPASS invalid username-password pair: неверный пароль, неверный пользователь или измененный секрет, развернутый не везде.
NOPERM this user has no permissions: пользователь аутентифицирован, но не имеет разрешений на команды или каналы.

С ACL разрешения на каналы отделены от разрешений на ключи. Пользователю может быть разрешено выполнять обычные команды с ключами, но не подписываться на ожидаемые каналы. Проверьте настроенного пользователя:

redis-cli ACL GETUSER app-user

Не вставляйте продакшен-секреты в историю оболочки во время тестирования. По возможности используйте переменные окружения или временные учетные данные.

Не используйте подключения Pub/Sub совместно с обычными командами

Как только подключение переходит в режим подписки, оно больше не является обычным подключением для команд Redis. Оно получает отправляемые сообщения и может выполнять только команды, связанные с подпиской: SUBSCRIBE, UNSUBSCRIBE, PSUBSCRIBE, PUNSUBSCRIBE, PING, RESET или команды выхода в зависимости от клиента и версии Redis.

Если вы берете подключение из общего пула и вызываете SUBSCRIBE, это подключение из пула фактически становится недоступным для GET, SET или других обычных команд. Результат может выглядеть как случайные тайм-ауты приложения, потому что пул медленно заполняется подключениями, застрявшими в режиме подписчика.

Используйте отдельные подключения:

Один обычный клиент или пул для обычных команд Redis.
Одно долгоживущее подключение подписчика на процесс или поток подписчика.
Одно отдельное подключение издателя, если ваша клиентская библиотека рекомендует это.

Многие клиентские библиотеки предоставляют метод duplicate() или new connection для этой цели. Используйте его. Не надейтесь, что пул разберется сам.

Поведение при переподключении имеет значение

Pub/Sub не воспроизводит пропущенные сообщения после переподключения. Если подписчик отключается на 30 секунд, каждое сообщение, опубликованное в течение этого окна, теряется для этого подписчика.

Это приемлемо для инвалидации кэша только в том случае, если ваше приложение имеет запасной вариант. Например, сервис, пропустивший событие инвалидации, все равно должен иметь TTL, проверки версий или способ восстановления из исходной базы данных. Без запасного варианта одна сетевая вспышка может оставить устаревшие записи локального кэша на слишком долгое время.

При переподключении убедитесь, что клиент повторно подписывается на все каналы и шаблоны. Некоторые библиотеки делают это автоматически. Другие требуют повторной регистрации обработчиков после переподключения. Проверьте это, убив подключение подписчика:

redis-cli CLIENT LIST | grep subscribe
redis-cli CLIENT KILL ID <client-id>

Затем опубликуйте тестовое сообщение и подтвердите, что приложение получает его после переподключения.

Высокий fan-out может создать нагрузку на ЦП и сеть

Работа PUBLISH растет с количеством соответствующих подписчиков и шаблонов. Канал с тысячами подписчиков означает, что Redis должен отправить сообщение тысячи раз. Это может быть нормально, но не бесплатно.

Следите:

redis-cli INFO stats
redis-cli PUBSUB NUMSUB events:test
redis-cli PUBSUB NUMPAT

PUBSUB NUMSUB помогает подтвердить, имеет ли канал то количество подписчиков, которое вы предполагаете. PUBSUB NUMPAT полезен, потому что широкие подписки по шаблонам могут вас удивить. Несколько сервисов, использующих PSUBSCRIBE * или PSUBSCRIBE events:*, могут получать гораздо больше трафика, чем предполагалось.

Если трафик Pub/Sub важен и имеет высокий объем, изолируйте его. Выделенный экземпляр Redis для Pub/Sub защищает ваш кэш и хранилище сессий от проблем с буферами подписчиков и всплесков широковещательной рассылки. Выделенный экземпляр может иметь конфигурацию, оптимизированную для Pub/Sub, более короткие проблемы с сохранением и мониторинг, ориентированный на клиентов и сетевой вывод.

Держите обработчики сообщений короткими

Подписчик должен прочитать сообщение, выполнить минимальную проверку и передать работу чему-то другому. Если обработчик вызывает базу данных, делает HTTP-запрос, рендерит шаблон или выполняет длительное вычисление перед чтением следующего сообщения, он может стать тем медленным потребителем, которого вы пытаетесь избежать.

Лучшая форма:

Сообщение Redis -> легковесный обработчик -> локальная очередь -> пул воркеров

Локальная очередь может быть внутрипроцессной очередью, пулом потоков, асинхронной очередью задач или надежным брокером, если работа должна пережить перезапуски процессов. Ключевая идея в том, что чтение из Redis не должно ждать самую медленную зависимость ниже по потоку.

Если работа должна быть надежной, Pub/Sub — неправильный примитив. Redis Streams с группами потребителей предоставляет ожидающие записи и подтверждения. Выделенный брокер может быть лучше, если вам нужны очереди недоставленных сообщений, отложенные повторные попытки, приоритеты или длительное хранение.

Практический контрольный список для устранения неполадок

Когда Pub/Sub выглядит нездоровым, я обычно работаю в таком порядке:

Подтвердите канал вручную с помощью SUBSCRIBE и PUBLISH.
Проверьте CLIENT LIST на наличие клиентов Pub/Sub с высоким omem.
Проверьте client-output-buffer-limit pubsub.
Проверьте аутентификацию и разрешения каналов ACL.
Убедитесь, что подписчики используют выделенные подключения.
Убейте подключение подписчика и проверьте поведение при переподключении и повторной подписке.
Проверьте PUBSUB NUMSUB и PUBSUB NUMPAT на предмет неожиданного fan-out.
Решите, нужна ли рабочей нагрузке на самом деле Streams или выделенный брокер.

Redis Pub/Sub надежен только в том смысле, что он делает именно то, что обещает: прямая трансляция сообщений текущим подключенным подписчикам. Большинство инцидентов в продакшене происходит из-за ожидания, что он будет вести себя как надежная очередь. Настройте лимиты буферов, изолируйте тяжелый трафик и проектируйте подписчиков так, как будто сообщения могут быть пропущены, потому что иногда они могут.

Пример инцидента: одна панель замедляет кэш

Представьте экземпляр Redis, используемый для обычных ключей кэша и небольшого канала Pub/Sub под названием metrics:live. Сначала подписывается только внутренняя панель. Месяцами позже подписываются несколько процессов шлюза браузера, и один из них начинает отправлять обновления через медленные WebSocket-соединения. Redis не знает, что нижестоящий браузер медленный. Он видит только подключение подписчика, которое не читает достаточно быстро.

Первый симптом может вообще не упоминать Pub/Sub. Запросы приложения, использующие обычные вызовы GET и SET, начинают выдавать тайм-ауты. Память растет. Хост Redis выглядит занятым, но SLOWLOG не показывает очевидной дорогой команды.

Полезная подсказка — в CLIENT LIST:

flags=P sub=1 omem=25165824 cmd=subscribe

Это говорит вам, что у клиента Pub/Sub большой выходной буфер. Если настроенный жесткий лимит составляет 32 МБ, этот клиент близок к отключению. Если лимит отключен, Redis может продолжать буферизацию, пока весь экземпляр не окажется под давлением памяти.

Исправление заключается не просто в повышении лимита. Повышение может скрыть проблему и позволить более сильному скачку памяти в следующий раз. Лучший ответ:

Определите процесс подписчика по addr, name или метаданным клиента.
Убейте худшего подписчика, если память под угрозой.
Добавьте или ужесточите client-output-buffer-limit pubsub.
Переместите медленную нижестоящую доставку во внутреннюю очередь вне цикла чтения Redis.
Рассмотрите возможность перемещения высокообъемного Pub/Sub на выделенный экземпляр Redis.

Имена клиентов значительно упрощают это. Многие библиотеки Redis позволяют задать имя подключения. Используйте имена, такие как web-1:pubsub-cache-invalidations или dashboard:metrics-live, чтобы CLIENT LIST указывал на владельца, а не только показывал IP и порт.

CLIENT SETNAME dashboard:metrics-live

Эта небольшая гигиена превращает расплывчатый инцидент с памятью в прямой разговор с командой, владеющей подписчиком.