Изменения документа Задачи. Распределение, резервирование, очередь.

Сводка

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

Подробности

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

Содержимое

...	...	@@ -29,8 +29,8 @@
29	29	* Все временные данные расположены в оперативной памяти.
30	30	Нет записи на диск. Их потеря не критична, она приведет к временной задержке, но система продолжит работу.
31	31	* При выборке из БД достаточно только чтения. Не требуется ни транзакция, ни блокировка, ни запись.
32		-* Минимальная задержка до начала выполнения (Если обработчик публикует сразу в Queue (наличие такой возможности)).
33		-* Возможность реализации разделения по типам процессов (нода обрабатывает только определенные типы и конфигурацию можно менять в любой момент).
	32	+* Максимально быстрое попадание в Executor (Если обработчик публикует сразу в Queue (наличие такой возможности)).
	33	+* Возможность реализации разделения по типам процессов (нода обрабатывает только определенные типы).
34	34	* Возможность разделения на Single и Range процессы и реализация различного потребления из очереди (когда мы хотим обработать в одной транзакции 1 или N процессов).
35	35	)))
36	36	|(% style="width:93px" %)Минусы|(% style="width:1151px" %)(((
...	...	@@ -40,62 +40,10 @@
40	40	* Когда в очередь поступает сообщение, то все ноды могут пытаться его потребить (нагрузка на сеть) (но это вроде самое безболезненное из возможных).
41	41	Системы с резервированием сообщений требуют подтверждения и имеют timeout, а это создает больше проблем и противоречий.
42	42	)))
	43	+|(% style="width:93px" %)Некоторые моменты|(% style="width:1151px" %)(((
	44	+* Решение на основе БД позволяет делать делать разделение по типам. Но это может требовать блокировок или записи резервирования (нагрузка на диск).
	45	+* Решения на основе брокеров сообщений не очень подходят для распределения по типам. Время обработки сообщения у consumer брокера не должно быть большим (У Redis нет такой проблемы).
43	43	)))
44		-|(% style="width:157px" %)Резервирование на основе БД|(% style="width:1277px" %)(((
45		-|(% style="width:29px" %) |(% style="width:1272px" %)(((
46		-|Плюсы|(((
47		-* Гибкая конфигурация распределения задач по типам и нодам обработки.
48	48	)))
49		-|Минусы|
50		-)))
51		-|(% style="width:29px" %)1|(% style="width:1272px" %)(((
52		-|(% style="width:67px" %) |(% style="width:1187px" %)Одна транзакция с блокировкой.
53		-|(% style="width:67px" %)Плюсы|(% style="width:1187px" %)(((
54		-* Сравнительно просто.
55		-* Нет записи на диск.
56		-Но используется память БД для хранения блокировок.
57		-)))
58		-|(% style="width:67px" %)Минусы|(% style="width:1187px" %)(((
59		-* Не подходит под все кейсы.
60		-** Если мы хотим запустить задачи параллельно:
61		-Нужно использовать AdvisoryLock (а не блокировку БД) (только Postgres), иначе транзакция блокировки не сможет записать строку.
62		-Необходимо удерживать select транзакцию и AdvisoryLock на протяжении всего времени обработки батча (возможно долгая транзакция на чтение).
63		-* Не использует индекс, необходимо проверять блокировку по все строкам.
64		-)))
65		-)))
66		-|(% style="width:29px" %)2|(% style="width:1272px" %)(((
67		-|(% style="width:68px" %) |(% style="width:1185px" %)Поле ReserveDate.
68		-|(% style="width:68px" %)Плюсы|(% style="width:1185px" %)(((
69		-* При выборе задач на обработку используется индекс (эффективно).
70		-)))
71		-|(% style="width:68px" %)Минусы|(% style="width:1185px" %)(((
72		-* Нагрузка - запись на диск для выставления пометки резервирования.
73		-)))
74		-)))
75		-|(% style="width:29px" %)3|(% style="width:1272px" %)(((
76		-|(% style="width:75px" %) |(% style="width:1179px" %)InMemory (возможно unlogged) таблица в реляционной БД.
77		-|(% style="width:75px" %)Плюсы|(% style="width:1179px" %)(((
78		-* Запись о резервирование не нагружает диск.
79		-* Наличие полной транзакционности.
80		-)))
81		-|(% style="width:75px" %)Минусы|(% style="width:1179px" %)(((
82		-* Необходим join с основной таблицей.
83		-* Функция InMemory таблиц не является стандартной, не везде поддерживается.
84		-)))
85		-)))
86		-)))
87		-|(% style="width:157px" %)Очередь распределения на основе брокера сообщений.|(% style="width:1277px" %)(((
88		-|(% style="width:78px" %)Минусы|(% style="width:1222px" %)(((
89		-* Переподключения и накладные расходы.
90		-* Ограниченное время на обработку сообщения (timeout). Может не подходить для долгой обработки.
91		-* Нет возможности гибко распределять потребление задач по типам (можно делать в Redis) (гибкая конфигурация нод и обрабатываемых ими типов процессов).
92		-* (Менее критично) Отсутствие резервирования, дублирования в очереди, нет гарантий уникальности (у Redis такая возможность есть).
93		-Или резервирование в БД (лишняя нагрузка на запись).
94		-* Распределение нагрузки. Kafka. Параллелизм только на уровне набора партиций. При перегрузке партиции необходимость увеличение количетсва.
95		-)))
96		-|(% style="width:78px" %)Плюсы|(% style="width:1222px" %)(((
97		-* (Не точно) Предположительно производительность выше чем у Redis при обработке мелких задач. Но обработка это все равное транзакция БД (не быстрее нее).
98		-)))
99		-)))
100	100
101	101