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

Сводка

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

Подробности

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

Содержимое

...	...	@@ -6,16 +6,12 @@
6	6	|(% style="width:105px" %) |(% style="width:1138px" %)
7	7	)))
8	8	|(% style="width:157px" %)Очередь и резервирование на основе [[Redis>>doc:Разработка.Базы данных.NoSQL.Ключ-значение структура.Redis.WebHome]]|(% style="width:1277px" %)(((
9		-|(% style="width:93px" %)Ветка|(% style="width:1151px" %)(((
10		-* --feature/redis_typed_process_queue--
11		-* Решение на основе Redis выделено как основное и включено в master ветку (как наилучшее по производительности, нагрузке, задержкам).
12		-* Решение, допускающие запуск без Redis помещено в ветку master2.
13		-)))
	9	+|(% style="width:93px" %)Ветка|(% style="width:1151px" %)feature/redis_typed_process_queue
14	14	|(% style="width:93px" %)Топология|(% style="width:1151px" %)DbSelector -> (Queue with reserve) -> Executor.
15	15	ExecutorRunner -> (Queue with reserve) -> Executor.
16	16	|(% style="width:93px" %)Компоненты|(% style="width:1151px" %)(((
17	17	|(% style="width:369px" %)В качестве очереди выступает один или группа SortedSet и PubSub channel.|(% style="width:759px" %)(((
18		-* SortedSet - позволяет хранить заявки на обработку (без дублей) и имеет упорядоченность (можно указать критерий, например приоритет / дата создания/ дата последней обработки).
	14	+* SortedSet - позволяет хранить заявки на обработку (без дублей) и имеет упорядоченность (можно указать критерий, например приоритет или дата создания).
19	19	Использование нескольких SortedSet позволяет выполнить разделение по типу / приоритету процесса, чтобы ноды Executor могли отбирать только указанные для них типы задач.
20	20	* PubSub channel - используется для оповещения Executor о том, что в определенную очередь поступило сообщение. Executor может попытаться его считать, при наличии у него свободных слотов на обработку (параллелизм).
21	21	)))
...	...	@@ -29,76 +29,14 @@
29	29	* Все временные данные расположены в оперативной памяти.
30	30	Нет записи на диск. Их потеря не критична, она приведет к временной задержке, но система продолжит работу.
31	31	* При выборке из БД достаточно только чтения. Не требуется ни транзакция, ни блокировка, ни запись.
32		-* Минимальная задержка до начала выполнения (Если обработчик публикует сразу в Queue (наличие такой возможности)).
33		-* Возможность реализации разделения по типам процессов (нода обрабатывает только определенные типы и конфигурацию можно менять в любой момент).
	28	+* Максимально быстрое попадание в Executor (Если обработчик публикует сразу в Queue (наличие такой возможности)).
	29	+* Возможность реализации разделения по типам процессов (нода обрабатывает только определенные типы).
34	34	* Возможность разделения на Single и Range процессы и реализация различного потребления из очереди (когда мы хотим обработать в одной транзакции 1 или N процессов).
35	35	)))
36	36	|(% style="width:93px" %)Минусы|(% style="width:1151px" %)(((
37	37	* Для наибольшей производительности необходимо публиковать сообщения в очередь сразу (иначе будет ожидания цикла срабатывания DbSelector).
38	38	* Необходимость контроля потребляемой оперативной памяти.
39		-* DbSelector при проверке резервирования нагружает сеть (периодический запрос) (но это вроде самое безболезненное из возможных + регулируется timeout).
40		-* Когда в очередь поступает сообщение, то все ноды могут пытаться его потребить (нагрузка на сеть) (но это вроде самое безболезненное из возможных).
41		-Системы с резервированием сообщений требуют подтверждения и имеют timeout, а это создает больше проблем и противоречий.
42	42	)))
43	43	)))
44		-|(% style="width:157px" %)Резервирование на основе БД|(% style="width:1277px" %)(((
45		-|(% style="width:29px" %) |(% style="width:1272px" %)(((
46		-|Плюсы|(((
47		-* Гибкая конфигурация распределения задач по типам и нодам обработки.
48		-* Сравнительно просто. Не требует развертывания других типов хранилищ или брокеров сообщений.
49		-* Наличие полной транзакционности.
50		-)))
51		-|Минусы|(((
52		-* Не самая малая задержка до начала выполнения.
53		-* Не самый эффективный вариант.
54		-)))
55		-)))
56		-|(% style="width:29px" %)1|(% style="width:1272px" %)(((
57		-|(% style="width:67px" %) |(% style="width:1187px" %)Одна транзакция с блокировкой.
58		-|(% style="width:67px" %)Плюсы|(% style="width:1187px" %)(((
59		-* Нет записи на диск.
60		-Но используется память БД для хранения блокировок.
61		-)))
62		-|(% style="width:67px" %)Минусы|(% style="width:1187px" %)(((
63		-* Не подходит под все кейсы.
64		-** Если мы хотим запустить задачи параллельно:
65		-Нужно использовать AdvisoryLock (а не блокировку БД) (только Postgres), иначе транзакция блокировки не сможет записать строку.
66		-Необходимо удерживать select транзакцию и AdvisoryLock на протяжении всего времени обработки батча (возможно долгая транзакция на чтение).
67		-* Не использует индекс, необходимо проверять блокировку по все строкам.
68		-)))
69		-)))
70		-|(% style="width:29px" %)2|(% style="width:1272px" %)(((
71		-|(% style="width:68px" %) |(% style="width:1185px" %)Поле ReserveDate.
72		-|(% style="width:68px" %)Плюсы|(% style="width:1185px" %)(((
73		-* При выборе задач на обработку используется индекс (эффективно).
74		-)))
75		-|(% style="width:68px" %)Минусы|(% style="width:1185px" %)(((
76		-* Нагрузка - запись на диск для выставления пометки резервирования.
77		-)))
78		-)))
79		-|(% style="width:29px" %)3|(% style="width:1272px" %)(((
80		-|(% style="width:75px" %) |(% style="width:1179px" %)InMemory (возможно unlogged) таблица в реляционной БД.
81		-|(% style="width:75px" %)Плюсы|(% style="width:1179px" %)(((
82		-* Запись о резервирование не нагружает диск.
83		-)))
84		-|(% style="width:75px" %)Минусы|(% style="width:1179px" %)(((
85		-* Необходим join с основной таблицей.
86		-* Функция InMemory таблиц не является стандартной, не везде поддерживается.
87		-)))
88		-)))
89		-)))
90		-|(% style="width:157px" %)Очередь распределения на основе брокера сообщений.|(% style="width:1277px" %)(((
91		-|(% style="width:78px" %)Минусы|(% style="width:1222px" %)(((
92		-* Переподключения и накладные расходы.
93		-* Ограниченное время на обработку сообщения (timeout). Может не подходить для долгой обработки.
94		-* Нет возможности гибко распределять потребление задач по типам (можно делать в Redis) (гибкая конфигурация нод и обрабатываемых ими типов процессов).
95		-* (Менее критично) Отсутствие резервирования, дублирования в очереди, нет гарантий уникальности (у Redis такая возможность есть).
96		-Или резервирование в БД (лишняя нагрузка на запись).
97		-* Распределение нагрузки. Kafka. Параллелизм только на уровне набора партиций. При перегрузке партиции необходимость увеличение количетсва.
98		-)))
99		-|(% style="width:78px" %)Плюсы|(% style="width:1222px" %)(((
100		-* (Не точно) Предположительно производительность выше чем у Redis при обработке мелких задач. Но обработка это все равное транзакция БД (не быстрее нее).
101		-)))
102		-)))
103	103
104	104