Когда следует прекратить обработку сообщений в случае сбоя очереди / базы данных?

Question

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

• Предположим, что транзакционность перебирает атомарный коммит; Что такое хорошая политика, когда вообще закрывать приложение?
• В случае сбоя базы данных приложение может быть переполнено сообщениями, которые оно в итоге отклонит. Должен ли он немедленно сдаться?
• В случае сбоя службы исходящих сообщений база данных будет заполнена откатами. Опять же, лучше ли сразу сдаваться?

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

Answer 1

Как уже упоминалось в cracked_all, не рекомендуется сдаваться немедленно.

Я думаю, что лучшим способом было бы подготовить другие базы данных к работе, так как первичные сбои. Получив неудачное подтверждение, вы можете направить их на дополнительный. Таким образом, вы не теряете так много данных. В этом случае вы можете использовать функцию «Гарантированная доставка» в JMS.

С гарантированной доставкой система обмена сообщениями использует встроенное хранилище данных для сохранения сообщений. Каждый компьютер, на котором установлена ​​система обмена сообщениями, имеет свое собственное хранилище данных, чтобы сообщения могли храниться локально. Когда отправитель отправляет сообщение, операция отправки не завершается успешно, пока сообщение не будет безопасно сохранено в хранилище данных отправителя. Впоследствии сообщение не удаляется из одного хранилища данных, пока оно не будет успешно передано и сохранено в следующем хранилище данных. Таким образом, после того, как отправитель успешно отправил сообщение, оно всегда сохраняется на диске хотя бы на одном компьютере, пока не будет успешно доставлено и подтверждено получателем. 1

Answer 2

Насколько я понимаю, вы ищете следующее:

1. Не теряйте сообщения из входящей очереди только потому, что приложение не может их обработать.
2. Когда останавливать обработку, если во время обработки возникают ошибки.

Прежде всего, важно проанализировать инфраструктуру, с которой вы имеете дело, и тип ситуаций, с которыми вам придется иметь дело. Типичные времена простоя и как часто они происходят на разных уровнях системы. Насколько надежна сеть, являетесь ли вы db rac сервером и т. Д.

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

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