Комментарий

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

Подробности

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

Содержимое

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