Изменения документа Диллема обработки сообщений

Редактировал(а) Alexandr Fokin 2024/06/12 16:21

<
От версии < 3.1 >
отредактировано Alexandr Fokin
на 2020/08/09 15:29
К версии < 5.3 >
отредактировано Alexandr Fokin
на 2024/02/02 10:03
>
Изменить комментарий: К данной версии нет комментариев

Комментарий

Подробности

Свойства страницы
Название
... ... @@ -1,1 +1,1 @@
1 -Обработка с транзакцией
1 +Диллема обработки сообщений
Родительский документ
... ... @@ -1,1 +1,1 @@
1 -Архитектура и модели.WebHome
1 +Архитектура и модели.Модели.Конвейер и Запрос-Ответ.WebHome
Содержимое
... ... @@ -1,6 +1,6 @@
1 -
1 +| |(((
2 2  Ситуация:
3 -Имееться очередь, из которой приложение читает данные и обрабатывает их. Рассмотрим пример, что приложение имеет следующий цикл обработки сообщения:
3 +Имеется очередь, из которой приложение читает данные и обрабатывает их. Рассмотрим пример, что приложение имеет следующий цикл обработки сообщения:
4 4  
5 5  1) Взять сообщение из очереди
6 6  2) Попытаться выполнить некоторый набор действий на основе данных из сообщения.
... ... @@ -10,29 +10,42 @@
10 10  
11 11  1]
12 12  1) Получаем сообщение
13 -2) Выполняем коммит (при следующем чтении на вход пойдет следующее сообщение)
13 +2) Выполняем коммит сообщения (при следующем чтении на вход пойдет следующее сообщение)
14 14  3) Выполняем обработку
15 15  
16 16  2]
17 17  1) Получаем сообщение
18 18  2) Выполняем обработку
19 -3) Если п.2 выполнен успешно, то выполняем коммит (при следующем чтении на вход пойдет следующее сообщение)
19 +3) Если п.2 выполнен успешно, то выполняем коммит сообщения (при следующем чтении на вход пойдет следующее сообщение)
20 20  
21 21  Возможные проблемы
22 22  1) При потходе 1, мы теряем сообщение, в случае если его обработка не завершилась успешно.
23 -2) При потходе 2, в случае, если после выполнения 2 пунтка наше приложение упадет (не успев выполнить пункт 3), то при повтроном запуске мы обработаем то-же самое сообщение второй раз.
23 +2) При потходе 2, в случае, если после выполнения 2 пункта наше приложение упадет (не успев выполнить пункт 3), то при повторном запуске мы обработаем то-же самое сообщение второй раз.
24 24  
25 25  Вопросы
26 26  1) Является ли повторная обработка одного и того же сообщения допустимой для нашей системы.
27 -2) Является ли потеря данных из одного из сообщений критичной для нашей системы
28 -3) Использование потхода номер 2 совместно с каким-либо более мродвинутым механизмом транзакции. Т.е в случае падения приложения транзакция не будет завершена успешно.
29 -Но еть риск если у нас выполняются 2 действия:
27 +2) Является ли потеря данных из одного из сообщений критичной для нашей системы.
28 +3) Возможно в нашей системе производитель сообщение, генерирует сообщени3) Возможно в нашей системе производитель сообщение, генерирует сообщен3) Возможно в нашей системе производитель сообщение, генерирует сообщение повторно через некоторой промежуток времени, если фиксирует, что предыдущее сообщение не было обработано.
29 +
30 +
31 +Более надежное, но более тяжелое решение:
32 +Использование потхода номер 2 совместно с каким-либо более продвинутым механизмом транзакций. Т.е в случае падения приложения транзакция не будет завершена успешно.
33 +Но есть риск если у нас выполняются 2 действия:
30 30  1) коммит транзакции в базе, 2) коммит сообщения. (или в порядке 2, 1)
31 31  В случае падения приложения между указанными шагами, мы все равно можем получить
32 -либо потерю (из-за незавершенной транзакции), либо повторнуб обработку из-за незакоммиченного сообщения очреди.
36 +либо потерю сообщения (закоммитили сообщение, но не завершили транзакцию),
37 +либо повторную обработку (завершили транзакцию, но не закоммитил сообщение).
33 33  Хоть и вероятность такого события в целом крайне мала. (зависит от системы)
39 +)))
40 +| |(((
41 +Замечание: на текущий момент отношу проблему к [[Dual write problem>>doc:Архитектура и модели.Группа\. Распределенные системы.Распределенные системы\. Консистентность.Dual write problem.WebHome]].
42 +По хорошему у каждого запроса или хотя бы сообщения должен быть уникальный ключ. Использую его, транзакцию, таблицу с уникальным индексом можно добиться гарантии, что сообщение будет обработано только единожды.
34 34  
44 +Возможен вариант, когда сообщение просто записывается в БД в статусе ожидает обработку. И фоновый обработчик разбирает таблицу и обрабатывает необходимые строки.
45 +)))
46 +| |
35 35  
36 36  
37 37  
38 38  
51 +