ServiceStack Redis Mq: является ли возможная согласованность проблемой? - PullRequest
Новая
       50

ServiceStack Redis Mq: является ли возможная согласованность проблемой?

2 голосов
/ 29 мая 2020

Я собираюсь превратить монолитное приложение в приложение, ориентированное на микросервисы, и для этого мне понадобится надежная система обмена сообщениями для межпроцессного взаимодействия. Идея состоит в том, чтобы процессы микросервисов выполнялись на кластере серверов для обеспечения высокой доступности, с запросами, которые должны обрабатываться для добавления в очередь сообщений, к которой могут получить доступ все приложения. Я рассматриваю Redis как хранилище KV для временных данных, а также как брокер сообщений с использованием инфраструктуры ServiceStack для. Net, но меня беспокоит, что концепция конечной согласованности, применяемая Redis, сделает обработку запросов ненадежной. . Вот как я понимаю, что Redis работает в отношении Mq:

  1. Клиент 1 отправляет запрос в очередь на узле 1
  2. Узел 1 проинформирует всех слушателей в этой очереди с помощью pub / sub наличия запроса, а также будет асинхронно pu sh запросы к узлу 2.
  3. Слушатели на узле 1 будут получать запрос от узла, только 1 из них получит его должным образом. Обновление об удалении запроса отправляется на узел 2 асинхронно, но его получение займет некоторое время.
  4. Первоначальный запрос получен узлом 2 (с учетом небольшой задержки в RTT), который будет go впереди и проинформирует подключенных к нему слушателей с помощью pub / sub. Перед тем, как от узла 1 будет получено обновление об удалении запроса из очереди, слушатель на узле 2 также может вытащить запрос. В результате два слушателя обработали один и тот же запрос, что вызвало бы havo c в нашей системе.

Есть ли что-нибудь в Redis или реализации ServiceStack Redis Mq, что предотвратило бы сценарий описано, чтобы происходить? Или есть что-то еще в отношении репликации в Redis, что я неправильно понял? Или мне следует отказаться от подхода Redis / SS для Mq и использовать вместо него что-то вроде RabbitMQ, которое, как я понял, является ACID-совместимым?

1 Ответ

1 голос
/ 29 мая 2020

Невозможно, чтобы одно и то же сообщение было обработано дважды в Redis MQ , поскольку обработчик сообщений выталкивает сообщение из Redis List поддерживаемого MQ, и все операции Redis выполняются atomi c поэтому никакой другой обработчик сообщений не будет иметь доступа к сообщениям, которые были удалены из списка.

ServiceStack.Redis (который использует Redis MQ) поддерживает только Redis Sentinel для HA , что, несмотря на Redis поддерживая несколько реплик , они содержат только представление основного набора данных только для чтения, поэтому все операции записи, такие как операции добавления / удаления списка, могут выполняться только на одном главном экземпляре.

Одно заметное отличие от использования Redis MQ вместо c целевого MQ, такого как Rabbit MQ, заключается в том, что Redis не поддерживает ACK, поэтому, если рабочий процесс сообщения, который выводит сообщение из MQ, вылетает, тогда это сообщение теряется, в отличие от Rabbit MQ, где, если соединение с состоянием сообщения un Ack'd умирает, сообщение восстанавливается сервером RabbitMQ обратно в MQ.

...