Изменения документа Задачи. Распределение, резервирование, очередь.
Редактировал(а) Alexandr Fokin 2026/08/20 12:16
От версии 1.8
отредактировано Alexandr Fokin
на 2026/08/20 11:47
на 2026/08/20 11:47
Изменить комментарий:
К данной версии нет комментариев
К версии 1.13
отредактировано Alexandr Fokin
на 2026/08/20 12:16
на 2026/08/20 12:16
Изменить комментарий:
К данной версии нет комментариев
Сводка
-
Свойства страницы (1 изменено, 0 добавлено, 0 удалено)
Подробности
- Свойства страницы
-
- Содержимое
-
... ... @@ -14,12 +14,12 @@ 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 -|(% style="width: 369px" %)В качестве очереди выступает один или группа SortedSet и PubSub channel.|(% style="width:759px" %)(((17 +|(% style="width:260px" %)В качестве очереди выступает один или группа SortedSet и PubSub channel.|(% style="width:921px" %)((( 18 18 * SortedSet - позволяет хранить заявки на обработку (без дублей) и имеет упорядоченность (можно указать критерий, например приоритет / дата создания/ дата последней обработки). 19 19 Использование нескольких SortedSet позволяет выполнить разделение по типу / приоритету процесса, чтобы ноды Executor могли отбирать только указанные для них типы задач. 20 20 * PubSub channel - используется для оповещения Executor о том, что в определенную очередь поступило сообщение. Executor может попытаться его считать, при наличии у него свободных слотов на обработку (параллелизм). 21 21 ))) 22 -|(% style="width: 369px" %)В качестве системы резервирования используется HashSet.|(% style="width:759px" %)(((22 +|(% style="width:260px" %)В качестве системы резервирования используется HashSet.|(% style="width:921px" %)((( 23 23 Позволяет гарантировать уникальность (при резервировании), а также позволяет задействовать ExperationTimeout (автоматическое снятие резервирования, если вдруг нода упада и не смогла снять сама). 24 24 25 25 Используется для обработки ситуации, когда задача была взята из очереди в обработку и обрабатывается (в этот промежуток нет смысла помещать в очередь повторно). В конце обработки (при нормальном завершение) резервирование снимается или при падении сработает ExperationTimeout. ... ... @@ -40,16 +40,22 @@ 40 40 * Когда в очередь поступает сообщение, то все ноды могут пытаться его потребить (нагрузка на сеть) (но это вроде самое безболезненное из возможных). 41 41 Системы с резервированием сообщений требуют подтверждения и имеют timeout, а это создает больше проблем и противоречий. 42 42 ))) 43 -|(% style="width:93px" %)Некоторые моменты|(% style="width:1151px" %)((( 44 -* Решение на основе БД позволяет делать делать разделение по типам. Но это может требовать блокировок или записи резервирования (нагрузка на диск). 45 -* Решения на основе брокеров сообщений не очень подходят для распределения по типам. Время обработки сообщения у consumer брокера не должно быть большим (У Redis нет такой проблемы). 46 46 ))) 44 +|(% style="width:157px" %)Резервирование на основе БД|(% style="width:1277px" %)((( 45 +|(% style="width:29px" %) |(% style="width:1272px" %)((( 46 +|(% style="width:71px" %)Плюсы|(% style="width:1183px" %)((( 47 +* Гибкая конфигурация распределения задач по типам и нодам обработки. 48 +* Сравнительно просто. Не требует развертывания других типов хранилищ или брокеров сообщений. 49 +* Наличие полной транзакционности. 47 47 ))) 48 -|(% style="width:157px" %)Резервирование в БД|(% style="width:1277px" %)((( 51 +|(% style="width:71px" %)Минусы|(% style="width:1183px" %)((( 52 +* Не самая малая задержка до начала выполнения. 53 +* Не самый эффективный вариант. 54 +))) 55 +))) 49 49 |(% style="width:29px" %)1|(% style="width:1272px" %)((( 50 50 |(% style="width:67px" %) |(% style="width:1187px" %)Одна транзакция с блокировкой. 51 51 |(% style="width:67px" %)Плюсы|(% style="width:1187px" %)((( 52 -* Сравнительно просто. 53 53 * Нет записи на диск. 54 54 Но используется память БД для хранения блокировок. 55 55 ))) ... ... @@ -74,7 +74,6 @@ 74 74 |(% style="width:75px" %) |(% style="width:1179px" %)InMemory (возможно unlogged) таблица в реляционной БД. 75 75 |(% style="width:75px" %)Плюсы|(% style="width:1179px" %)((( 76 76 * Запись о резервирование не нагружает диск. 77 -* Наличие полной транзакционности. 78 78 ))) 79 79 |(% style="width:75px" %)Минусы|(% style="width:1179px" %)((( 80 80 * Необходим join с основной таблицей.