Исходный код вики Задачи. Распределение, резервирование, очередь.
Версия 1.4 от Alexandr Fokin на 2026/08/02 15:47
Скрыть последних авторов
| author | version | line-number | content |
|---|---|---|---|
 |
1.1 | 1 | |(% style="width:157px" %) |(% style="width:1277px" %)((( |
| 2 | |(% style="width:105px" %) |(% style="width:1138px" %) | ||
| 3 | |(% style="width:105px" %)Распределение|(% style="width:1138px" %) | ||
| 4 | |(% style="width:105px" %)Резервирование|(% style="width:1138px" %)Резервирование помогает отслеживать факт того, что экземпляр назначен на выполнение или выполняется (чтобы не пытаться запустить его на другом исполнителе). | ||
| 5 | Резервирование накладывается с timeout. | ||
| 6 | |(% style="width:105px" %) |(% style="width:1138px" %) | ||
| 7 | ))) | ||
| 8 | |(% style="width:157px" %)Очередь и резервирование на основе [[Redis>>doc:Разработка.Базы данных.NoSQL.Ключ-значение структура.Redis.WebHome]]|(% style="width:1277px" %)((( | ||
| 9 | |(% style="width:93px" %)Ветка|(% style="width:1151px" %)feature/redis_typed_process_queue | ||
| 10 | |(% style="width:93px" %)Топология|(% style="width:1151px" %)DbSelector -> (Queue with reserve) -> Executor. | ||
| 11 | ExecutorRunner -> (Queue with reserve) -> Executor. | ||
| 12 | |(% style="width:93px" %)Компоненты|(% style="width:1151px" %)((( | ||
| 13 | |(% style="width:369px" %)В качестве очереди выступает один или группа SortedSet и PubSub channel.|(% style="width:759px" %)((( | ||
| 14 | * SortedSet - позволяет хранить заявки на обработку (без дублей) и имеет упорядоченность (можно указать критерий, например приоритет или дата создания). | ||
| 15 | Использование нескольких SortedSet позволяет выполнить разделение по типу / приоритету процесса, чтобы ноды Executor могли отбирать только указанные для них типы задач. | ||
| 16 | * PubSub channel - используется для оповещения Executor о том, что в определенную очередь поступило сообщение. Executor может попытаться его считать, при наличии у него свободных слотов на обработку (параллелизм). | ||
| 17 | ))) | ||
| |
1.2 | 18 | |(% style="width:369px" %)В качестве системы резервирования используется HashSet.|(% style="width:759px" %)((( |
| 19 | Позволяет гарантировать уникальность (при резервировании), а также позволяет задействовать ExperationTimeout (автоматическое снятие резервирования, если вдруг нода упада и не смогла снять сама). | ||
| 20 | |||
| 21 | Используется для обработки ситуации, когда задача была взята из очереди в обработку и обрабатывается (в этот промежуток нет смысла помещать в очередь повторно). В конце обработки (при нормальном завершение) резервирование снимается или при падении сработает ExperationTimeout. | ||
| |
1.1 | 22 | ))) |
| |
1.2 | 23 | ))) |
| |
1.1 | 24 | |(% style="width:93px" %)Плюсы|(% style="width:1151px" %)((( |
| 25 | * Все временные данные расположены в оперативной памяти. | ||
| 26 | Нет записи на диск. Их потеря не критична, она приведет к временной задержке, но система продолжит работу. | ||
| 27 | * При выборке из БД достаточно только чтения. Не требуется ни транзакция, ни блокировка, ни запись. | ||
| 28 | * Максимально быстрое попадание в Executor (Если обработчик публикует сразу в Queue (наличие такой возможности)). | ||
| |
1.3 | 29 | * Возможность реализации разделения по типам процессов (нода обрабатывает только определенные типы). |
| 30 | * Возможность разделения на Single и Range процессы и реализация различного потребления из очереди (когда мы хотим обработать в одной транзакции 1 или N процессов). | ||
| |
1.1 | 31 | ))) |
| 32 | |(% style="width:93px" %)Минусы|(% style="width:1151px" %)((( | ||
| |
1.3 | 33 | * Для наибольшей производительности необходимо публиковать сообщения в очередь сразу (иначе будет ожидания цикла срабатывания DbSelector). |
| |
1.1 | 34 | * Необходимость контроля потребляемой оперативной памяти. |
| |
1.4 | 35 | * DbSelector при проверке резервирования нагружает сеть (периодический запрос) (но это вроде самое безболезненное из возможных + регулируется timeout). |
| 36 | * Когда в очередь поступает сообщение, то все ноды могут пытаться его потребить (нагрузка на сеть) (но это вроде самое безболезненное из возможных). | ||
| 37 | Системы с резервированием сообщений требуют подтверждения и имеют timeout, а это создает больше проблем и противоречий. | ||
| |
1.1 | 38 | ))) |
| |
1.4 | 39 | |(% style="width:93px" %)Некоторые моменты|(% style="width:1151px" %)((( |
| 40 | * Решение на основе БД позволяет делать делать разделение по типам. Но это может требовать блокировок или записи резервирования (нагрузка на диск). | ||
| 41 | * Решения на основе брокеров сообщений не очень подходят для распределения по типам. Время обработки сообщения у consumer брокера не должно быть большим (У Redis нет такой проблемы). | ||
| |
1.1 | 42 | ))) |
| |
1.4 | 43 | ))) |
| |
1.1 | 44 | |
| 45 |