Исходный код вики Диллема обработки сообщений
Версия 5.5 от Alexandr Fokin на 2024/02/02 10:14
Скрыть последних авторов
author | version | line-number | content |
---|---|---|---|
![]() |
5.3 | 1 | | |((( |
![]() |
2.1 | 2 | Ситуация: |
![]() |
5.3 | 3 | Имеется очередь, из которой приложение читает данные и обрабатывает их. Рассмотрим пример, что приложение имеет следующий цикл обработки сообщения: |
![]() |
2.1 | 4 | |
5 | 1) Взять сообщение из очереди | ||
6 | 2) Попытаться выполнить некоторый набор действий на основе данных из сообщения. | ||
7 | Отметим, что обработка сообщения может завершиться как успешно, так и с ошибкой. | ||
8 | |||
9 | Вариации: | ||
10 | |||
11 | 1] | ||
12 | 1) Получаем сообщение | ||
![]() |
5.3 | 13 | 2) Выполняем коммит сообщения (при следующем чтении на вход пойдет следующее сообщение) |
![]() |
2.1 | 14 | 3) Выполняем обработку |
15 | |||
16 | 2] | ||
17 | 1) Получаем сообщение | ||
18 | 2) Выполняем обработку | ||
![]() |
5.3 | 19 | 3) Если п.2 выполнен успешно, то выполняем коммит сообщения (при следующем чтении на вход пойдет следующее сообщение) |
![]() |
2.1 | 20 | |
21 | Возможные проблемы | ||
![]() |
3.1 | 22 | 1) При потходе 1, мы теряем сообщение, в случае если его обработка не завершилась успешно. |
![]() |
5.3 | 23 | 2) При потходе 2, в случае, если после выполнения 2 пункта наше приложение упадет (не успев выполнить пункт 3), то при повторном запуске мы обработаем то-же самое сообщение второй раз. |
![]() |
2.1 | 24 | |
25 | Вопросы | ||
26 | 1) Является ли повторная обработка одного и того же сообщения допустимой для нашей системы. | ||
![]() |
5.1 | 27 | 2) Является ли потеря данных из одного из сообщений критичной для нашей системы. |
![]() |
5.3 | 28 | 3) Возможно в нашей системе производитель сообщение, генерирует сообщени3) Возможно в нашей системе производитель сообщение, генерирует сообщен3) Возможно в нашей системе производитель сообщение, генерирует сообщение повторно через некоторой промежуток времени, если фиксирует, что предыдущее сообщение не было обработано. |
![]() |
5.1 | 29 | |
30 | |||
31 | Более надежное, но более тяжелое решение: | ||
32 | Использование потхода номер 2 совместно с каким-либо более продвинутым механизмом транзакций. Т.е в случае падения приложения транзакция не будет завершена успешно. | ||
![]() |
4.1 | 33 | Но есть риск если у нас выполняются 2 действия: |
![]() |
3.1 | 34 | 1) коммит транзакции в базе, 2) коммит сообщения. (или в порядке 2, 1) |
35 | В случае падения приложения между указанными шагами, мы все равно можем получить | ||
![]() |
5.3 | 36 | либо потерю сообщения (закоммитили сообщение, но не завершили транзакцию), |
![]() |
4.1 | 37 | либо повторную обработку (завершили транзакцию, но не закоммитил сообщение). |
![]() |
3.1 | 38 | Хоть и вероятность такого события в целом крайне мала. (зависит от системы) |
![]() |
5.3 | 39 | ))) |
40 | | |((( | ||
41 | Замечание: на текущий момент отношу проблему к [[Dual write problem>>doc:Архитектура и модели.Группа\. Распределенные системы.Распределенные системы\. Консистентность.Dual write problem.WebHome]]. | ||
![]() |
5.5 | 42 | По хорошему у каждого запроса или хотя бы сообщения должен быть уникальный ключ. Использую его, транзакцию, таблицу с уникальным индексом можно добиться гарантии, что сообщение будет обработано только единожды. Транзакция БД позволяет атомарно зафиксировать и изменения и факт обработки сообщения (по его ключу). |
![]() |
2.1 | 43 | |
![]() |
5.4 | 44 | Отдельный вопрос: хотим ли мы использовать очередь для приостановки обработки в случае ошибок. Зачастую мы не хотим останавливать обработку из-за одной ошибки. В таком случае важно сохранить проблемное сообщение, но при этом сделать так чтобы обработчик продолжил обрабатывать последующие сообщения. |
45 | |||
![]() |
5.3 | 46 | Возможен вариант, когда сообщение просто записывается в БД в статусе ожидает обработку. И фоновый обработчик разбирает таблицу и обрабатывает необходимые строки. |
47 | ))) | ||
48 | | | | ||
![]() |
2.1 | 49 | |
50 | |||
![]() |
5.3 | 51 |