Упругая обработка сообщений от RabbitMQ - PullRequest
0 голосов
/ 06 мая 2019

Я не уверен, как правильно обрабатывать сообщения RabbitMQ в случае периодического сбоя.

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

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

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

1 Ответ

0 голосов
/ 06 мая 2019

Это широкая тема, но со стороны сервера вы можете сохранить свои сообщения и сделать ваши очереди надежными, это означает, что в случае перезапуска сервера они не будут потеряны, проверьте больше здесь Как сохранить сообщенияво время перезапуска брокера RabbitMQ?

Для потребителя (клиента) это будет зависеть от того, как вы конфигурируете своего клиента, из документов:

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

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

Проверьте больше здесь: https://www.rabbitmq.com/reliability.html#consumer

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