Aeron: เบื้องหลังระบบส่งข้อความที่ขับเคลื่อนครึ่งหนึ่งของอุตสาหกรรม HFT

Aeron Messaging Architecture Aeron: Media Driver, หน่วยความจำร่วม, triple-buffered logs — สถาปัตยกรรมที่กำหนดมาตรฐานสำหรับการส่งข้อความแฝงเวลาต่ำ

เมื่อพูดถึงระบบส่งข้อความสำหรับการซื้อขายความถี่สูง ชื่อที่ถูกกล่าวถึงในทุกบทสนทนาคือ Aeron พัฒนาโดย Martin Thompson และทีม Real Logic (ต่อมาคือ Adaptive Financial Consulting) Aeron กลายเป็นมาตรฐานโดยพฤตินัยสำหรับการส่งข้อมูลในโลกที่ไมโครวินาทีตัดสินทุกอย่าง

ในบทความนี้ เราจะแยก Aeron ออกเป็นส่วนประกอบต่างๆ ได้แก่ Transport, Archive, Cluster และ Sequencer พร้อมอธิบายว่าแต่ละส่วนทำงานอย่างไรภายใน จุดแข็งอยู่ที่ไหน — และปัญหาเริ่มต้นตรงไหน

TL;DR

Aeron — ระบบส่งข้อความโอเพ่นซอร์ส (Apache 2.0) สำหรับแอปพลิเคชันที่ต้องการแฝงเวลาต่ำ
IPC latency: ~250 ns round-trip ผ่านหน่วยความจำร่วม
Throughput: มากกว่า 20 ล้านข้อความต่อวินาที
สี่ผลิตภัณฑ์: Transport (หลัก), Archive (บันทึก/เล่นซ้ำ), Cluster (Raft), Sequencer (ลำดับทั้งหมด)
ภาษา: Java (หลัก) + C client (ไม่สมบูรณ์เท่า)
ใช้งานโดย: บริษัท HFT, market maker และ exchange หลายสิบแห่ง

ส่วนที่ 1: Aeron Transport — แกนหลัก

สถาปัตยกรรม: Media Driver

Aeron Media Driver

องค์ประกอบหลักคือ Media Driver — กระบวนการแยกต่างหาก (หรือไลบรารีฝังตัว) ที่จัดการการส่งข้อมูลทั้งหมด แอปพลิเคชันสื่อสารกับ Media Driver ผ่านหน่วยความจำร่วม (mmap files ใน /dev/shm)

โครงสร้างข้อมูลสำคัญ:

ManyToOneRingBuffer (MPSC) — คำสั่งจาก client ไปยัง Media Driver
BroadcastTransmitter/Receiver — การตอบสนองจาก Media Driver ไปยัง client
Log Buffers — append-only log แบบ triple-buffered สำหรับข้อมูล
Position Counters — atomic counter สำหรับการประสานตำแหน่ง

ประสิทธิภาพ

ตัวชี้วัด	ค่า
IPC (shared memory) RTT	~250 ns
UDP unicast RTT (bare metal)	~10 us
UDP unicast RTT (cloud, AWS)	<100 us
Throughput	>20M msg/sec
Aeron Premium (kernel bypass) P99	39 us

ส่วนที่ 2: Aeron Archive — บันทึกและเล่นซ้ำ

Archive บันทึก stream ข้อความลงดิสก์เพื่อเล่นซ้ำจากตำแหน่งใดก็ได้ กรณีการใช้งาน: การตรวจสอบตามกฎระเบียบ, การกู้คืนจากข้อขัดข้อง, backtesting, การดีบัก

ส่วนที่ 3: Aeron Cluster — Raft Consensus

Raft Consensus

Fault-tolerant replicated state machine สำหรับระบบที่การสูญเสียข้อความเป็นสิ่งที่ยอมรับไม่ได้ (matching engine, order management) รองรับการเลือก leader, การจำลองล็อก และการอ่านที่สอดคล้องกันอย่างสมบูรณ์

ส่วนที่ 4: Aeron Sequencer — การจัดลำดับทั้งหมด

ผลิตภัณฑ์ใหม่ (2025) ที่ปรับแต่งสำหรับตลาดทุน ให้การจัดลำดับเดียวกันสำหรับเหตุการณ์ทั้งหมดในระดับโลก — สำคัญมากสำหรับ matching engine และ market making แบบ multi-venue สร้างบน Cluster ผลิตภัณฑ์เชิงพาณิชย์ (ปิดซอร์ส)

จุดอ่อน

JVM Overhead and GC Pauses

การพึ่งพา JVM — safepoint, GC pause, การอุ่นเครื่อง JIT
ค่าใช้จ่าย Media Driver — ขั้นตอนพิเศษผ่านหน่วยความจำร่วม
ไม่มี kernel bypass แบบ native — รองรับเฉพาะ UDP (io_uring, DPDK ไม่รองรับในเวอร์ชันโอเพ่นซอร์ส)
SBE เป็นส่วนแยก — XML schema, Java code generator, ขั้นตอน build แยกต่างหาก
ไม่มี zero-copy networking — ข้อมูลถูกคัดลอกจาก socket ไปยัง log buffer

ทางเลือกอื่น

โปรเจกต์	ภาษา	จุดแข็ง	จุดอ่อน
Aeron	Java/C	เสถียร, ผ่านการทดสอบจริง, ecosystem ครบครัน	ค่าใช้จ่าย JVM, ไม่มี kernel bypass (โอเพ่นซอร์ส)
ZigBolt	Zig	20 ns SPSC, zero-copy codecs, ไม่มี GC	โปรเจกต์ใหม่ (v0.2.1)
Chronicle Queue	Java	Persistent, รองรับหลายพันล้านข้อความต่อวัน	JVM GC, หนักเกินไป
ZeroMQ	C	API ง่าย, รองรับหลาย transport	ไม่มี reliability layer, ไม่มี clustering

ที่ Marketmaker.cc เราพัฒนา ZigBolt — ทางเลือกโอเพ่นซอร์สสำหรับ Aeron ที่เขียนด้วย Zig ไม่มี JVM, ไม่มี GC, comptime codec, แฝงเวลา SPSC 20 ns อ่านเพิ่มเติมได้ใน บทความ ZigBolt ของเรา

ลิงก์:

Aeron GitHub: github.com/real-logic/aeron
Martin Thompson: mechanical-sympathy.blogspot.com
ZigBolt (ทางเลือกของเรา): บทความ | เว็บไซต์
Marketmaker.cc: marketmaker.cc

การอ้างอิง

@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 = {เจาะลึกสถาปัตยกรรม: Aeron Transport, Archive, Cluster, Sequencer}
}