Как сделать отказоустойчивой толерантной обработку данных в модулях k8s?

Question

У нас есть конвейер обработки изображений в GKE, который подается из GCP Topi c, который, в свою очередь, подается посредством уведомлений корзины, то есть

image upload > bucket > notification > topic < pods consume files off topic.

Это масштабируется красиво, но иногда только d ie или получить вниз и вместе с ними данные из топи c, которые они потребляли. Существует ли шаблон дизайна контейнера, обеспечивающий обработку файла, даже если модуль неожиданно умирает?

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

Answer 1

Да, я просто долго размышлял над этим и придумал решение для 2 очередей с тем, что я собираюсь назвать, модулем / контейнером бухгалтера (так как идея основана на бухгалтерском учете двойной записи):

1. Рабочие места публикуются в 2 очередях, Q1 и Q2
2. Рабочие обрабатывают сообщения Q1, пока они не опустеют
3. Когда Q1 пуст, модуль бухгалтера go до Q2 проверка ожидаемого выхода для каждой работы. Если чего-то не хватает, его снова кладут на Q1 и Q2 (после исчерпания Q2).
4. Повторяйте, пока бухгалтер ничего не отправит обратно в очередь.

Я называю это шаблоном: Double-Entry / Accountant Design:)

Я думаю, что это применимо к большинству систем очередей обработки данных.

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