Перейти к содержимому
Редактировал(а) Alexandr Fokin 2026/08/26 19:07
От версии 1.17
отредактировано Alexandr Fokin
на 2026/08/26 19:07
Изменить комментарий: К данной версии нет комментариев
К версии 1.1
отредактировано Alexandr Fokin
на 2026/07/27 02:15
Изменить комментарий: К данной версии нет комментариев

Сводка

Подробности

Свойства страницы
Содержимое
... ... @@ -1,53 +1,14 @@
1 1  |(% style="width:40px" %) |(% style="width:1394px" %)[[Примеры>>doc:Проекты и репозитории.Библиотеки.Движок cccc1808\. ProcessEngine.Тема\. Сигналы и триггеры.Примеры.WebHome]]
2 2  |(% style="width:40px" %) |(% style="width:1394px" %)(((
3 -|(% style="width:127px" %)Технологические решения|(% style="width:1260px" %)(((
4 -|(((
5 -Полная целостность.
6 -
7 -TriggerEvent sql TransactionalInbox
8 -+ TriggerEvent sql TransactionalOutbox
9 -+ sql store.
10 -)))|Полная ACID целостность (отсутствие проблем), но меньшая пропускная способность из-за ограничений производительности sql БД.
11 -|Меньшие гарантии|(((
12 -Использование меньших гарантий требует дополнительных проверок:
13 -
14 -* Дополнительные проверки условия -> обнаружения инцидента ложного сигнала.
15 -В случае обнаружения инцидента:
16 -** Попытка пересчитать временный счетчик (количество необработанных значений не менее N).
17 -** Реагирование на каждый поступающий сигнал (возможно с задержкой после срабатывания).
18 -* Страхующая проверка завязанная на таймер (периодическая) -> обнаружения инцидента потери сигнала.
19 -
20 -Основывается на том, что вероятность исключительных ситуаций не велика.
21 -
22 -[[Надежность триггеров>>doc:Проекты и репозитории.Библиотеки.Движок cccc1808\. ProcessEngine.Тема\. Сигналы и триггеры.Надежность триггеров.WebHome]]
3 +| |
4 +|Выводы|(((
5 +* Более производительные решения возможны только с использованием InMemory ([[NoSQL>>doc:Разработка.Базы данных.NoSQL.WebHome]]) хранилища. Что ведет к понижению надежности и отсутсвию полного [[ACID>>doc:Разработка.Базы данных.Концепции.ACID.WebHome]].
6 +* Решение на основа только реляционной БД ([[SQL>>doc:Разработка.Базы данных.SQL.WebHome]]) при высокой производительности не возможно. Возможно смещение в сторону периодической перепроверки по таймеру (увеличение задержки между завершением работы и реакций на это).
23 23  )))
24 -)))| |
25 -|(% style="width:127px" %)Проблемы и риски при использовании меньших гарантий.|(% style="width:1260px" %)(((
26 -|Тип|(% style="width:312px" %)Причина|(% style="width:703px" %)Пример
27 -|Потеря данных в хранилище.|(% style="width:312px" %)Падение ненадежного (например InMemory) хранилища.|(% style="width:703px" %)Потеря счетчика сигналов.
28 -|Потеря сигнала.|(% style="width:312px" %)Отправка TriggerEvent без sql TransactionalOutbox.|(% style="width:703px" %)(((
29 -* TriggerEvent не был отправлен (no gracefull shutdown)
8 +| |
30 30  
31 --> Счетчик не был изменен.
32 --> Зависание обработки.
10 +
33 33  )))
34 -|Ложный или дублирующий сигнал.|(% style="width:312px" %)Обработка TriggerEvent без sql TransactionalInbox.|(% style="width:703px" %)(((
35 -TriggerEvent был обработан более одного раза ([[Гарантии доставки>>doc:Разработка.Брокеры сообщений.Apache Kafka.Kafka\. Механизмы.Гарантии доставки.WebHome]]).
36 -
37 -* Отвал и переподключение consumer. Транзакция БД закомичена, а сообщение брокера нет.
38 -* Дублирование сообщений на отправке.
39 -** Проблемы с сетью (доставка подтверждения отправки).
40 -** Падение сервиса после публикации сообщения (без фиксации).
41 -
42 --> Счетчик был уменьшен более чем на 1.
43 --> Ложное, преждевременное срабатывание триггера.
44 -)))
45 -)))| |
46 -|(% style="width:127px" %)Выводы|(% style="width:1260px" %)(((
47 -* Более производительные решения возможны только с использованием InMemory ([[NoSQL>>doc:Разработка.Базы данных.NoSQL.WebHome]]) хранилища. Что ведет к потере полной целостности и отсутствию полного [[ACID>>doc:Разработка.Базы данных.Концепции.ACID.WebHome]]. При этом корретная обработка возможна (хоть она и будет более долгой).
48 -* Решение на основа только реляционной БД ([[SQL>>doc:Разработка.Базы данных.SQL.WebHome]]) не может гарантировать такой же высокий уровень производительности. Возможно смещение в сторону периодической перепроверки по таймеру (увеличение задержки между завершением работы и реакций на это).
49 -)))| |
50 -)))
51 51  |(% style="width:40px" %) |(% style="width:1394px" %)
52 52  
53 53