× Install ThecoreGrid App
Tap below and select "Add to Home Screen" for full-screen experience.
B2B Engineering Insights & Architectural Teardowns

Einzel-Thread-Architektur für deterministisches Trading

Die Einzel-Thread-Architektur in Kombination mit Raft gewährleistet Determinismus und Fehlertoleranz in Börsensystemen. Dies ist entscheidend, wenn der Preis eines Fehlers nicht durch Latenz, sondern durch direkte finanzielle Verluste gemessen wird.

Das Problem in der Börsenarchitektur zeigt sich, wenn das System auf ein Ungleichgewicht zwischen Geschwindigkeit und Vorhersagbarkeit stößt. Die Anforderungen sind widersprüchlich: Sub-Millisekunden-Latenz, strikte Fairness bei der Ausführung und die Möglichkeit, den Marktstatus zu jedem Zeitpunkt wiederherzustellen. Jede Nicht-Determinierung bricht die Reproduzierbarkeit. Ohne sie sind weder Audits noch eine präzise Analyse von Vorfällen möglich. Der Versuch, die Verarbeitung von Aufträgen zu parallelisieren, erhöht den Durchsatz, führt jedoch zu Wettläufen und macht das Verhalten des Systems von den Timings abhängig.

Als Lösung wird eine Einzel-Thread-Architektur für den Kern des Matching-Engines gewählt. Dies ist ein bewusster Verzicht auf Parallelismus in kritischen Abschnitten. Alle Eingabeveranstaltungen werden strikt sequenziell verarbeitet. Dieser Ansatz vereinfacht das Modell: Identische Eingabedaten führen immer zu identischen Ergebnissen. Für Fehlertoleranz und Verfügbarkeit wird daraufhin der Raft-Konsens hinzugefügt. Er repliziert das Transaktionsprotokoll zwischen Knoten und garantiert einen konsistenten Zustand. Der Trade-off ist offensichtlich: eine Einschränkung der CPU-Skalierbarkeit gegenüber starker Determinierung und einfacherem Verständnis des Systems.

Ein Schlüsselprinzip ist der Determinismus. Er ermöglicht die Umsetzung mehrerer wichtiger Eigenschaften:

  • Reproduktion von Produktionsvorfällen durch Replay von Protokollen
  • Zero-Downtime-Rolling-Deployments durch identisches Verhalten der Versionen
  • Exakte Wiederherstellung des Marktstatus zu einem beliebigen Zeitpunkt

Das funktionale Modell der Börse wird auf grundlegende Regeln vereinfacht, wie z.B. Preis-Zeit-Priorität. Dies ist eine kompakte Formalisierung komplexen Verhaltens. Sie definiert, welcher Auftrag zuerst ausgeführt wird, wenn die Preise übereinstimmen. Wichtig ist, dass solche Regeln leicht in einem sequenziellen Modell kodiert werden können und in einem konkurrierenden Modell schwierig sind.

Die Implementierung beginnt nicht mit Optimierungen, sondern mit dem Aufbau eines Test-Harness. Das System wird als schwarzer Kasten betrachtet: Eingabe-API-Aktionen, interner Zustand des Orderbuchs und Ausgabeereignisse. Dieser Ansatz fixiert das erwartete Verhalten vor der Optimierung. Anschließend wird der Kern der Matching-Logik isoliert und minimiert. Je weniger Code im kritischen Pfad vorhanden ist, desto einfacher ist es, dessen Determinismus zu garantieren.

Schwierigkeiten treten an der Grenze zur Außenwelt auf. Die Börse ist nicht nur Matching, sondern auch die breitbandige Zustellung des Status an die Teilnehmer, die Speicherung der Historie und die Einhaltung regulatorischer Anforderungen. Zum Beispiel muss es möglich sein, den Marktstatus auf Mikrosekundenebene über Jahre hinweg wiederherzustellen. Dies erfordert strikte Persistenz aller bestätigten Ereignisse und Konsistenz der Replikate. Hier löst Raft das Konsistenzproblem, fügt jedoch Koordinationskosten hinzu.

Besonderes Augenmerk wird auf die Verteilung der Latenz gelegt. Es ist nicht nur der Durchschnittswert wichtig, sondern auch die Schwänze (P99). Marktteilnehmer entwickeln Strategien unter Berücksichtigung dieser Eigenschaften. Unvorhersehbare Verzögerungen führen zu finanziellen Verlusten. Das sequenzielle Modell hilft, die Schwänze zu „glätten“, da es die Variabilität, die mit der Konkurrenz von Threads verbunden ist, beseitigt.

Das Ergebnis dieses Ansatzes ist ein System, in dem das Verhalten vorhersehbar und reproduzierbar ist. Dies ermöglicht:

  • 24/7 Verfügbarkeit durch Replikation aufrechtzuerhalten
  • Sichere Deployments ohne Unterbrechung durchzuführen
  • Jegliche Vorfälle genau zu analysieren

Dabei gibt es in den Ausgangsdaten keine spezifischen Metriken zu Latenz oder Durchsatz. Aber die architektonische Wahl zielt eindeutig auf ein Gleichgewicht ab: minimale Komplexität des Kerns gegenüber Skalierbarkeit durch horizontale Verteilung über Konsens.

Ähnliche Lösungen werden seit langem in der Finanzsystemindustrie diskutiert. Hier sind sie bis zum logischen Ende gebracht: Es ist besser, auf Parallelismus zu verzichten, als die Kontrolle über das System zu verlieren. Im Kontext von Highload erscheint dies kontraintuitiv, aber gerade der Determinismus wird zur Grundlage für Zuverlässigkeit.

Lesen

×

🚀 Deploy the Blocks

Controls: ← → to move, ↑ to rotate, ↓ to drop.
Mobile: use buttons below.