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

Сводка

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

Подробности

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

Содержимое

...	...	@@ -15,18 +15,31 @@
15	15	Использование нескольких SortedSet позволяет выполнить разделение по типу / приоритету процесса, чтобы ноды Executor могли отбирать только указанные для них типы задач.
16	16	* PubSub channel - используется для оповещения Executor о том, что в определенную очередь поступило сообщение. Executor может попытаться его считать, при наличии у него свободных слотов на обработку (параллелизм).
17	17	)))
18		-|(% style="width:369px" %)В качестве системы резервирования используется HashSet.|(% style="width:759px" %)Позволяет гарантировать уникальность (при резервировании), а также позволяет задействовать ExperationTimeout (автоматическое снятие резервирования, если вдруг нода упада и не смогла снять сама).
	18	+|(% style="width:369px" %)В качестве системы резервирования используется HashSet.|(% style="width:759px" %)(((
	19	+Позволяет гарантировать уникальность (при резервировании), а также позволяет задействовать ExperationTimeout (автоматическое снятие резервирования, если вдруг нода упада и не смогла снять сама).
	20	+
	21	+Используется для обработки ситуации, когда задача была взята из очереди в обработку и обрабатывается (в этот промежуток нет смысла помещать в очередь повторно). В конце обработки (при нормальном завершение) резервирование снимается или при падении сработает ExperationTimeout.
19	19	)))
	23	+)))
20	20	|(% style="width:93px" %)Плюсы|(% style="width:1151px" %)(((
21	21	* Все временные данные расположены в оперативной памяти.
22	22	Нет записи на диск. Их потеря не критична, она приведет к временной задержке, но система продолжит работу.
23	23	* При выборке из БД достаточно только чтения. Не требуется ни транзакция, ни блокировка, ни запись.
24	24	* Максимально быстрое попадание в Executor (Если обработчик публикует сразу в Queue (наличие такой возможности)).
	29	+* Возможность реализации разделения по типам процессов (нода обрабатывает только определенные типы).
	30	+* Возможность разделения на Single и Range процессы и реализация различного потребления из очереди (когда мы хотим обработать в одной транзакции 1 или N процессов).
25	25	)))
26	26	|(% style="width:93px" %)Минусы|(% style="width:1151px" %)(((
27		-* Для наибольшей производительности необходимо публиковать сообщения в очередь (иначе будет ожидания цикла срабатывания DbSelector).
	33	+* Для наибольшей производительности необходимо публиковать сообщения в очередь сразу (иначе будет ожидания цикла срабатывания DbSelector).
28	28	* Необходимость контроля потребляемой оперативной памяти.
	35	+* DbSelector при проверке резервирования нагружает сеть (периодический запрос) (но это вроде самое безболезненное из возможных + регулируется timeout).
	36	+* Когда в очередь поступает сообщение, то все ноды могут пытаться его потребить (нагрузка на сеть) (но это вроде самое безболезненное из возможных).
	37	+Системы с резервированием сообщений требуют подтверждения и имеют timeout, а это создает больше проблем и противоречий.
29	29	)))
	39	+|(% style="width:93px" %)Некоторые моменты|(% style="width:1151px" %)(((
	40	+* Решение на основе БД позволяет делать делать разделение по типам. Но это может требовать блокировок или записи резервирования (нагрузка на диск).
	41	+* Решения на основе брокеров сообщений не очень подходят для распределения по типам. Время обработки сообщения у consumer брокера не должно быть большим (У Redis нет такой проблемы).
30	30	)))
	43	+)))
31	31
32	32