| | | | | | Распределение | | | Резервирование | Резервирование помогает отслеживать факт того, что экземпляр назначен на выполнение или выполняется (чтобы не пытаться запустить его на другом исполнителе).
Резервирование накладывается с timeout. | | | |
|
| Очередь и резервирование на основе Redis | | Ветка | feature/redis_typed_process_queue- Решение на основе Redis выделено как основное и включено в master ветку (как наилучшее по производительности, нагрузке, задержкам).
- Решение, допускающие запуск без Redis помещено в ветку master2.
| | Топология | DbSelector -> (Queue with reserve) -> Executor.
ExecutorRunner -> (Queue with reserve) -> Executor. | | Компоненты | | В качестве очереди выступает один или группа SortedSet и PubSub channel. | - SortedSet - позволяет хранить заявки на обработку (без дублей) и имеет упорядоченность (можно указать критерий, например приоритет / дата создания/ дата последней обработки).
Использование нескольких SortedSet позволяет выполнить разделение по типу / приоритету процесса, чтобы ноды Executor могли отбирать только указанные для них типы задач. - PubSub channel - используется для оповещения Executor о том, что в определенную очередь поступило сообщение. Executor может попытаться его считать, при наличии у него свободных слотов на обработку (параллелизм).
| | В качестве системы резервирования используется HashSet. | Позволяет гарантировать уникальность (при резервировании), а также позволяет задействовать ExperationTimeout (автоматическое снятие резервирования, если вдруг нода упада и не смогла снять сама). Используется для обработки ситуации, когда задача была взята из очереди в обработку и обрабатывается (в этот промежуток нет смысла помещать в очередь повторно). В конце обработки (при нормальном завершение) резервирование снимается или при падении сработает ExperationTimeout. |
| | Плюсы | - Все временные данные расположены в оперативной памяти.
Нет записи на диск. Их потеря не критична, она приведет к временной задержке, но система продолжит работу. - При выборке из БД достаточно только чтения. Не требуется ни транзакция, ни блокировка, ни запись.
- Минимальная задержка до начала выполнения (Если обработчик публикует сразу в Queue (наличие такой возможности)).
- Возможность реализации разделения по типам процессов (нода обрабатывает только определенные типы и конфигурацию можно менять в любой момент).
- Возможность разделения на Single и Range процессы и реализация различного потребления из очереди (когда мы хотим обработать в одной транзакции 1 или N процессов).
| | Минусы | - Для наибольшей производительности необходимо публиковать сообщения в очередь сразу (иначе будет ожидания цикла срабатывания DbSelector).
- Необходимость контроля потребляемой оперативной памяти.
- DbSelector при проверке резервирования нагружает сеть (периодический запрос) (но это вроде самое безболезненное из возможных + регулируется timeout).
- Когда в очередь поступает сообщение, то все ноды могут пытаться его потребить (нагрузка на сеть) (но это вроде самое безболезненное из возможных).
Системы с резервированием сообщений требуют подтверждения и имеют timeout, а это создает больше проблем и противоречий.
|
|
| Резервирование на основе БД | | | | Плюсы | - Гибкая конфигурация распределения задач по типам и нодам обработки.
- Сравнительно просто. Не требует развертывания других типов хранилищ или брокеров сообщений.
| | Минусы | - Не самая малая задержка до начала выполнения.
- Не самый эффективный вариант.
|
| | 1 | | | Одна транзакция с блокировкой. | | Плюсы | - Нет записи на диск.
Но используется память БД для хранения блокировок.
| | Минусы | - Не подходит под все кейсы.
- Если мы хотим запустить задачи параллельно:
Нужно использовать AdvisoryLock (а не блокировку БД) (только Postgres), иначе транзакция блокировки не сможет записать строку.
Необходимо удерживать select транзакцию и AdvisoryLock на протяжении всего времени обработки батча (возможно долгая транзакция на чтение).
- Не использует индекс, необходимо проверять блокировку по все строкам.
|
| | 2 | | | Поле ReserveDate. | | Плюсы | - При выборе задач на обработку используется индекс (эффективно).
| | Минусы | - Нагрузка - запись на диск для выставления пометки резервирования.
|
| | 3 | | | InMemory (возможно unlogged) таблица в реляционной БД. | | Плюсы | - Запись о резервирование не нагружает диск.
- Наличие полной транзакционности.
| | Минусы | - Необходим join с основной таблицей.
- Функция InMemory таблиц не является стандартной, не везде поддерживается.
|
|
|
| Очередь распределения на основе брокера сообщений. | | Минусы | - Переподключения и накладные расходы.
- Ограниченное время на обработку сообщения (timeout). Может не подходить для долгой обработки.
- Нет возможности гибко распределять потребление задач по типам (можно делать в Redis) (гибкая конфигурация нод и обрабатываемых ими типов процессов).
- (Менее критично) Отсутствие резервирования, дублирования в очереди, нет гарантий уникальности (у Redis такая возможность есть).
Или резервирование в БД (лишняя нагрузка на запись). - Распределение нагрузки. Kafka. Параллелизм только на уровне набора партиций. При перегрузке партиции необходимость увеличение количетсва.
| | Плюсы | - (Не точно) Предположительно производительность выше чем у Redis при обработке мелких задач. Но обработка это все равное транзакция БД (не быстрее нее).
|
|
