Leistungsfähigkeit und Skalierbarkeit von Camunda 7
Wie Camunda 7 einen hohen Durchsatz bewältigt
Persistenz-Strategien
Camunda 7 läuft mit vielen verschiedenen relationalen Datenbanken (siehe: Supported Environments). Camunda nutzt diese Datenbanken so effizient wie möglich und wendet dabei die folgenden Konzepte an:
Kompakte Tabellen
Camunda 7 verwendet ein kompaktes Datenmodell und anspruchsvolle Algorithmen, um die Anzahl der Zeilen zu minimieren, die zur Speicherung des Status von Prozessinstanzen in der Datenbank erforderlich sind. Dadurch wird die Ausführung beschleunigt, da die Anzahl der zu speichernden Zeilen reduziert wird. Im besten Fall muss nur eine einzige Zeile aktualisiert werden, wenn von einer Aktivität zur nächsten übergegangen wird.
Deadlock-Vermeidung
Camunda 7 verwendet eine optimierte Parallelitätssteuerung, um ein hohes Maß an Parallelität zu unterstützen und gleichzeitig das Risiko von Deadlocks zu minimieren. Sperren werden niemals während der Arbeitszeit des Benutzers durchgeführt. Alle Änderungen des Datenbankzustands werden am Ende einer Transaktion einem Batch-Flush unterzogen, wobei eine intelligente Reihenfolge von SQL-Anweisungen verwendet wird, um zirkuläre Wartezeiten zu vermeiden.
Savepoints steuern
Wenn ein Savepoint erreicht ist, wird der In-Memory-Status mit der Datenbank synchronisiert, um Fehlertoleranz zu gewährleisten. Camunda 7 erlaubt eine fein abgestimmte Kontrolle über die Platzierung von Savepoints und ermöglicht Ihnen so, Fehlertoleranz und Leistung in Einklang zu bringen. Beispielsweise können Sie die Ausführung mehrerer Aktivitäten in einer einzigen Transaktion stapelweise ausführen und dadurch die Anzahl der Datenbank-Synchronisationspunkte reduzieren.
Intelligentes Caching
Savepoints mit Nur-Schreibzugriff werden durch Wiederverwendung des 1st-Level-Caches in nachfolgenden Transaktionen unterstützt. Dadurch wird die Anzahl der SELECT-Abfragen, die zur Ausführung einer Folge von Aktivitäten mit zwischengeschalteten Savepoints erforderlich sind, erheblich reduziert. Dies ist am effektivsten bei der Implementierung datenintensiver Prozesse wie JSON oder XML-Nutzlasttransformation.
Echte Parallelität
Gleichzeitige Token werden als einzelne Zeilen in der Datenbank dargestellt. Dieses Modell ermöglicht eine echte Parallelität von Intra-Prozessinstanzen, da einzelne Zeilen gleichzeitig aktualisiert werden können.
Clustering
Sie können Camunda 7 in einem Cluster ausführen, um Lastausgleich und/oder Hochverfügbarkeit zu erreichen. Beispielsweise ist es ein sehr häufiger Anwendungsfall, Camunda in einer aktiv/aktiven Konfiguration zu betreiben.
Mehrere Knoten, gemeinsam genutzte Datenbank
Um Funktionen für Lastenausgleich oder Failover bereitzustellen, kann die Prozess-Engine auf verschiedene Knoten in einem Cluster verteilt werden. Jede Prozess-Engine-Instanz stellt dann eine Verbindung zu einer gemeinsamen Datenbank her.
Die einzelnen Prozess-Engine-Instanzen behalten den Sitzungsstatus nicht transaktionsübergreifend bei. Immer wenn die Prozess-Engine eine Transaktion ausführt, wird der komplette Zustand in die gemeinsam genutzte Datenbank übertragen. Dadurch ist es möglich, nachfolgende Abfragen aus derselben Prozessinstanz an verschiedene Clusterknoten zu leiten. Dieses Modell ist sehr einfach, leicht verständlich und erfordert nur begrenzte Einschränkungen bei der Bereitstellung einer Cluster-Installation. Was die Prozess-Engine betrifft, gibt es auch keinen Unterschied zwischen Setups für den Lastausgleich und Setups für das Failover (da die Prozess-Engine zwischen Transaktionen keinen Sitzungsstatus beibehält).
Infolgedessen ist es äußerst einfach, HA-Konfigurationen wie aktive/aktive Knoten einzurichten.
Der Job Executor er Prozess-Engine ist ebenfalls geclustert und läuft auf jedem Knoten. Auf diese Weise gibt es keinen Single Point of Failure, was die Prozess-Engine betrifft. Der Job Executor kann sowohl in homogenen, als auch in heterogenen Clustern ausgeführt werden.
Minimale Ressourcenzuweisung
Da die Prozess-Engine zustandslos ist, weist sie eine minimale Menge an RAM-Ressourcen pro Knoten zu (normalerweise weniger als 10 MB). Im Grunde können Sie Milliarden von Prozessinstanzen in der Datenbank persistieren lassen, ohne dass dies notwendigerweise Auswirkungen auf die Ressourcenzuweisung pro Knoten hat. Dies bedeutet auch, dass Sie viele Prozess-Engine-Instanzen pro Knoten ausführen können.
Laufzeit vs. Verlauf
Laufzeitdaten sind die minimale Datenmenge, die die Prozess-Engine von Camunda 7 benötigt, um eine asynchrone Fortsetzung auszuführen – z. B. wenn die Prozess-Engine auf eine Benutzerinteraktion (Benutzer-Task), eine eingehende Nachricht (Nachrichten-Ereignis) oder eine Zeitspanne (Timer-Event), wartet, oder wenn es asynchrone Service-Interaktionen gibt Service-Task).
Verlaufsdaten sind für die Durchführung nicht erforderlich, können aber für Audits, Berichte usw. protokolliert werden. Sie ermöglichen es Ihnen, den vollständigen Audit-Trail laufender und abgeschlossener Prozessinstanzen einschließlich ihrer Nutzlast einzusehen.
Camunda trennt Laufzeitdaten von Verlaufsdaten, was ein sehr leistungsfähiges Architekturkonzept zur Leistungsoptimierung darstellt.
Verlaufs-Ereignis-Stream
Zusätzlich zur Aufrechterhaltung des Laufzeitstatus erstellt die Prozess-Engine ein Audit-Protokoll, das Audit-Informationen über ausgeführte Prozessinstanzen enthält. Wir nennen diesen Ereignisstrom den Verlaufs-Ereignis-Stream. Die einzelnen Ereignisse, aus denen sich dieser Ereignis-Stream zusammensetzt, werden als Verlaufs-Ereignisse bezeichnet und enthalten Daten über ausgeführte Prozessinstanzen, Aktivitätsinstanzen, geänderte Prozessvariablen und so weiter. In der Standardkonfiguration schreibt die Prozess-Engine diesen Ereignis-Stream einfach in die History-Datenbank von Camunda. Die HistoryService API ermöglicht Abfragen aus dieser Datenbank.
Konfigurierbare Log-Ebene
Die Verlaufsebene steuert die Datenmenge, die die Prozess-Engine über den Verlaufs-Ereignis-Stream bereitstellt. Eine Reihe von Einstellungen sind sofort verfügbar, wie z. B. mit oder ohne Nutzlast (Prozessvariablen), oder „full“ oder „none“. Sie können jedoch auch Ihre ganz eigene Konfiguration der Protokollebene erstellen. Zum Beispiel könnten Sie entscheiden, dass nur für bestimmte Prozesse einer bestimmten Art eine bestimmte Datenmenge protokolliert werden soll, z. B. wenn Aufträge mit einem Volumen von mehr als 100 USD bearbeitet werden.
Big Data
Alternativ können Sie den Verlaufs-Ereignis-Stream an jedes beliebige Ziel umleiten, einschließlich Warteschlangen und aller Big-Data-Lösungen, die Sie verwenden möchten. Dies ist möglich, da Camunda 7 keinen Status aus der Historiendatenbank liest.
