Redis Pub/Sub с надежностью

Я искал использование Redis Pub/Sub в качестве замены RabbitMQ.

Из моего понимания Redis pub/sub хранит постоянное соединение с каждым из абонентов, и если соединение прекращается, все будущие сообщения будут потеряны и сброшены на пол.

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

  • что происходит, когда абонент умирает и возвращается в Интернет, как он должен обрабатывать все ожидающие сообщения сообщения?
  • Когда в системе появляется неверное сообщение, как вы справляетесь с этими исключениями? Очередь DeadLetter?
  • Существует ли стандартная практика реализации политики повтора?

Ответы

Ответ 1

Когда абонент (потребитель) умирает, ваш список будет продолжать расти до тех пор, пока клиент не вернется. Ваш производитель может обрезать список (с каждой стороны), когда он достигнет определенного предела, но это то, что вам нужно будет обрабатывать на уровне приложения. Если вы включаете метку времени в каждое сообщение, ваш потребитель может затем действовать в соответствии с возрастом сообщения, предполагая, что у вас есть логика приложения, которую вы хотите применить в возрасте сообщения.

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

Политики повтора будут в значительной степени зависеть от потребностей вашего приложения. Если вам требуется 100% уверенность в том, что сообщение получено и обработано, вам следует рассмотреть возможность использования транзакций Redis (MULTI/EXEC) для переноса работы, выполняемой потребителем, чтобы вы могли убедиться, что клиент не удаляет сообщение, если только он завершил свою работу. Если вам требуется четкое подтверждение, вы можете использовать явное сообщение ACK в очереди, посвященной процессам (-ам) производителя.

Не зная больше о потребностях вашего приложения, трудно понять, как правильно выбирать. Как правило, если ваши сообщения требуют полной защиты ACID, вам также, вероятно, также придется использовать транзакции redis. Если ваши сообщения имеют смысл только тогда, когда они являются своевременными, тогда транзакции могут не понадобиться. Похоже, вы не можете терпеть упавшие сообщения, поэтому ваш подход к использованию списка хорош. Если вам нужно реализовать приоритетную очередь для своих сообщений, вы можете использовать отсортированный набор (Z-команды) для хранения ваших сообщений, используя их приоритет как значение оценки, а также потребитель опроса.

Ответ 2

То, что я сделал, это использовать отсортированный набор, используя метку времени, как счетчик и ключ к данным в качестве значения члена. Я использую счет из последнего элемента, чтобы получить следующие несколько, а затем получить ключи. После завершения работы я обертываю как zrem, так и del в транзакции MULTI/EXEC.

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

Надеюсь, это поможет!