Исходный код вики Задачи. Распределение, резервирование, очередь.
Версия 1.10 от Alexandr Fokin на 2026/08/20 11:51
Последние авторы
| author | version | line-number | content |
|---|---|---|---|
| 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" %)((( | ||
| 10 | * --feature/redis_typed_process_queue-- | ||
| 11 | * Решение на основе Redis выделено как основное и включено в master ветку (как наилучшее по производительности, нагрузке, задержкам). | ||
| 12 | * Решение, допускающие запуск без Redis помещено в ветку master2. | ||
| 13 | ))) | ||
| 14 | |(% style="width:93px" %)Топология|(% style="width:1151px" %)DbSelector -> (Queue with reserve) -> Executor. | ||
| 15 | ExecutorRunner -> (Queue with reserve) -> Executor. | ||
| 16 | |(% style="width:93px" %)Компоненты|(% style="width:1151px" %)((( | ||
| 17 | |(% style="width:369px" %)В качестве очереди выступает один или группа SortedSet и PubSub channel.|(% style="width:759px" %)((( | ||
| 18 | * SortedSet - позволяет хранить заявки на обработку (без дублей) и имеет упорядоченность (можно указать критерий, например приоритет / дата создания/ дата последней обработки). | ||
| 19 | Использование нескольких SortedSet позволяет выполнить разделение по типу / приоритету процесса, чтобы ноды Executor могли отбирать только указанные для них типы задач. | ||
| 20 | * PubSub channel - используется для оповещения Executor о том, что в определенную очередь поступило сообщение. Executor может попытаться его считать, при наличии у него свободных слотов на обработку (параллелизм). | ||
| 21 | ))) | ||
| 22 | |(% style="width:369px" %)В качестве системы резервирования используется HashSet.|(% style="width:759px" %)((( | ||
| 23 | Позволяет гарантировать уникальность (при резервировании), а также позволяет задействовать ExperationTimeout (автоматическое снятие резервирования, если вдруг нода упада и не смогла снять сама). | ||
| 24 | |||
| 25 | Используется для обработки ситуации, когда задача была взята из очереди в обработку и обрабатывается (в этот промежуток нет смысла помещать в очередь повторно). В конце обработки (при нормальном завершение) резервирование снимается или при падении сработает ExperationTimeout. | ||
| 26 | ))) | ||
| 27 | ))) | ||
| 28 | |(% style="width:93px" %)Плюсы|(% style="width:1151px" %)((( | ||
| 29 | * Все временные данные расположены в оперативной памяти. | ||
| 30 | Нет записи на диск. Их потеря не критична, она приведет к временной задержке, но система продолжит работу. | ||
| 31 | * При выборке из БД достаточно только чтения. Не требуется ни транзакция, ни блокировка, ни запись. | ||
| 32 | * Минимальная задержка до начала выполнения (Если обработчик публикует сразу в Queue (наличие такой возможности)). | ||
| 33 | * Возможность реализации разделения по типам процессов (нода обрабатывает только определенные типы и конфигурацию можно менять в любой момент). | ||
| 34 | * Возможность разделения на Single и Range процессы и реализация различного потребления из очереди (когда мы хотим обработать в одной транзакции 1 или N процессов). | ||
| 35 | ))) | ||
| 36 | |(% style="width:93px" %)Минусы|(% style="width:1151px" %)((( | ||
| 37 | * Для наибольшей производительности необходимо публиковать сообщения в очередь сразу (иначе будет ожидания цикла срабатывания DbSelector). | ||
| 38 | * Необходимость контроля потребляемой оперативной памяти. | ||
| 39 | * DbSelector при проверке резервирования нагружает сеть (периодический запрос) (но это вроде самое безболезненное из возможных + регулируется timeout). | ||
| 40 | * Когда в очередь поступает сообщение, то все ноды могут пытаться его потребить (нагрузка на сеть) (но это вроде самое безболезненное из возможных). | ||
| 41 | Системы с резервированием сообщений требуют подтверждения и имеют timeout, а это создает больше проблем и противоречий. | ||
| 42 | ))) | ||
| 43 | ))) | ||
| 44 | |(% style="width:157px" %)Резервирование на основе БД|(% style="width:1277px" %)((( | ||
| 45 | |(% style="width:29px" %) |(% style="width:1272px" %)((( | ||
| 46 | |Плюсы|((( | ||
| 47 | * Гибкая конфигурация распределения задач по типам и нодам обработки. | ||
| 48 | ))) | ||
| 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 | ))) | ||
| 100 | |||
| 101 |