Перейти к содержимому
Редактировал(а) Alexandr Fokin 2026/08/20 12:16
От версии 1.12
отредактировано Alexandr Fokin
на 2026/08/20 12:03
Изменить комментарий: К данной версии нет комментариев
К версии 1.7
отредактировано Alexandr Fokin
на 2026/08/18 15:19
Изменить комментарий: К данной версии нет комментариев

Сводка

Подробности

Свойства страницы
Содержимое
... ... @@ -29,7 +29,7 @@
29 29  * Все временные данные расположены в оперативной памяти.
30 30  Нет записи на диск. Их потеря не критична, она приведет к временной задержке, но система продолжит работу.
31 31  * При выборке из БД достаточно только чтения. Не требуется ни транзакция, ни блокировка, ни запись.
32 -* Минимальная задержка до начала выполнения (Если обработчик публикует сразу в Queue (наличие такой возможности)).
32 +* Максимально быстрое попадание в Executor (Если обработчик публикует сразу в Queue (наличие такой возможности)).
33 33  * Возможность реализации разделения по типам процессов (нода обрабатывает только определенные типы и конфигурацию можно менять в любой момент).
34 34  * Возможность разделения на Single и Range процессы и реализация различного потребления из очереди (когда мы хотим обработать в одной транзакции 1 или N процессов).
35 35  )))
... ... @@ -40,65 +40,10 @@
40 40  * Когда в очередь поступает сообщение, то все ноды могут пытаться его потребить (нагрузка на сеть) (но это вроде самое безболезненное из возможных).
41 41  Системы с резервированием сообщений требуют подтверждения и имеют timeout, а это создает больше проблем и противоречий.
42 42  )))
43 +|(% style="width:93px" %)Некоторые моменты|(% style="width:1151px" %)(((
44 +* Решение на основе БД позволяет делать делать разделение по типам. Но это может требовать блокировок или записи резервирования (нагрузка на диск).
45 +* Решения на основе брокеров сообщений не очень подходят для распределения по типам. Время обработки сообщения у consumer брокера не должно быть большим (У Redis нет такой проблемы).
43 43  )))
44 -|(% style="width:157px" %)Резервирование на основе БД|(% style="width:1277px" %)(((
45 -|(% style="width:29px" %) |(% style="width:1272px" %)(((
46 -|Плюсы|(((
47 -* Гибкая конфигурация распределения задач по типам и нодам обработки.
48 -* Сравнительно просто. Не требует развертывания других типов хранилищ или брокеров сообщений.
49 -* Наличие полной транзакционности.
50 50  )))
51 -|Минусы|(((
52 -* Не самая малая задержка до начала выполнения.
53 -* Не самый эффективный вариант.
54 -)))
55 -)))
56 -|(% style="width:29px" %)1|(% style="width:1272px" %)(((
57 -|(% style="width:67px" %) |(% style="width:1187px" %)Одна транзакция с блокировкой.
58 -|(% style="width:67px" %)Плюсы|(% style="width:1187px" %)(((
59 -* Нет записи на диск.
60 -Но используется память БД для хранения блокировок.
61 -)))
62 -|(% style="width:67px" %)Минусы|(% style="width:1187px" %)(((
63 -* Не подходит под все кейсы.
64 -** Если мы хотим запустить задачи параллельно:
65 -Нужно использовать AdvisoryLock (а не блокировку БД) (только Postgres), иначе транзакция блокировки не сможет записать строку.
66 -Необходимо удерживать select транзакцию и AdvisoryLock на протяжении всего времени обработки батча (возможно долгая транзакция на чтение).
67 -* Не использует индекс, необходимо проверять блокировку по все строкам.
68 -)))
69 -)))
70 -|(% style="width:29px" %)2|(% style="width:1272px" %)(((
71 -|(% style="width:68px" %) |(% style="width:1185px" %)Поле ReserveDate.
72 -|(% style="width:68px" %)Плюсы|(% style="width:1185px" %)(((
73 -* При выборе задач на обработку используется индекс (эффективно).
74 -)))
75 -|(% style="width:68px" %)Минусы|(% style="width:1185px" %)(((
76 -* Нагрузка - запись на диск для выставления пометки резервирования.
77 -)))
78 -)))
79 -|(% style="width:29px" %)3|(% style="width:1272px" %)(((
80 -|(% style="width:75px" %) |(% style="width:1179px" %)InMemory (возможно unlogged) таблица в реляционной БД.
81 -|(% style="width:75px" %)Плюсы|(% style="width:1179px" %)(((
82 -* Запись о резервирование не нагружает диск.
83 -)))
84 -|(% style="width:75px" %)Минусы|(% style="width:1179px" %)(((
85 -* Необходим join с основной таблицей.
86 -* Функция InMemory таблиц не является стандартной, не везде поддерживается.
87 -)))
88 -)))
89 -)))
90 -|(% style="width:157px" %)Очередь распределения на основе брокера сообщений.|(% style="width:1277px" %)(((
91 -|(% style="width:78px" %)Минусы|(% style="width:1222px" %)(((
92 -* Переподключения и накладные расходы.
93 -* Ограниченное время на обработку сообщения (timeout). Может не подходить для долгой обработки.
94 -* Нет возможности гибко распределять потребление задач по типам (можно делать в Redis) (гибкая конфигурация нод и обрабатываемых ими типов процессов).
95 -* (Менее критично) Отсутствие резервирования, дублирования в очереди, нет гарантий уникальности (у Redis такая возможность есть).
96 -Или резервирование в БД (лишняя нагрузка на запись).
97 -* Распределение нагрузки. Kafka. Параллелизм только на уровне набора партиций. При перегрузке партиции необходимость увеличение количетсва.
98 -)))
99 -|(% style="width:78px" %)Плюсы|(% style="width:1222px" %)(((
100 -* (Не точно) Предположительно производительность выше чем у Redis при обработке мелких задач. Но обработка это все равное транзакция БД (не быстрее нее).
101 -)))
102 -)))
103 103  
104 104