Изменения документа Примеры
Редактировал(а) Alexandr Fokin 2026/08/26 19:05
От версии 8.27
отредактировано Alexandr Fokin
на 2026/07/27 03:29
на 2026/07/27 03:29
Изменить комментарий:
К данной версии нет комментариев
К версии 6.1
отредактировано Alexandr Fokin
на 2026/04/27 13:26
на 2026/04/27 13:26
Изменить комментарий:
Удаление картинки %D0%A0%D0%BE%D0%B4%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D1%81%D0%BA%D0%B8%D0%B9%20%D0%B4%D0%BE%D1%87%D0%B5%D1%80%D0%BD%D0%B8%D0%B9%20%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81.%20Sequence.jpg
Сводка
-
Свойства страницы (2 изменено, 0 добавлено, 0 удалено)
-
Вложения (0 изменено, 1 добавлено, 0 удалено)
-
Объекты (0 изменено, 0 добавлено, 1 удалено)
Подробности
- Свойства страницы
-
- Родительский документ
-
... ... @@ -1,1 +1,1 @@ 1 -Проекты и репозитории.Библиотеки.Движок cccc1808\. ProcessEngine. Тема\. Сигналы и триггеры.WebHome1 +Проекты и репозитории.Библиотеки.Движок cccc1808\. ProcessEngine.WebHome - Содержимое
-
... ... @@ -1,9 +1,7 @@ 1 -|1|(% style="width:188px" %)1 родительский процесс и N дочерних процессов.|(% style="width:1268px" %)((( 2 -|В данном примере имеется в виду, что дочерние процессы могут выполняться параллельно другу и независимо друг от друга, но в конце должны оповестить родительский процесс о необходимости продолжения обработки. 3 -Если речь идет о каких-либо зависимостях порядка выполнения в дочерних процессах, то это может контролировать дочерний процесс (выделяя группу, которую сейчас можно запустить и ожидая окончания). 1 +|1|Родительский процесс, N дочерних процессов.|((( 4 4 |((( 5 - |(((6 - Вариант1:CounterTrigger.3 +В данном примере имеется в виду, что дочерние процессы могут выполняться параллельно другу и независимо друг от друга, но в конце должны оповестить родительский процесс о необходимости продолжения обработки. 4 +Если речь идет о каких-либо зависимостях порядка выполнения в дочерних процессах, то это может контролировать дочерний процесс (выделяя группу, которую сейчас можно запустить и ожидая окончания). 7 7 ))) 8 8 |((( 9 9 1. Родительский процесс создает триггер со счетчиком N, создает и запускает дочерние процессы, засыпает. ... ... @@ -19,77 +19,19 @@ 19 19 Для таких случаев создается страхующий триггер (1 общий на тип процесса). Этот триггер запускается периодически и проходится по всем ожидающим процессам, проверяя условие (в реализации можно использовать keyset пагинацию) (в реализации можно использовать join для проверки условия). 20 20 Этот триггер выполняется периодически с более крупной временной задержкой. В случае обнаружения потери TriggerEvent, он поднимет заклинивший родительский процесс и он будет обработан (но позже). Можно установить этому триггеру низкий приоритет. 21 21 ))) 22 -|[[image:Родительский дочерний процесс. Sequence.jpg]] 23 -))) 20 +| 24 24 |((( 25 -Вариант №2: 26 - 27 -Мы просто ставим TimerTrigger на условно 1-5-10 минут (насколько важна задержка) и перепроверяем условие завершения. 28 -В этом случае будет 29 - 30 -* Из минус: что родительский процесс узнает о завершении дочерних процессов с задержкой. 31 -Если дочерний процесс падает в ошибку, TimerTrigger все равно будет крутиться и создавать пустую нагрузку. 32 -* Из плюсов: будет меньше пишущей нагрузки на БД чем в варианте 1 (но больше читающей - на проверку) т.к. у нас не будет CounterTrigger, но будет периодический запрос на проверку завершения всех дочерних процессов (аналогично страхующему триггер). 33 -* [Расширенный]: Дочерние процессы в блоке wakeup condition проверяют наличие незавершенных процессов. 34 -** Если все процессы завершены или (незавершенных процессов мало и нет процессов с ошибкой), то можно опубликовать событие на TimerTrigger на сброс или установку минимальной задержки. 22 + 35 35 ))) 36 -|((( 37 -Вариант №3: 38 - 39 -Дочерние процессы выполняются через родительский (ограничение в рамках одной ноды). 40 -Точкой выполнения является родительский процесс, который внутри себя (параллельно или последовательно) выполняет дочерние процессы. 41 -За счет такого способа у нас также отсутствует конкуренция передачи сигнала в родительский процесс. 42 -Но мы ограничены выполнением дочерних процессов одной одной сервиса. 43 -Сложнее контролировать распределение нагрузки, если будет вложенный параллелизм. 44 -Также решает проблему, если дочерний процесс содержит ожидание (например асинхронный запрос-ответ), тут будет конкуренция сигнала от хендлера ответа к родительскому процессу. 45 45 ))) 46 -|((( 47 -Вариант №4: 48 - 49 -SimpleStreamTrigger + Timer (один из лучших вариантов). 50 - 51 -* Триггер проверяет условие завершения всех дочерних процессов (можно прикинуть количество незавершенных дочерних процессов). 52 -** Если все обработано, то пробуждает процесс и деактивируется. 53 -** Иначе: 54 -*** деактивируется (до поступления хотя бы одного сигнала), 55 -*** взводит признак стрима - процесс ожидает, 56 -*** взводит флаг новых сигналов на 0, 57 -*** выставляет задержку от оценки количества необработанных процессов (< N - малая задержка, иначе большая задержка). 58 -* [Расширенный]: Дочерние процессы в блоке wakeup condition проверяют наличие незавершенных процессов. 59 -** Если все процессы завершены или (незавершенных процессов мало и нет процессов с ошибкой), то можно опубликовать событие на SimpleStreamTrigger на сброс или установку минимальной задержки (в дополнение к сигналу). 60 -* Читающей нагрузки будет немного больше чем в варианте 2 (чтение триггера на поступлении сигнала), 61 -но пишущей нагрузки будет меньше чем в варианте 1 (запись - только на активации новым сигналом). 62 -* Если сигналов нет, то нет пустых срабатываний в отличие от варианта 2 (т.к. нет поступления сигнала от дочерних процессов). 63 -))) 64 -|((( 65 -|Вариант №5: Trigger + Счетчик в Redis. 66 -|InMemory счетчик, нагрузка на БД и конкуренция. 67 -Дочерний процесс уменьшает счетчик. И публикует событие только если счетчик достиг 0. 68 -|((( 69 -Проблема: изменение счетчика не привязано к основной транзакции БД. 70 - 71 -Возможно: 72 - 73 -1. До коммита транзакции уменьшаем счетчик и записываем id дочернего процесса в redis hashset. Если счетчик 0, то публикуем triggerEvent через TransactionalOutbox. 74 -(На старте транзакции проверить и удалить из HashSet и если удалили, то увеличить счетчик на 1 - значит была упавшая транзакция). 75 -1. После коммита транзакции удаляем id дочернего процесса из redis hashset. 76 -1. Trigger при получении события смотрит значение счетчика и HashSet. 77 -Если счетчик 0 и HashSet пустой, то скорее всего все корректно и триггер может активироваться. 78 -Иначе если HashSet не пустой, то можно попытаться проверить статус процесса (если он завершен, то можно удалить значение из HashSet). 79 -))) 80 -|Проблемы: Потеря счетчика целиком или искажения значения в случае падения Redis. 81 -))) 82 -))) 83 -|2|(% style="width:188px" %)Transaction outbox stream process.|(% style="width:1268px" %)[[image:TransactionOutbox. Sequence.jpg]] 84 -|3|(% style="width:188px" %)Stream trigger|(% style="width:1268px" %)((( 25 +|2|Transaction outbox stream process.| 26 +|3|Stream trigger|((( 85 85 | |((( 86 86 * Позволяет убрать лишние запросы пробуждения процесса (когда он и так запущен). 87 -* __Позволяет полностью убрать задержку после остановки процесса__(если есть новое сообщения, то он сразу же будет пробужден).29 +* Позволяет полностью убрать задержку после остановки процесса (если есть новое сообщения, то он сразу же будет пробужден). 88 88 За счет того, что триггер точно знает, что есть новые сообщения и процесс только что уснул. 89 89 * Вводит 2 типа события, 1 сигнал о новом сообщении (содержит offset значение), 2 - процесс идет спать (содержит offset значение). 90 90 * Вводит дополнительное состояние в триггер: максимальный offset сообщения, максимальный offset обработанного процессом сообщения, флаг состояния сна процесса. 91 -* В некоторых случаях позволяет не выполнять wakeup код в конце сессии обработки (если отключить wakeup, оставить только stream trigger) 92 -(блокировка и обновление wakeup entity, проверка wakeup условия), __улучшает перформанс такта работы__. 93 93 ))) 94 94 |Алгоритм триггера.|((( 95 95 * При получении события о засыпании процесса: ... ... @@ -105,40 +105,5 @@ 105 105 Если есть сообщения со смещением больше чем указал процесс, то делает гарантированное пробуждение процесса. 106 106 Когда поступает сигнал о новом сообщении (от отправителя сообщения), то обновляет данные о максимальном смещении и пробуждает процесс, если он спит 107 107 ))) 108 -| Заготовка|[[https:~~/~~/github.com/cccc1808/cccc1808.ProcessEngine/tree/cccc1808/feature/trigger_stream_trigger>>https://github.com/cccc1808/cccc1808.ProcessEngine/tree/cccc1808/feature/trigger_stream_trigger]]48 +| |TODO: 109 109 ))) 110 -|4|(% style="width:188px" %)Групповое действие|(% style="width:1268px" %)((( 111 -| |Действие, которое нужно применить к диапазону строк (сравнительно большому), независимо для каждой строки. 112 -Наличие у строк упорядоченного столбца (для выделения диапазонов). 113 -| |((( 114 -|(% style="width:888px" %)Родительские процесс определяет границы диапазона [min, max].|(% style="width:266px" %){{code language="none"}}select min(), max() 115 -where condition(){{/code}} 116 -|(% style="width:888px" %)Родительский процесс нарезает диапазон [min, max] на поддиапазоны. На каждый поддиапазон создается дочерний процесс.|(% style="width:266px" %) 117 -|(% style="width:888px" %)Каждый дочерний процесс обрабатывает свой поддиапазон строк (параллельно).|(% style="width:266px" %)Внутри поддиапазона может использоваться keyset пагинация. 118 -|(% style="width:888px" %)Родительский процесс ожидает завершения дочерних процессов (см. пример 1).|(% style="width:266px" %) 119 -))) 120 -))) 121 - 122 ----- 123 - 124 -==== Внутренние ссылки: ==== 125 - 126 -====== Дочерние страницы: ====== 127 - 128 -{{children/}} 129 - 130 -====== Обратные ссылки: ====== 131 - 132 -{{velocity}} 133 -#set ($links = $doc.getBacklinks()) 134 -#if ($links.size() > 0) 135 - #foreach ($docname in $links) 136 - #set ($rdoc = $xwiki.getDocument($docname).getTranslatedDocument()) 137 - * [[$escapetool.xml($rdoc.fullName)]] 138 - #end 139 -#else 140 - No back links for this page! 141 -#end 142 -{{/velocity}} 143 - 144 -----
- TransactionOutbox.%20Sequence.jpg
-
- Автор
-
... ... @@ -1,0 +1,1 @@ 1 +XWiki.cccc1808 - Размер
-
... ... @@ -1,0 +1,1 @@ 1 +247.1 KB - Содержимое
- XWiki.XWikiComments[0]
-
- Автор
-
... ... @@ -1,1 +1,0 @@ 1 -XWiki.cccc1808 - Комментарий
-
... ... @@ -1,4 +1,0 @@ 1 -Замечание: конфигурация задержки trigger consumer вычитывания и накопления батча trigger events. 2 - 3 -* Для примера 1 предпочтительная более большая задержка т.к. это уменьшит нагрузку на БД (агрегирует больше сигналов от дочерних процессов в одну операцию обновления). Throughput. 4 -* Для примера 3 в контексте inbox stream trigger, может быть предпочтительная более низкая задержка, чтобы не раздувать задержку от поступления сообщения до его обработки. Latency. - Дата
-
... ... @@ -1,1 +1,0 @@ 1 -2026-05-01 15:36:23.922