Изменения документа Движок cccc1808. ProcessEngine
Редактировал(а) Alexandr Fokin 2026/04/27 13:28
От версии 27.11
отредактировано Alexandr Fokin
на 2026/04/11 00:30
на 2026/04/11 00:30
Изменить комментарий:
К данной версии нет комментариев
К версии 28.1
отредактировано Alexandr Fokin
на 2026/04/27 13:24
на 2026/04/27 13:24
Изменить комментарий:
Вложение перемещено в xwiki:Проекты и репозитории.Библиотеки.Движок cccc1808\. ProcessEngine.Примеры.WebHome.
Сводка
-
Свойства страницы (1 изменено, 0 добавлено, 0 удалено)
-
Вложения (0 изменено, 0 добавлено, 1 удалено)
Подробности
- Свойства страницы
-
- Содержимое
-
... ... @@ -1,11 +1,12 @@ 1 -|(% style="width:132px" %) Тегипоиска|(% style="width:1301px" %)(((2 -cccc1808. ProcessEngine, cccc1808.ProcessEngine 1 +|(% style="width:132px" %) |(% style="width:1301px" %)((( 2 +|Теги поиска|cccc1808. ProcessEngine, cccc1808.ProcessEngine, Process engine 3 3 Очередь задач, Система обработки процессов, Движок обработки процессов. 4 4 [[Процесс>>doc:Архитектура и модели.Модели.Процесс.WebHome]] 5 -))) 6 -|(% style="width:132px" %) |(% style="width:1301px" %)Универсальный движок для выполнения процессов и очередей задач, позволяющий комбинировать несколько подходов к обработке (см особенности). 7 -|(% style="width:132px" %) |(% style="width:1301px" %)Процесс является единицей исполнения. В реализации может содержать машину состояний. 5 +|Описание|Универсальный движок для выполнения процессов и очередей задач, позволяющий комбинировать несколько подходов к обработке (см особенности). 6 +|Термины|Процесс является единицей исполнения. В реализации может содержать машину состояний. 8 8 Система триггеров используется для таймеров и передачи сигналов для процессов (с оптимизацией нагрузки). 8 +|Репозиторий|[[https:~~/~~/github.com/cccc1808/cccc1808.ProcessEngine>>https://github.com/cccc1808/cccc1808.ProcessEngine]] 9 +))) 9 9 |(% style="width:132px" %)Разветывание|(% style="width:1301px" %)((( 10 10 |(% style="width:150px" %)База данных|(% style="width:1177px" %)((( 11 11 Для надежного хранения данных процессов и триггеров. ... ... @@ -15,16 +15,18 @@ 15 15 16 16 Для текущей реализации в качестве хранилище может выступать БД, поддерживающая: 17 17 18 -* Транзакции: транзакции. 19 -* Транзакции: savepoint. 19 +* Транзакции: 20 +** Транзакции. 21 +** Savepoint. 20 20 (если используются, можно обрабатывать каждый шаг отдельной транзакцией или весь процесс без savepoint изоляции ошибок между шагами). 21 -* Блокировка: updatelock. 22 -* Блокировка: updatelock skip locked. 23 +* [[Блокировки>>doc:Разработка.Базы данных.SQL.Механизмы.Транзакции и блокировки.WebHome]]: 24 +** updatelock. 25 +** updatelock skip locked. 23 23 (частично можно обойтись без него). 24 -* Блокировка:sharelock27 +** sharelock 25 25 (можно обойтись без него без сильного влияния) 26 -* Уровен ьизоляции: работает на read committed, то что нужно блокируется руками.27 -* Для некоторых кейсов желательно возможность выполнить upsert (insert on conflict).29 +* [[Уровни изоляции>>doc:Разработка.Базы данных.SQL.Механизмы.Транзакции и блокировки.Уровни изоляции | Isolation levels.WebHome]]: работает на read committed, то что нужно блокируется руками. 30 +* Для некоторых кейсов желательно возможность выполнить [[Upsert>>doc:Разработка.Базы данных.SQL.Сценарии и вопросы.Insert or update\. Upsert.WebHome]] (insert on conflict). 28 28 ))) 29 29 |(% style="width:150px" %)Брокер сообщений|(% style="width:1177px" %)((( 30 30 Используется для накопления и доставки TriggerEvent. ... ... @@ -35,8 +35,8 @@ 35 35 ))) 36 36 ))) 37 37 |(% style="width:132px" %)Особенности|(% style="width:1301px" %)((( 38 -|(% style="width:159px" %) Батчингпри выполнении.|(% style="width:1168px" %)(((39 -Возможность использовать и комбинировать разныетипы выполнениякак41 +|(% style="width:159px" %)Пакетные транзакции (батчинг).|(% style="width:1168px" %)((( 42 +Возможность использовать и комбинировать типы выполнения для разных типов процессов: 40 40 41 41 * (1 транзакция - 1 процесс), 42 42 * (1 транзакция - N процессов). ... ... @@ -60,6 +60,7 @@ 60 60 См. пример 2. 61 61 ))) 62 62 |(% style="width:159px" %)Перехват ошибок|(% style="width:1168px" %)Перехват и обработка ошибок, если процесс выкинул exception в движок. Реализацию простого retry с задержкой (создается триггер на следующую попытку). 66 +В случае пакетной транзакции движок не знает какой конкретно из процессов породил ошибку (если она не перехвачена вручную), то ошибка выставляется на все незавершенные процессы. 63 63 |(% style="width:159px" %)Параллельное выполнение|(% style="width:1168px" %)Допускается запуск нескольких раннеров (на разных нодах), работающих с одной таблицей процессов для распределения нагрузки между ними. 64 64 Допускается фильтрация типов процессов между нодами (чтобы нода выполняла только определенные типы процессов, в том числе по приоритету). 65 65 Доступно для раннеров процессов и триггеров. ... ... @@ -99,16 +99,7 @@ 99 99 ))) 100 100 |(% style="width:870px" %)[[image:Родительский дочерний процесс. Sequence.jpg]] 101 101 |(% style="width:870px" %)((( 102 -Возможен вариант №2, когда мы просто ставит timerTrigger на условно 1-5-10 минуту (насколько важна задержка) и перепроверяем условие завершения. Из минус, что родительский процесс узнает о завершении дочерних процессов с задержкой (хотя в задержке можно использовать функцию от количества необработанных дочерних процессов, но тогда нужно считать количество или хотя бы что оно не больше N). 103 - 104 -* Но тут будет join нагрузка на БД (если шаг проверки выполняется пакетно), иначе будет просто много одиночны запросов на чтение (условно раз в минуту). 105 -* Если дочерний процесс остановиться в ошибке, то родительский либо также продолжит крутиться в проверке (впустую доя разрешения проблемы), либо должен также пробросить ошибку в себя чтобы приостановиться. 106 -При это если родительский процесс приостановиться при обнаружении хотя бы одной ошибки в дочернем процессе, то стартануть нужно будет и родительский (он сам не узнает), а в случае с сигналом останавливать родительский процесс не нужно. 107 -В случае с решением 1, со страхующим триггером это можно обойти через фильтрующий индекс если мы начинаем идти сразу с таблицы процессов (т.е. процессы с ошибкой сразу будут игнорироваться). 108 -* Но все равно, именно данный движек может позволить настроить 2 процесса таким образом, что 1 процесс будет исполняться (1 процесс - 1 транзакция) в параллельном режиме (пока создаются множественные дочерние процессы), 2 процесс будет исполняться в пакетном режиме (N процессов - 1 транзакция) чтобы проверять выполнение условия завершения дочерних процессов через запрос (один пакетный). 109 - 110 -плюсы: меньше пишущей нагрузки (т.к. триггер со счетчиком будет делать условно одну запись на счетчик триггер в 5-20 секунд), а тут будет одна запись в 1-5 минуту на обновление таймера. 111 -минусы: больше читающей нагрузки с join (раз 1-5 минуту нужно будет выполнить join незавершенных процессов с дочерними). У решения 1 тоже есть такая нагрузка, но на страхующем триггер (условно раз 10-30 минут) и у решения 1 процессы упавшие в ошибку не будут генерировать нагрузку (если использовать фильтрующий индекс). 106 + 112 112 ))) 113 113 ))) 114 114 |(% style="width:32px" %)2|(% style="width:171px" %)Transaction outbox stream process.|(% style="width:1066px" %)[[image:TransactionOutbox. Sequence.jpg]]
- TransactionOutbox. Sequence.graphml
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -XWiki.cccc1808 - Размер
-
... ... @@ -1,1 +1,0 @@ 1 -33.6 KB - Содержимое