Производительность и масштабируемость

Как работает Camunda Workflow Engine с высокой пропускной способностью.

Стратегии сохранения

Camunda работает во многих разных реляционных базах данных (тут: поддерживаемые среды). Camunda использует эти базы данных как можно эффективнее, применяя следующие концепции:

Компактные таблицы

Camunda использует компактную модель данных и сложные алгоритмы для минимизации количества строк, необходимых для хранить состояние экземпляров процесса в базе данных. Это ускоряет выполнение, уменьшая количество строки, которые необходимо сохранить. В лучшем случае только одна строка должна быть обновлена, если перейти от одного деятельность к следующему.

Отказ от тупика

Camunda использует оптимистичный контроль параллелизма для поддержки высокого уровня параллелизма при минимизации риск мертвых замков. Замки никогда не удерживаются в течение времени ожидания пользователя. Все изменения в состоянии базы данных пакет очищается в конце транзакции при использовании интеллектуального упорядочения SQL-операторов, чтобы избежать кругового ждет.

Контрольные точки сохранения

При достижении точки сохранения состояние в памяти синхронизируется с базой данных для обеспечения Отказоустойчивость. Camunda обеспечивает мелкий гранулированный контроль за размещением точек сохранения, и, таким образом, позволяет сбалансировать отказоустойчивость и производительность. Например, вы можете выполнить несколько операций в одной транзакции и этим уменьшают количество синхронизации базы данных точки.

Интеллектуальное кэширование

Сохраненные точки записи поддерживаются путем повторного использования кеша 1-го уровня в последующих транзакциях. Это существенно сокращает количество операторов SELECT, необходимых для выполнения операции с промежуточными точками сохранения. Это наиболее эффективно при внедрении тяжелых процессов, таких как JSON или преобразование полезной нагрузки XML

Правильная цена

Параллельные токены представлены в виде отдельных строк в базе данных. Эта модель позволяет внутрипроцессный параллельный процесс, поскольку отдельные ряды могут обновляться одновременно.

Кластеризация

Вы можете запустить Camunda в кластере, чтобы добиться балансировки нагрузки и / или высокой доступности. Например, это очень обычный вариант использования для запуска Camunda в активной / активной конфигурации.

Несколько узлов, общая база данных

Чтобы обеспечить балансировку нагрузки или возможности отказа, механизм процесса может быть различные узлы в кластере. Каждый экземпляр механизма процесса подключается к общей базе данных.

Отдельные экземпляры механизма процесса не поддерживают состояние сеанса между транзакциями.                                      Всякий раз, когда механизм процесса запускает транзакцию, полное состояние выгружается в общую базу данных.                                      Это позволяет маршрутизировать последующие запросы, которые работают в одном экземпляре процесса, с разными                                      узлы кластера. Эта модель очень проста и понятна и налагает ограниченные ограничения, когда она                                      приступает к развертыванию кластерной установки. Что касается двигателя процесса, то также нет                                      разница между настройками для балансировки нагрузки и настройками для отказа (поскольку механизм процесса не поддерживает                                      состояние сеанса между транзакциями).

Как следствие, очень просто настроить HA-конфигурации, такие как активные / активные узлы.

Механизм процесса оператор выполнения также группируется и запускается на каждом узле. Таким образом, нет единственной точки отказа в отношении процесса. Исполнитель задания может работать как в однородные и гетерогенные кластеры.

Минимальное распределение ресурсов

Поскольку механизм процесса не имеет состояния, он выделяет минимальный объем ресурса ОЗУ на узел (обычно менее 10 МБ). В принципе, вы можете иметь миллиарды экземпляры процессов сохраняются в базе данных без какого-либо влияния на распределение ресурсов на узел. Это также означает, что вы можете запускать множество экземпляров процесса для каждого узла.

Время выполнения и история

Данные времени выполнения это минимальный объем данных, которые двигатели процесса Camunda должны сохраняться, чтобы выполнять асинхронное продолжение. когда процесс-движок ждет взаимодействия с пользователем (задача пользователя), входящие сообщения (Событие по сообщению) или timespan (timer event), or when there are асинхронные сервисные взаимодействия (служебная задача).

Данные истории не требуются для выполнения, но могут регистрироваться для аудита, отчетности и т. д. Они разрешают вы проверяете полный контрольный список запущенных и завершенных экземпляров процессов, включая их полезную нагрузку.

Camunda отделяет данные Runtime от исторических данных, что является очень мощной архитектурной концепцией оптимизации производительности.

История событий

В дополнение к поддержанию состояния времени выполнения механизм процесса создает журнал аудита, обеспечивающий                                      аудиторская информация о выполненных экземплярах процесса. Мы называем этот поток событий потоком событий истории.                                      Отдельные события, которые составляют этот поток событий, называются событиями истории и содержат данные о                                      исполняемые экземпляры процессов, экземпляры операций, измененные переменные процесса и т. д.                                      В конфигурации по умолчанию механизм процесса просто напишет этот поток событий в историю Camunda                                      база данных. API HistoryService позволяет запрашивать эту базу данных.

Настраиваемый уровень журнала

Уровень истории контролирует объем данных, предоставляемых механизмом процесса через поток событий истории.                                  Ряд настроек доступен из коробки, например, с полезной нагрузкой или без нее (переменные процесса) или «полный»,                                  или "none". Однако вы также можете создать свою собственную конфигурацию уровня журнала. Например, вы можете решить, что                                  только для определенных процессов определенного вида должен регистрироваться количество данных certai, например. когда заказы                                  которые имеют объем более 100 долларов США.

Большие данные

Кроме того, вы можете перенаправить поток событий истории на любую нужную вам цель, включая очереди и                                  когда-либо большие решения для данных, которые вы хотите использовать. Это возможно, потому что компонент Camunda Process Engine не считывает состояние                                   из базы данных истории.