Как масштабировать Redis Queue

Question

Мы переходим с Monolithi c на микросервисную архитектуру для нашего приложения для электронной коммерции. Мы выбрали Redis pub / sub для связи между микросервисами и микросервисами, а также для некоторых целей уведомления pu sh. Стратегия уведомления Pu sh выглядит следующим образом:

Каждый раз, когда создается заказ (т.е. покупатель создает заказ), серверная часть публикует событие в соответствующем канале (очереди) и указанном c pu sh -notification-microservice потребляет это событие (json сообщение) и отправляет уведомление pu sh на мобильный телефон продавца.

В настоящее время мы используем redis-server, установленный на нашей машине ubuntu, без каких-либо хлопот. Но головная боль в будущем, когда миллионы заказов будут сгенерированы в определенный момент времени, тогда как мы можем справиться с этой ситуацией? Это означает, что нам нужно масштабировать Redis Queue, верно?

Мой точный чистый вопрос (независимо от приведенного выше сценария):

Как я могу масштабировать Redis Queue по горизонтали вместо увеличения RAM на той же машине?

Answer 1

Каждый раз, когда создается заказ (т. Е. Покупатель создает заказ), серверная часть публикует событие в соответствующем канале (очереди), и указанный c pu sh -notification-microservice использует это событие ( json message) и отправляет уведомление pu sh на мобильный телефон продавца.

IIU C вы отправляете сообщение через Redis PUB / SUB, это ненадежно, это означает, что только производитель работает, а другие услуги / потребители не работают, тогда потребители будут пропускать сообщения. Любые неработающие службы потеряют все сообщения, которые были отправлены, когда указанная служба была отключена.

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

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

Очень просто вы можете распределять нагрузки на основе userId, например, если userId находится между 0 и 1000, тогда используйте queue_0, 1000-2000 queue_1 и т. д. Это ручной процесс, который можно автоматизировать с помощью сценария. Всякий раз, когда в набор добавляется новая очередь, все потребители должны быть уведомлены, а издатель также будет обновлен.

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

Вы можете рассмотреть возможность использования Rqueue