Как обрабатывать сбои во время итерации по очень большому списку (> 100 000)

Question

Наша система обрабатывает более 100 000 подписчиков.Еженедельно другое внешнее приложение создает специальный файл (ы), содержащий финансовую информацию пользователей с> 100 000 строк.Наше приложение должно проанализировать его и обработать каждую запись (отправьте sms / mms / email в нашем случае).Конечно, эти операции отнимают много времени, поэтому мы выполняем их асинхронно через JMS.

Но сначала нам нужно поместить все записи в очередь.Тест производительности показал, что на это уходит около 30-40 минут и даже больше.По сути, мы перебираем весь список из 100 000 элементов и помещаем сообщения в очередь JMS по одному.Предположим, что на 50000-й итерации происходит сбой системы.Если мы не заботимся о логике восстановления, вторая половина пользователей не получит никакого сообщения.Если мы просто перезапустим процесс, первая половина пользователей получит 2 идентичных СМС.

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

1. Сохранить счетчик итераций в некотором постоянном хранилище - возможно, предпочтительнее, порядок такой же, как в файле

2. Сериализация состояния процесса для некоторого постоянного хранилища - плохая производительность?

3. Сохранение всего списка и статусов обновления - плохая производительность, бесполезнаяданные? Для всех них данные о состоянии обновляются в постоянное хранилище на каждой итерации.

Какой из них выбрать?И какой лучший выбор для постоянного хранения здесь (простой, быстрый, надежный)?

Кто-нибудь знает какое-либо решение / шаблон, который обычно применяется в подобных случаях?Или вы уже столкнулись с той же проблемой и можете предложить свой подход?Любая помощь будет оценена!Заранее спасибо!

Answer 1

Я настоятельно рекомендую вам использовать Пружинную партию , специально разработанную для ваших нужд. Он не должен иметь проблем при обработке 100 000+ строк, дает вам возможность перезапустить (с момента сбоя), повторить попытку и т. Д.

Answer 2

Потому что то, что вы делаете с записями (одна запись не заботится о том, была ли успешно отправлена ​​следующая или предыдущая, нет), я не думаю, что нужно останавливаться, если есть ошибка или вы беспокоитесь о перезапуске сцарапина;Мое предположение заключается в том, чтобы обработать все записи, которые вы можете, а затем выяснить, как исправить / повторно обработать сбои.

Единственное, на что вы можете обратить внимание - это какая-то системная ошибка:бессмысленно пытаться обработать записи по 100 КБ, если первые 50 не будут выполнены по одной и той же причине - например, сбой сети.

В случае, если вы захотите вернуться и повторно выполнить сбои, я склонен кскопировать снимок данных для обработки и добавить к ним данные обработки (отправлено успешно @ dd-mm-yy, hh: mm: ss, Failed и т. д.).В качестве альтернативы просто зарегистрируйте все сбои в вашей стандартной системе регистрации.

Answer 3

Является ли ваш JMS-провайдер транзакционным? Если это так, вы можете запустить весь процесс в одной транзакции JMS. Брокер не позволит потребителям обрабатывать какое-либо сообщение, пока транзакция, отправившая его, не зафиксируется. Таким образом, если в любой момент произойдет сбой процесса импорта, брокер автоматически откатит все отправленные сообщения.

Затем можно перезапустить процесс с нуля.

Кстати, 30-40 минут для отправки 100K сообщений в очередь JMS (около 50 мс / с)? Я только что провел быстрый тест с веб-интерфейсом ActiveMQ 5.5.0, и отправка сообщений размером 100 КБ занимает около 1-2 минут ...