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

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

<
От версии < 5.5 >
отредактировано Alexandr Fokin
на 2024/02/02 10:14
К версии < 4.1 >
отредактировано Alexandr Fokin
на 2020/08/09 15:32
>
Изменить комментарий: К данной версии нет комментариев

Комментарий

Подробности

Свойства страницы
Родительский документ
... ... @@ -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,42 +10,30 @@
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) Возможно в нашей системе производитель сообщение, генерирует сообщени3) Возможно в нашей системе производитель сообщение, генерирует сообщен3) Возможно в нашей системе производитель сообщение, генерирует сообщение повторно через некоторой промежуток времени, если фиксирует, что предыдущее сообщение не было обработано.
29 -
30 -
31 -Более надежное, но более тяжелое решение:
32 -Использование потхода номер 2 совместно с каким-либо более продвинутым механизмом транзакций. Т.е в случае падения приложения транзакция не будет завершена успешно.
27 +2) Является ли потеря данных из одного из сообщений критичной для нашей системы
28 +3) Использование потхода номер 2 совместно с каким-либо более продвинутым механизмом транзакций. Т.е в случае падения приложения транзакция не будет завершена успешно.
33 33  Но есть риск если у нас выполняются 2 действия:
34 34  1) коммит транзакции в базе, 2) коммит сообщения. (или в порядке 2, 1)
35 35  В случае падения приложения между указанными шагами, мы все равно можем получить
36 -либо потерю сообщения (закоммитили сообщение, но не завершили транзакцию),
32 +либо потерю сообщения (закоммитили сообщение, но не завершили транзацию),
37 37  либо повторную обработку (завершили транзакцию, но не закоммитил сообщение).
38 38  Хоть и вероятность такого события в целом крайне мала. (зависит от системы)
39 -)))
40 -| |(((
41 -Замечание: на текущий момент отношу проблему к [[Dual write problem>>doc:Архитектура и модели.Группа\. Распределенные системы.Распределенные системы\. Консистентность.Dual write problem.WebHome]].
42 -По хорошему у каждого запроса или хотя бы сообщения должен быть уникальный ключ. Использую его, транзакцию, таблицу с уникальным индексом можно добиться гарантии, что сообщение будет обработано только единожды. Транзакция БД позволяет атомарно зафиксировать и изменения и факт обработки сообщения (по его ключу).
43 43  
44 -Отдельный вопрос: хотим ли мы использовать очередь для приостановки обработки в случае ошибок. Зачастую мы не хотим останавливать обработку из-за одной ошибки. В таком случае важно сохранить проблемное сообщение, но при этом сделать так чтобы обработчик продолжил обрабатывать последующие сообщения.
45 45  
46 -Возможен вариант, когда сообщение просто записывается в БД в статусе ожидает обработку. И фоновый обработчик разбирает таблицу и обрабатывает необходимые строки.
47 -)))
48 -| |
49 49  
50 50  
51 -
39 +