| Очередь и резервирование на основе Redis | | Ветка | feature/redis_typed_process_queue | | Топология | DbSelector -> (Queue with reserve) -> Executor.
ExecutorRunner -> (Queue with reserve) -> Executor. | | Компоненты | | В качестве очереди выступает один или группа SortedSet и PubSub channel. | - SortedSet - позволяет хранить заявки на обработку (без дублей) и имеет упорядоченность (можно указать критерий, например приоритет или дата создания).
Использование нескольких SortedSet позволяет выполнить разделение по типу / приоритету процесса, чтобы ноды Executor могли отбирать только указанные для них типы задач. - PubSub channel - используется для оповещения Executor о том, что в определенную очередь поступило сообщение. Executor может попытаться его считать, при наличии у него свободных слотов на обработку (параллелизм).
| | В качестве системы резервирования используется HashSet. | Позволяет гарантировать уникальность (при резервировании), а также позволяет задействовать ExperationTimeout (автоматическое снятие резервирования, если вдруг нода упада и не смогла снять сама). Используется для обработки ситуации, когда задача была взята из очереди в обработку и обрабатывается (в этот промежуток нет смысла помещать в очередь повторно). В конце обработки (при нормальном завершение) резервирование снимается или при падении сработает ExperationTimeout. |
| | Плюсы | - Все временные данные расположены в оперативной памяти.
Нет записи на диск. Их потеря не критична, она приведет к временной задержке, но система продолжит работу. - При выборке из БД достаточно только чтения. Не требуется ни транзакция, ни блокировка, ни запись.
- Максимально быстрое попадание в Executor (Если обработчик публикует сразу в Queue (наличие такой возможности)).
- Возможность реализации разделения по типам процессов (нода обрабатывает только определенные типы).
- Возможность разделения на Single и Range процессы и реализация различного потребления из очереди (когда мы хотим обработать в одной транзакции 1 или N процессов).
| | Минусы | - Для наибольшей производительности необходимо публиковать сообщения в очередь сразу (иначе будет ожидания цикла срабатывания DbSelector).
- Необходимость контроля потребляемой оперативной памяти.
|
|
