Комментарий

• Свойства страницы (3 изменено, 0 добавлено, 0 удалено)

Подробности

Свойства страницы

Название

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