Aeron: Ein Blick in das Messaging-System, das die Hälfte der HFT-Branche antreibt

Aeron: Media Driver, Shared Memory, dreifach gepufferte Logs – die Architektur, die den Standard für Low-Latency-Messaging gesetzt hat.

Wenn es um Messaging-Systeme für den Hochfrequenzhandel geht, fällt in jedem Gespräch ein Name – Aeron. Entwickelt von Martin Thompson und dem Team von Real Logic (später Adaptive Financial Consulting), wurde Aeron zum De-facto-Standard für die Datenübertragung in einer Welt, in der Mikrosekunden über alles entscheiden.

In diesem Artikel zerlegen wir Aeron in seine Bestandteile: Transport, Archive, Cluster und Sequencer. Wir erklären, wie es intern funktioniert, wo seine Stärken liegen – und wo die Probleme beginnen.

TL;DR

• Aeron – Open-Source-Messaging-System (Apache 2.0) für Low-Latency-Anwendungen
• IPC-Latenz: ~250 ns Round-Trip über Shared Memory
• Durchsatz: über 20 Millionen Nachrichten pro Sekunde
• Vier Produkte: Transport (Kern), Archive (Aufzeichnen/Wiedergabe), Cluster (Raft), Sequencer (totale Ordnung)
• Sprache: Java (primär) + C-Client (weniger vollständig)
• Eingesetzt von: Dutzenden HFT-Firmen, Market Makern und Börsen

Teil 1: Aeron Transport – Der Kern

Architektur: Media Driver

Die zentrale Komponente ist der Media Driver – ein separater Prozess (oder eine eingebettete Bibliothek), der die gesamte Datenübertragung verwaltet. Anwendungen kommunizieren mit ihm über Shared Memory (mmap-Dateien in /dev/shm).

Wichtige Datenstrukturen:

• ManyToOneRingBuffer (MPSC) – Befehle von Clients an den Media Driver
• BroadcastTransmitter/Receiver – Antworten vom Media Driver an die Clients
• Log Buffers – dreifach gepuffertes Append-only-Log für Daten
• Position Counters – atomare Zähler zur Positionskoordination

Performance

Teil 2: Aeron Archive – Aufzeichnen und Wiedergeben

Archive zeichnet Nachrichtenströme auf die Festplatte auf, um sie von jeder beliebigen Position wiederzugeben. Anwendungsfälle: regulatorisches Audit, Crash-Recovery, Backtesting, Debugging.

Teil 3: Aeron Cluster – Raft-Konsens

Fehlertolerante replizierte Zustandsmaschine für Systeme, bei denen der Verlust einer Nachricht inakzeptabel ist (Matching Engines, Order-Management). Leader-Wahl, Log-Replikation, streng konsistente Lesevorgänge.

Teil 4: Aeron Sequencer – Totale Ordnung

Neues Produkt (2025), optimiert für die Kapitalmärkte. Es liefert eine einzige globale Ordnung aller Ereignisse – entscheidend für Matching Engines und Multi-Venue-Market-Making. Baut auf Cluster auf. Kommerzielles Produkt (Closed Source).

Schwächen

1. JVM-Abhängigkeit – Safepoints, GC-Pausen, JIT-Warm-up
2. Media-Driver-Overhead – zusätzlicher Sprung durch den Shared Memory
3. Kein nativer Kernel Bypass – nur UDP (io_uring, DPDK werden in der Open-Source-Version nicht unterstützt)
4. SBE ist separat – XML-Schemas, Java-Codegenerator, separater Build-Schritt
5. Kein Zero-Copy-Networking – Daten werden vom Socket in den Log Buffer kopiert

Alternativen

Wir von Marketmaker.cc haben ZigBolt entwickelt – eine Open-Source-Alternative zu Aeron in Zig. Keine JVM, kein GC, Comptime-Codecs, 20 ns SPSC-Latenz. Mehr dazu in unserem ZigBolt-Artikel.

Links:

• Aeron GitHub: github.com/real-logic/aeron
• Martin Thompson: mechanical-sympathy.blogspot.com
• ZigBolt (unsere Alternative): Artikel | Website
• Marketmaker.cc: marketmaker.cc

Zitat

@article{soloviov2026aeron,
  author = {Soloviov, Eugen},
  title = {Aeron: Inside the Messaging System That Powers Half of the HFT Industry},
  year = {2026},
  url = {https://marketmaker.cc/en/blog/post/aeron-messaging-overview},
  description = {Architecture deep-dive: Aeron Transport, Archive, Cluster, Sequencer.}
}