Перейти к содержимому
Редактировал(а) Alexandr Fokin 2026/08/20 12:16
От версии 1.2
отредактировано Alexandr Fokin
на 2026/08/02 15:36
Изменить комментарий: К данной версии нет комментариев
К версии 1.4
отредактировано Alexandr Fokin
на 2026/08/02 15:47
Изменить комментарий: К данной версии нет комментариев

Сводка

Подробности

Свойства страницы
Содержимое
... ... @@ -26,11 +26,20 @@
26 26  Нет записи на диск. Их потеря не критична, она приведет к временной задержке, но система продолжит работу.
27 27  * При выборке из БД достаточно только чтения. Не требуется ни транзакция, ни блокировка, ни запись.
28 28  * Максимально быстрое попадание в Executor (Если обработчик публикует сразу в Queue (наличие такой возможности)).
29 +* Возможность реализации разделения по типам процессов (нода обрабатывает только определенные типы).
30 +* Возможность разделения на Single и Range процессы и реализация различного потребления из очереди (когда мы хотим обработать в одной транзакции 1 или N процессов).
29 29  )))
30 30  |(% style="width:93px" %)Минусы|(% style="width:1151px" %)(((
31 -* Для наибольшей производительности необходимо публиковать сообщения в очередь (иначе будет ожидания цикла срабатывания DbSelector).
33 +* Для наибольшей производительности необходимо публиковать сообщения в очередь сразу (иначе будет ожидания цикла срабатывания DbSelector).
32 32  * Необходимость контроля потребляемой оперативной памяти.
35 +* DbSelector при проверке резервирования нагружает сеть (периодический запрос) (но это вроде самое безболезненное из возможных + регулируется timeout).
36 +* Когда в очередь поступает сообщение, то все ноды могут пытаться его потребить (нагрузка на сеть) (но это вроде самое безболезненное из возможных).
37 +Системы с резервированием сообщений требуют подтверждения и имеют timeout, а это создает больше проблем и противоречий.
33 33  )))
39 +|(% style="width:93px" %)Некоторые моменты|(% style="width:1151px" %)(((
40 +* Решение на основе БД позволяет делать делать разделение по типам. Но это может требовать блокировок или записи резервирования (нагрузка на диск).
41 +* Решения на основе брокеров сообщений не очень подходят для распределения по типам. Время обработки сообщения у consumer брокера не должно быть большим (У Redis нет такой проблемы).
34 34  )))
43 +)))
35 35  
36 36