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

Сводка

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

Подробности

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

Содержимое

...	...	@@ -6,12 +6,16 @@
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" %)feature/redis_typed_process_queue
	9	+|(% style="width:93px" %)Ветка|(% style="width:1151px" %)(((
	10	+* --feature/redis_typed_process_queue--
	11	+* Решение на основе Redis выделено как основное и включено в master ветку (как наилучшее по производительности, нагрузке, задержкам).
	12	+* Решение, допускающие запуск без Redis помещено в ветку master2.
	13	+)))
10	10	|(% style="width:93px" %)Топология|(% style="width:1151px" %)DbSelector -> (Queue with reserve) -> Executor.
11	11	ExecutorRunner -> (Queue with reserve) -> Executor.
12	12	|(% style="width:93px" %)Компоненты|(% style="width:1151px" %)(((
13	13	|(% style="width:369px" %)В качестве очереди выступает один или группа SortedSet и PubSub channel.|(% style="width:759px" %)(((
14		-* SortedSet - позволяет хранить заявки на обработку (без дублей) и имеет упорядоченность (можно указать критерий, например приоритет или дата создания).
	18	+* SortedSet - позволяет хранить заявки на обработку (без дублей) и имеет упорядоченность (можно указать критерий, например приоритет / дата создания/ дата последней обработки).
15	15	Использование нескольких SortedSet позволяет выполнить разделение по типу / приоритету процесса, чтобы ноды Executor могли отбирать только указанные для них типы задач.
16	16	* PubSub channel - используется для оповещения Executor о том, что в определенную очередь поступило сообщение. Executor может попытаться его считать, при наличии у него свободных слотов на обработку (параллелизм).
17	17	)))
...	...	@@ -25,8 +25,8 @@
25	25	* Все временные данные расположены в оперативной памяти.
26	26	Нет записи на диск. Их потеря не критична, она приведет к временной задержке, но система продолжит работу.
27	27	* При выборке из БД достаточно только чтения. Не требуется ни транзакция, ни блокировка, ни запись.
28		-* Максимально быстрое попадание в Executor (Если обработчик публикует сразу в Queue (наличие такой возможности)).
29		-* Возможность реализации разделения по типам процессов (нода обрабатывает только определенные типы).
	32	+* Минимальная задержка до начала выполнения (Если обработчик публикует сразу в Queue (наличие такой возможности)).
	33	+* Возможность реализации разделения по типам процессов (нода обрабатывает только определенные типы и конфигурацию можно менять в любой момент).
30	30	* Возможность разделения на Single и Range процессы и реализация различного потребления из очереди (когда мы хотим обработать в одной транзакции 1 или N процессов).
31	31	)))
32	32	|(% style="width:93px" %)Минусы|(% style="width:1151px" %)(((
...	...	@@ -36,10 +36,62 @@
36	36	* Когда в очередь поступает сообщение, то все ноды могут пытаться его потребить (нагрузка на сеть) (но это вроде самое безболезненное из возможных).
37	37	Системы с резервированием сообщений требуют подтверждения и имеют timeout, а это создает больше проблем и противоречий.
38	38	)))
39		-|(% style="width:93px" %)Некоторые моменты|(% style="width:1151px" %)(((
40		-* Решение на основе БД позволяет делать делать разделение по типам. Но это может требовать блокировок или записи резервирования (нагрузка на диск).
41		-* Решения на основе брокеров сообщений не очень подходят для распределения по типам. Время обработки сообщения у consumer брокера не должно быть большим (У Redis нет такой проблемы).
42	42	)))
	44	+|(% style="width:157px" %)Резервирование на основе БД|(% style="width:1277px" %)(((
	45	+|(% style="width:29px" %) |(% style="width:1272px" %)(((
	46	+|Плюсы|(((
	47	+* Гибкая конфигурация распределения задач по типам и нодам обработки.
43	43	)))
	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	+)))
44	44
45	45