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

71
8

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


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


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


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


    Сериализуйте состояние процесса в некотором постоянном хранилище - плохая производительность?


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

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


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

спросил(а) 2011-09-08T20:25:00+04:00 9 лет, 1 месяц назад
1
Решение
59

Я бы очень рекомендовал вам использовать Spring пакет, который предназначен для конкретного удовлетворения ваших потребностей. У него не должно быть проблем с обработкой 100 000 строк, что дает вам возможность перезапускать (с момента сбоя), повторить попытку и т.д.

ответил(а) 2011-09-08T20:28:00+04:00 9 лет, 1 месяц назад
42

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


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


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

ответил(а) 2011-09-09T05:55:00+04:00 9 лет, 1 месяц назад
41

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


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

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

ответил(а) 2011-09-08T20:35:00+04:00 9 лет, 1 месяц назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема