Aeron: как устроена система обмена сообщениями, на которой работает половина HFT-индустрии

Aeron: Media Driver, shared memory, triple-buffered logs — архитектура, задающая стандарт для low-latency messaging.

Когда речь заходит о системах обмена сообщениями для high-frequency trading, одно имя всплывает в каждом разговоре — Aeron. Разработанный Мартином Томпсоном и командой Real Logic (позже Adaptive Financial Consulting), Aeron стал де-факто стандартом для передачи данных в мире, где микросекунды решают всё.

В этой статье мы разберём Aeron по частям: Transport, Archive, Cluster и Sequencer. Расскажем, как он устроен внутри, где его сильные стороны — и где начинаются проблемы.

Кратко

• Aeron — open-source (Apache 2.0) система обмена сообщениями для low-latency приложений
• IPC латентность: ~250 нс round-trip через shared memory
• Throughput: 20+ миллионов сообщений в секунду
• Четыре продукта: Transport (ядро), Archive (запись/replay), Cluster (Raft), Sequencer (total order)
• Язык: Java (основной) + C-клиент (менее полный)
• Используется: десятками HFT-фирм, маркетмейкеров и бирж

Часть 1: Aeron Transport — ядро всего

Архитектура: Media Driver

Центральный компонент Aeron — Media Driver. Это отдельный процесс (или embedded-библиотека), который управляет всей передачей данных. Приложения общаются с Media Driver через shared memory (mmap-файлы в /dev/shm).

┌──────────┐                    ┌──────────────┐                    ┌──────────┐
│ Publisher │ ── shm commands ─→│ Media Driver  │←─ shm commands ── │Subscriber│
│   (App)   │ ←─ shm responses─│  (process)    │─→ shm responses  │  (App)   │
└──────────┘                    │              │                    └──────────┘
                                │ Log Buffers  │
                                │ (data path)  │
                                └──────┬───────┘
                                       │
                                    Network
                                  (UDP/IPC)

Ключевые структуры данных:

• ManyToOneRingBuffer (MPSC) — команды от клиентов к Media Driver
• BroadcastTransmitter/Receiver — ответы от Media Driver к клиентам
• Log Buffers — triple-buffered append-only log для данных
• Position Counters — атомарные счётчики для координации позиций

Log Buffers: тройная буферизация

Данные в Aeron передаются через Log Buffers — три чередующихся term buffer. Когда один заполняется, идёт переключение на следующий (term rotation). Это позволяет publisher писать в один буфер, пока subscriber читает из другого.

Каждый term buffer — от 64 КБ до 1 ГБ. Размер фиксируется при создании Publication.

Протокол

Aeron использует собственный wire protocol поверх UDP:

• Data frames — собственно данные с заголовком (stream ID, session ID, term ID, offset)
• Status Messages — управление потоком (receiver сообщает свою позицию)
• NAK — запрос ретрансмиссии (receiver-driven)
• Setup — установка соединения
• Heartbeat — проверка активности

Производительность

Заявленные характеристики:

Эти числа впечатляют. Но есть нюанс — они получены на Java, а значит, подвержены JVM-артефактам.

Часть 2: Aeron Archive — запись и воспроизведение

Archive решает задачу сохранения сообщений на диск с возможностью replay с любой позиции.

Как работает

1. Archive-процесс подписывается на потоки через Aeron Transport
2. Все сообщения записываются в сегментированные файлы на диск
3. При необходимости — replay: Archive создаёт новую Publication из записанных данных
4. Клиент подписывается на replay-поток и получает исторические сообщения

Зачем нужен

• Аудит — регулятор требует хранить все сообщения
• Восстановление после сбоя — новый узел «догоняет» лидера через replay
• Аналитика — replay потока для бэктестинга стратегий
• Отладка — воспроизвести точную последовательность событий

Часть 3: Aeron Cluster — Raft consensus

Cluster — это fault-tolerant replicated state machine на базе Raft consensus. Используется для критически важных систем, где потеря сообщения недопустима (matching engine, order management).

Как работает

1. Leader принимает все входящие команды
2. Реплицирует каждую запись на followers через Aeron Transport
3. После подтверждения большинством — запись считается committed
4. Committed записи применяются к state machine

Характеристики

• Автоматический leader election и failover (<1 сек)
• Strongly consistent (linearizable reads через leader)
• Hot system upgrades
• Throughput: миллионы msg/sec с Raft consensus

Часть 4: Aeron Sequencer — единый порядок событий

Sequencer — новый продукт (2025), оптимизированный для капитальных рынков.

Задача

В маркетмейкинге и на биржах критически важно, чтобы все участники видели одинаковый порядок событий. Sequencer обеспечивает total ordering — единую глобальную последовательность для всех сообщений.

Архитектура

• Построен поверх Aeron Cluster
• Distributed log, реплицированный на несколько машин
• Multiple readers — несколько приложений читают один лог
• Decoupled teams — команды работают независимо в рамках единого ordering

Ограничения

Sequencer — коммерческий продукт Adaptive Financial Consulting. Closed-source. Все слабости Cluster наследуются.

Слабые стороны Aeron

При всех достоинствах, у Aeron есть фундаментальные ограничения:

1. JVM dependency

Даже с off-heap memory, JVM safepoints останавливают все потоки. GuaranteedSafepointInterval=300000 — это костыль, не решение. JIT warm-up добавляет непредсказуемость в первые минуты после старта.

C-клиент существует, но он менее feature-complete — нет Archive, нет Cluster.

2. Media Driver overhead

Отдельный процесс = дополнительный hop через shared memory. Embedded mode привязывает к JVM. В обоих случаях — лишняя непредсказуемость.

3. Фиксированные Log Buffers

Три term buffer, размер фиксирован при создании. Нет адаптивного управления памятью. Слишком большие — тратим RAM; слишком маленькие — частые term rotation.

4. Нет нативного kernel bypass

UDP-only для сети. io_uring, DPDK, AF_XDP — не поддерживаются. Aeron Premium добавляет kernel bypass, но это закрытый платный продукт.

5. SBE — отдельная зависимость

XML-схемы, Java-кодогенератор, отдельный build step. Нет интеграции в язык.

6. Нет zero-copy networking

Данные копируются из сокета в log buffer. На Linux 6.0+ io_uring позволяет zero-copy send/recv, но Aeron этим не пользуется.

Альтернативы

Мы в Marketmaker.cc разработали ZigBolt — open-source альтернативу Aeron на языке Zig. Без JVM, без GC, с comptime-кодеками и 20 нс латентностью на SPSC. Подробнее — в нашей статье про ZigBolt.

Заключение

Aeron — это выдающийся инженерный проект, который задал стандарт для low-latency messaging. Его архитектурные решения (triple-buffered logs, NAK-based reliability, Raft cluster) стали образцом для подражания.

Но мир не стоит на месте. Языки вроде Zig и Rust позволяют достичь тех же (и лучших) результатов без JVM overhead. Kernel bypass через io_uring и DPDK открывает возможности, недоступные чистому UDP. А comptime-кодогенерация делает отдельные XML-схемы и Java-кодогенераторы артефактом прошлого.

Aeron останется в production у десятков компаний ещё на годы. Но для новых проектов стоит смотреть на альтернативы — в том числе на ZigBolt.

Ссылки:

• Aeron GitHub: github.com/real-logic/aeron
• Aeron Wiki: github.com/real-logic/aeron/wiki
• Martin Thompson (создатель): mechanical-sympathy.blogspot.com
• ZigBolt (наша альтернатива): статья | сайт
• Marketmaker.cc: marketmaker.cc

Цитирование

@article{soloviov2026aeron,
  author = {Soloviov, Eugen},
  title = {Aeron: как устроена система обмена сообщениями для HFT-индустрии},
  year = {2026},
  url = {https://marketmaker.cc/ru/blog/post/aeron-messaging-overview},
  description = {Разбор архитектуры Aeron — Transport, Archive, Cluster, Sequencer. Сильные и слабые стороны.}
}