Redis Pub/Sub

Преимущества и недостатки

Скорее всего в вашем проекте уже используется Redis. Если вы хотите использовать асинхронную отправку сообщений, но не хотите внедрять новую тяжеловесную зависимость (Kafka, RabbitMQ, Nats и тд) в свою инфраструктуру, вам стоит воспользоваться им в качестве брокера сообщений.

Redis работает быстро, не деградирует при большом количестве сообщений и самое главное - он уже у вас есть!

Note

Подробнее с документацией Redis Pub/Sub вы можете ознакомиться на официальном сайте

Однако, Redis в качестве брокера сообщений обладает некоторыми существенными недостатками:

• Сообщения не персистентны. Если сообщение будет опубликовано пока ваш потребитель отключен - оно будет потеряно.
• Отсутсвует возможность горизонтального масштабирования потребителей.
• Отстутствуют механизмы сложной маршрутизации.
• Отстутствуют механизмы подтверждения получения и обработки сообщений со стороны потребителя.
• Сообщения представлены сырыми байтами без метаинформации.

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

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

Также, Redis 5.0+ содержит механизм Streams, который также может служить в роли брокера сообщений и закрывает основные недостатки Redis Pub/Sub: персистентность сообщений и масштабирование потребителей.

Правила маршрутизации

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

Оба примера рассмотрены чуть далее.

Особенности Propan

Так как Redis в качестве сообщения использует просто набор байт без заголовков и прочей метаинформации, Propan в качестве сообщения использует закодированный json со следующей структурой:

{
    "data": "",
    "headers": {},
    "reply_to": ""
}

Это необходимо для корреткного распознавания content-type входящего сообщения (необходимо для правильного декодирования) и поддержки RPC запросов.

Если Propan получает сообщение, отправленное с помощью другой библиотеки или фреймворка (или просто сообщение другого формата), все тело этого сообщение будет воспринято как поле data принимаемого сообщения, а content-type будет распознан автоматически.

При этом RPC запросы не будут работать, так как во входящем сообщении нет поля reply_to.