Изменения документа Движок cccc1808. ProcessEngine

Сводка

• Свойства страницы (1 изменено, 0 добавлено, 0 удалено)

Подробности

Свойства страницы

Содержимое

...	...	@@ -1,12 +1,11 @@
1		-|(% style="width:132px" %) |(% style="width:1301px" %)(((
2		-|Теги поиска|cccc1808. ProcessEngine, cccc1808.ProcessEngine, Process engine
	1	+|(% style="width:132px" %)Теги поиска|(% style="width:1301px" %)(((
	2	+cccc1808. ProcessEngine, cccc1808.ProcessEngine
3	3	Очередь задач, Система обработки процессов, Движок обработки процессов.
4	4	[[Процесс>>doc:Архитектура и модели.Модели.Процесс.WebHome]]
5		-|Описание|Универсальный движок для выполнения процессов и очередей задач, позволяющий комбинировать несколько подходов к обработке (см особенности).
6		-|Термины|Процесс является единицей исполнения. В реализации может содержать машину состояний.
7		-Система триггеров используется для таймеров и передачи сигналов для процессов (с оптимизацией нагрузки).
8		-|Репозиторий|[[https:~~/~~/github.com/cccc1808/cccc1808.ProcessEngine>>https://github.com/cccc1808/cccc1808.ProcessEngine]]
9	9	)))
	6	+|(% style="width:132px" %) |(% style="width:1301px" %)Универсальный движок для выполнения процессов и очередей задач, позволяющий комбинировать несколько подходов к обработке (см особенности).
	7	+|(% style="width:132px" %) |(% style="width:1301px" %)Процесс является единицей исполнения. В реализации может содержать машину состояний.
	8	+Система триггеров используется для таймеров и передачи сигналов для процессов (с оптимизацией нагрузки).
10	10	|(% style="width:132px" %)Разветывание|(% style="width:1301px" %)(((
11	11	|(% style="width:150px" %)База данных|(% style="width:1177px" %)(((
12	12	Для надежного хранения данных процессов и триггеров.
...	...	@@ -16,18 +16,16 @@
16	16
17	17	Для текущей реализации в качестве хранилище может выступать БД, поддерживающая:
18	18
19		-* Транзакции:
20		-** Транзакции.
21		-** Savepoint.
	18	+* Транзакции: транзакции.
	19	+* Транзакции: savepoint.
22	22	(если используются, можно обрабатывать каждый шаг отдельной транзакцией или весь процесс без savepoint изоляции ошибок между шагами).
23		-* [[Блокировки>>doc:Разработка.Базы данных.SQL.Механизмы.Транзакции и блокировки.WebHome]]:
24		-** updatelock.
25		-** updatelock skip locked.
	21	+* Блокировка: updatelock.
	22	+* Блокировка: updatelock skip locked.
26	26	(частично можно обойтись без него).
27		-** sharelock
	24	+* Блокировка: sharelock
28	28	(можно обойтись без него без сильного влияния)
29		-* [[Уровни изоляции>>doc:Разработка.Базы данных.SQL.Механизмы.Транзакции и блокировки.Уровни изоляции | Isolation levels.WebHome]]: работает на read committed, то что нужно блокируется руками.
30		-* Для некоторых кейсов желательно возможность выполнить [[Upsert>>doc:Разработка.Базы данных.SQL.Сценарии и вопросы.Insert or update\. Upsert.WebHome]] (insert on conflict).
	26	+* Уровень изоляции: работает на read committed, то что нужно блокируется руками.
	27	+* Для некоторых кейсов желательно возможность выполнить upsert (insert on conflict).
31	31	)))
32	32	|(% style="width:150px" %)Брокер сообщений|(% style="width:1177px" %)(((
33	33	Используется для накопления и доставки TriggerEvent.
...	...	@@ -38,8 +38,8 @@
38	38	)))
39	39	)))
40	40	|(% style="width:132px" %)Особенности|(% style="width:1301px" %)(((
41		-|(% style="width:159px" %)Пакетные транзакции (батчинг).|(% style="width:1168px" %)(((
42		-Возможность использовать и комбинировать типы выполнения для разных типов процессов:
	38	+|(% style="width:159px" %)Батчинг при выполнении.|(% style="width:1168px" %)(((
	39	+Возможность использовать и комбинировать разные типы выполнения как
43	43
44	44	* (1 транзакция - 1 процесс),
45	45	* (1 транзакция - N процессов).
...	...	@@ -63,7 +63,6 @@
63	63	См. пример 2.
64	64	)))
65	65	|(% style="width:159px" %)Перехват ошибок|(% style="width:1168px" %)Перехват и обработка ошибок, если процесс выкинул exception в движок. Реализацию простого retry с задержкой (создается триггер на следующую попытку).
66		-В случае пакетной транзакции движок не знает какой конкретно из процессов породил ошибку (если она не перехвачена вручную), то ошибка выставляется на все незавершенные процессы.
67	67	|(% style="width:159px" %)Параллельное выполнение|(% style="width:1168px" %)Допускается запуск нескольких раннеров (на разных нодах), работающих с одной таблицей процессов для распределения нагрузки между ними.
68	68	Допускается фильтрация типов процессов между нодами (чтобы нода выполняла только определенные типы процессов, в том числе по приоритету).
69	69	Доступно для раннеров процессов и триггеров.
...	...	@@ -103,7 +103,16 @@
103	103	)))
104	104	|(% style="width:870px" %)[[image:Родительский дочерний процесс. Sequence.jpg]]
105	105	|(% style="width:870px" %)(((
106		-
	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 процессы упавшие в ошибку не будут генерировать нагрузку (если использовать фильтрующий индекс).
107	107	)))
108	108	)))
109	109	|(% style="width:32px" %)2|(% style="width:171px" %)Transaction outbox stream process.|(% style="width:1066px" %)[[image:TransactionOutbox. Sequence.jpg]]