Изменения документа Примеры

Редактировал(а) Alexandr Fokin 2026/08/26 19:05

Управление
- Копировать
Действия
- Экспорт
- Предварительный просмотр
Просмотр

От 8.18 до 8.19

От версии 8.19

отредактировано Alexandr Fokin
на 2026/05/09 01:38

Изменить комментарий: К данной версии нет комментариев

К версии 8.52

отредактировано Alexandr Fokin
на 2026/08/26 19:05

Изменить комментарий: Удаленный объект

Необработанный
Обработанный

Сводка

Свойства страницы (2 изменено, 0 добавлено, 0 удалено)
Объекты (0 изменено, 0 добавлено, 1 удалено)
- XWiki.XWikiComments[0]

Подробности

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

Родительский документ

@@ -1,1 +1,1 @@
--Проекты и репозитории.Библиотеки.Движок cccc1808\. ProcessEngine.WebHome
++Проекты и репозитории.Библиотеки.Движок cccc1808\. ProcessEngine.Тема\. Сигналы и триггеры.WebHome

Содержимое

@@ -1,8 +1,13 @@
--|1|(% style="width:188px" %)1 родительский процесс и N дочерних процессов.|(% style="width:1268px" %)(((
++| |(% style="width:188px" %)**Пример задачи**|(% style="width:1268px" %)**Наборы решений**
++|1|(% style="width:188px" %)(((
++(% class="wikigeneratedid" id="H144043E43443844243543B44C44143A438439A043F44043E446435441441438N43443E44743544043D43844543F44043E44643544144143E432." %)
++1 родительский процесс и N дочерних процессов.
++)))|(% style="width:1268px" %)(((
  |В данном примере имеется в виду, что дочерние процессы могут выполняться параллельно другу и независимо друг от друга, но в конце должны оповестить родительский процесс о необходимости продолжения обработки.
  Если речь идет о каких-либо зависимостях порядка выполнения в дочерних процессах, то это может контролировать дочерний процесс (выделяя группу, которую сейчас можно запустить и ожидая окончания).
  |(((
  |(((
++(% class="wikigeneratedid" id="H41243044043843043D4421:CounterTrigger." %)
  Вариант 1: CounterTrigger.
  )))
  |(((
@@ -29,7 +29,7 @@
  * Из минус: что родительский процесс узнает о завершении дочерних процессов с задержкой.
  Если дочерний процесс падает в ошибку, TimerTrigger все равно будет крутиться и создавать пустую нагрузку.
--* Из плюсов: будет меньше пишущей нагрузки на БД (но больше читающей - на проверку) т.к. у нас не будет CounterTrigger, но будет периодический запрос на проверку завершения всех дочерних процессов (аналогично страхующему триггер).
++* Из плюсов: будет меньше пишущей нагрузки на БД чем в варианте 1 (но больше читающей - на проверку) т.к. у нас не будет CounterTrigger, но будет периодический запрос на проверку завершения всех дочерних процессов (аналогично страхующему триггер).
  * [Расширенный]: Дочерние процессы в блоке wakeup condition проверяют наличие незавершенных процессов.
  ** Если все процессы завершены или (незавершенных процессов мало и нет процессов с ошибкой), то можно опубликовать событие на TimerTrigger на сброс или установку минимальной задержки.
  )))
@@ -44,12 +44,10 @@
  Также решает проблему, если дочерний процесс содержит ожидание (например асинхронный запрос-ответ), тут будет конкуренция сигнала от хендлера ответа к родительскому процессу.
  )))
  |(((
--Вариант N4:
++Вариант №4:
--SimpleStreamTrigger + Timer (один из лучших вариантов).
++SimpleStreamTrigger + Timer.
--* Если сигналов нет, то нет ложных срабатываний в отличие от варианта 2 (т.к. нет поступления сигнала от дочерних процессов).
--* Записей в БД меньше, чем от варианта 1 (счетчик нужно уменьшать, а здесь достаточно взвести флаг необработанного сигнала).
  * Триггер проверяет условие завершения всех дочерних процессов (можно прикинуть количество незавершенных дочерних процессов).
  ** Если все обработано, то пробуждает процесс и деактивируется.
  ** Иначе:
@@ -59,35 +59,45 @@
  *** выставляет задержку от оценки количества необработанных процессов (< N - малая задержка, иначе большая задержка).
  * [Расширенный]: Дочерние процессы в блоке wakeup condition проверяют наличие незавершенных процессов.
  ** Если все процессы завершены или (незавершенных процессов мало и нет процессов с ошибкой), то можно опубликовать событие на SimpleStreamTrigger на сброс или установку минимальной задержки (в дополнение к сигналу).
++* Читающей нагрузки будет немного больше чем в варианте 2 (чтение триггера на поступлении сигнала),
++но пишущей нагрузки будет меньше чем в варианте 1 (запись - только на активации новым сигналом).
++* Если сигналов нет, то нет пустых срабатываний в отличие от варианта 2 (т.к. нет поступления сигнала от дочерних процессов).
  )))
++|(((
++|Вариант №5:
++SimpleStreamTrigger + Счетчик (ExternalCounter) в [[Redis>>doc:Разработка.Базы данных.NoSQL.Ключ-значение структура.Redis.WebHome]]. (__на текущий момент самый лучший вариант__).
++|InMemory счетчик, нагрузка на БД и конкуренция.
++Дочерний процесс уменьшает счетчик. И публикует событие только если счетчик достиг 0.
++Совмещает преимущества из варианта 1.1 (при этом не нагружает БД), в случае ошибки переключается на режим 1.4.
++|(((
++Проблема: изменение счетчика не привязано к основной транзакции БД.
++
++Возможно:
++
++1. В начале транзакции (или шага) атомарно проверяем MemberSet, если есть запись то удаляем и увеличиваем счетчик на 1 (означает что процесс уже уменьшал счетчик, но потом было падение).
++1. До коммита транзакции атомарно добавляем значение в MemberSet и уменьшаем счетчик на 1. Если счетчик равен 0, то публикуем TriggerEvent
++(добавляем в ручную компенсацию вызов из пункта 1 (при откате изоляции шага и компенсации транзакции)).
++1. После коммита транзакции удаляем запись из MemberSet.
++(Если мы падаем тут, то процесс уже перешел на другой шаг или даже завершился, поэтому наличие единичной остаточной записи в memberSet не будет критичным).
++1. Trigger получает событие. (Необязательно) в хендлере может првоерить значения счетчиков и MemberSet.
++
++MemberSet используется для уменьшения вероятности увеличить или уменьшить счетчик дважды одним экземпляром дочернего процесса.
  )))
--|2|(% style="width:188px" %)Transaction outbox stream process.|(% style="width:1268px" %)[[image:TransactionOutbox. Sequence.jpg]]
--|3|(% style="width:188px" %)Stream trigger|(% style="width:1268px" %)(((
--| |(((
--* Позволяет убрать лишние запросы пробуждения процесса (когда он и так запущен).
--* __Позволяет полностью убрать задержку после остановки процесса__ (если есть новое сообщения, то он сразу же будет пробужден).
--За счет того, что триггер точно знает, что есть новые сообщения и процесс только что уснул.
--* Вводит 2 типа события, 1 сигнал о новом сообщении (содержит offset значение), 2 - процесс идет спать (содержит offset значение).
--* Вводит дополнительное состояние в триггер: максимальный offset сообщения, максимальный offset обработанного процессом сообщения, флаг состояния сна процесса.
--* В некоторых случаях позволяет не выполнять wakeup код в конце сессии обработки (если отключить wakeup, оставить только stream trigger)
--(блокировка и обновление wakeup entity, проверка wakeup условия), __улучшает перформанс такта работы__.
--)))
--|Алгоритм триггера.|(((
--* При получении события о засыпании процесса:
--Фиксирует смещение процесса обработки и сравнивает со смещением сообщения.
--Если все сообщения обработаны, то не пробуждает процесс, иначе пробуждает процесс.
--* При получении события о новом сообщении:
--Фиксирует новое наибольшее смещение.
--Если процесс не спит (по флагу в триггере), то ничего не делает.
--Если процесс спит (по флагу), то пробуждает процесс.
++|(((
++В случае обнаружения повреждения обработка фактически переходит в режим 1.4: начинает публиковать событий каждый раз и используется задержка.
--Отслеживает смещение обработки процесса и последнего события.
--Ожидает от процесса события о том, что он все обработал, его последнее смещение и он идет спать.
--Если есть сообщения со смещением больше чем указал процесс, то делает гарантированное пробуждение процесса.
--Когда поступает сигнал о новом сообщении (от отправителя сообщения), то обновляет данные о максимальном смещении и пробуждает процесс, если он спит
++Примеры проблемы:
++
++* Падение InMemory хранилища. Предполагается режим без снимков и удаление ключей.
++Обнаружение (со стороны дочернего процесса) через отсутствие ключей (проверяется в транзакции).
++* Дублирование обновления счетчика.
++Обнаружение (со стороны дочернего процесса) через значение счетчика < 0.
++Обнаружение (со стороны триггера) через активацию триггера (поступления сигнала от процесса), при этом обнаруживается что не все процессы завершены.
  )))
--|Заготовка|[[https:~~/~~/github.com/cccc1808/cccc1808.ProcessEngine/tree/cccc1808/feature/trigger_stream_trigger>>https://github.com/cccc1808/cccc1808.ProcessEngine/tree/cccc1808/feature/trigger_stream_trigger]]
  )))
++)))
++|2|(% style="width:188px" %)Transaction outbox stream process.|(% style="width:1268px" %)Смотри stream trigger.
++|-|(% style="width:188px" %) |(% style="width:1268px" %)
  |4|(% style="width:188px" %)Групповое действие|(% style="width:1268px" %)(((
  | |Действие, которое нужно применить к диапазону строк (сравнительно большому), независимо для каждой строки.
  Наличие у строк упорядоченного столбца (для выделения диапазонов).
@@ -99,3 +99,55 @@
  |(% style="width:888px" %)Родительский процесс ожидает завершения дочерних процессов (см. пример 1).|(% style="width:266px" %)
  )))
  )))
++|5|(% style="width:188px" %)Распределение заявок между исполнителями
++(Заготовка).|(% style="width:1268px" %)(((
++|(% style="width:94px" %)Описание|(% style="width:1156px" %)Есть поток заявок на деталь (создание детали требует ресурсов, 1 станок, время).
++Есть N станков. Опционально: у станка есть уровень ресурсов и коэффициент скорости работы.
++Реализация системы распределения и обработки.
++|(% style="width:94px" %)Вариант 1|(% style="width:1156px" %)(((
++| |Планирование без очереди к станку.
++| |(((
++* У процесса планировщика есть
++** StreamTrigger на поток заявок.
++(Можно использовать расширение SignalCode, чтобы временно игнорировать откладывать этот сигнал пока все слоты станков заняты).
++** StreanTrigger на поток сигналов об освобождении слота станка.
++)))
++| |Процесс планировщик назначает заявку на свободный станок.
++Вопрос наиболее эффективной функции выбора (оценка наибольшее количество ресурсов, наилучшая скорость обработки и др.).
++Когда все станки заняты планировщик ожидает освобождения станков.
++)))
++|(% style="width:94px" %)Вариант 2|(% style="width:1156px" %)(((
++| |Планировщик с очередью к станку.
++| |(((
++* У процесса станка есть StreamTrigger, на который планировщик подает сигнал в добавления задачи в его очередь.
++* У процесса планировщика есть StreamTrigger на поток заявок.
++)))
++| |При поступлении заявки процесс планировщик сразу назначает в очередь на какой либо станок.
++Хранение фактического уровня ресурсов и зарезервированного уровня ресурсов (с учетом очереди к станку).
++Вопрос наиболее эффективной функции выбора (оценка размера очереди, достаточности у станка ресурсов для ее обработки, общего количества ресурсов, скорости работы станка и др.).
++)))
++)))
++
++----
++
++==== Внутренние ссылки: ====
++
++====== Дочерние страницы: ======
++
++{{children/}}
++
++====== Обратные ссылки: ======
++
++{{velocity}}
++#set ($links = $doc.getBacklinks())
++#if ($links.size() > 0)
++  #foreach ($docname in $links)
++    #set ($rdoc = $xwiki.getDocument($docname).getTranslatedDocument())
++    * [[$escapetool.xml($rdoc.fullName)]]
++  #end
++#else
++  No back links for this page!
++#end
++{{/velocity}}
++
++----

XWiki.XWikiComments[0]

Автор

...	...	@@ -1,1 +1,0 @@
1		-XWiki.cccc1808

Комментарий

@@ -1,4 +1,0 @@
--Замечание: конфигурация задержки trigger consumer вычитывания и накопления батча trigger events.
--
--* Для примера 1 предпочтительная более большая задержка т.к. это уменьшит нагрузку на БД (агрегирует больше сигналов от дочерних процессов в одну операцию обновления). Throughput.
--* Для примера 3 в контексте inbox stream trigger, может быть предпочтительная более низкая задержка, чтобы не раздувать задержку от поступления сообщения до его обработки. Latency.

Дата

...	...	@@ -1,1 +1,0 @@
1		-2026-05-01 15:36:23.922

Изменения документа Примеры

Сводка

Подробности

Приложения

Навигация