Aeron 是一个开源的高性能消息传输系统,由 Martin Thompson 和 Todd Montgomery 在 Real Logic 创建,目前由 Adaptive Financial Consulting 主导维护。它是电子交易领域用于低延迟消息传输与高可用集群的全球技术标准,GitHub 组织地址为 aeron-io/aeron。
一、定位与设计目标
Aeron 是一个面向 Java、C/C++ 的超高效消息传输库,设计运行在 UDP、Infiniband 等不可靠介质之上,提供有序消息传输和可选的可靠性保证(通过丢包重传)。它对低延迟通信有极致的追求,适用于高频交易、实时游戏、VOIP、视频流等实时性场景。Java 实现被设计为稳态运行时不产生垃圾对象,从而降低内存压力和 GC 负担。
支持语言:Java、C/C++、.NET。
二、三大核心产品
Aeron 项目由三个层次的产品组成:
Aeron Transport(传输层)——底层消息传输。为单播与组播提供安全的数据流,同时支持本机的 IPC 消息传输,可交付个位数微秒级的可预测延迟,吞吐量超过每秒 2000 万条消息。
Aeron Archive(归档层)——在 Transport 之上提供消息归档与回放。允许消息流以全速率持久化到磁盘,使断连的服务能够重新连接并可靠恢复而不丢失消息。支持从指定位置回放,支持将录制从一个进程复制到另一个进程(用于近实时备份)。归档可被清除、截断或做 CRC 校验。
Aeron Cluster(集群层)——用于构建高性能、内存式、容错的事务型服务框架,具有自动故障转移和 99.999 分位数据不丢失 SLA,故障切换在一秒内完成。
三、架构与核心组件
Aeron 由三部分组成:Media Driver(媒体驱动)、Client API(客户端 API)、Publication/Subscription 模型。
Media Driver(媒体驱动)
Media Driver 负责在活跃 publication/subscription 使用的介质(UDP 或 IPC)上收发数据。它设计灵活,可以配置为极致高性能低延迟,也可以运行在资源受限环境。虽然概念上类似分布式消息代理,但缺少许多 broker 的功能——最好把它视作与消息代理不同的东西。
Driver Conductor 接受 publisher/subscriber 的命令并编排 Media Driver 的行为,同时负责名称解析;Sender 管理数据在介质上的发送;Client Conductor 负责与 Driver Conductor 通信。
Media Driver 可以嵌入运行,也可以作为独立进程运行。目录建议放在 /dev/shm 下,并保证足够存储空间。Media Driver 通常运行在独立进程/线程中,应用发送消息的唯一开销就是写共享内存缓冲区,网络传输全部由 Media Driver 在后台完成。接收端只需轮询 subscription 内存缓冲区检查新消息。
消息模型
通信抽象为流(称为 Channel):publisher 创建 Publication 发送消息,subscriber 通过 Subscription 接收消息,多个 subscriber 可以监听同一个 publication。
Publication 是开发者向 Subscription 发送数据的主要 API。offer 和 tryClaim 两个方法都是非阻塞的。发送的数据会追加到本地 Log Buffer,Media Driver 异步地将数据通过指定介质发送出去。未被 spy 的 publication 只有当 subscription 就绪时才能发送数据(UDP 和 IPC 都是如此)。单条消息的最大长度受 MTU 限制,可以通过 maxPayloadLength() 查询。
典型消息流
Publisher → Publication → Media Driver → Channel → Subscription → Subscriber,整个过程无锁,保证低延迟。
Java 示例:
// 发布端
Aeron aeron = Aeron.connect();
Publication publication = aeron.addPublication("aeron:udp?endpoint=localhost:40123", 1);
UnsafeBuffer buffer = new UnsafeBuffer(new byte[256]);
buffer.putStringUtf8(0, "Hello Aeron!");
while (!publication.offer(buffer)) { /* 背压重试 */ }
// 订阅端
Subscription subscription = aeron.addSubscription("aeron:udp?endpoint=localhost:40123", 1);
FragmentHandler handler = (buf, off, len, hdr) -> System.out.println(buf.getStringUtf8(off, len));
while (true) { subscription.poll(handler, 10); }四、传输方式
Aeron 支持多种传输介质:
- UDP 单播 / UDP 组播——网络通信
- IPC(共享内存)——同机进程间通信,延迟纳秒级
- MDC(Multi-Destination-Cast)——在不支持 UDP 组播的云环境中,MDC 通过单播流模拟组播,允许发布应用向一个 MDC 地址发送一次,由多个订阅方共同监听
Channel 通过 URI 描述,例如 aeron:udp?endpoint=host:port 或 aeron:ipc。
五、Aeron Cluster 与 Raft
Aeron Cluster 是解决容错交易系统难题的方案:采用单线程状态机模型简化设计,避免了多线程域模型带来的竞态、死锁和调试复杂度。通过状态机复制实现容错——多副本并行运行,一份失败另一份可自动接管。Raft 共识算法负责协调状态机保持同步。
Aeron Cluster 实现 Raft 共识算法,提供日志复制,让多个节点保持相同状态,并通过自动领导者选举确保集群中始终只有一位 leader。Raft 主要是日志复制协议,因此 Aeron Cluster 用 Aeron Archive 来持久化日志。Consensus Module 是关键组件,它与 Archive 协调持久化消息,并向其他节点复制/确认消息,然后把消息投递给 Clustered Services——即开发者提供的应用逻辑。
共识过程:leader 计算大多数(至少半数)成员已经落盘的位置,发送给 followers 作为 CommitPosition(Raft 中的最新提交条目)。若某成员宕机,数据也至少存在另一成员上可恢复。leader 和 followers 随后可处理到 CommitPosition,将新提交的条目应用到复制状态机(即你的服务)。服务通过 Egress channel 响应客户端,只有 leader 的响应会被送出,followers 的响应被 Aeron Cluster 静默丢弃。
需要注意的权衡:Raft 客户端可能在 leader 故障时丢失数据。以 Artio FIX 引擎搭配 Aeron Cluster 构建交易系统为例,leader 故障期间用户 FIX session 发出的数据可能丢失。客户端实现必须做出决策——例如断开所有 FIX session 并提供协议验证订单/成交状态。
六、性能表现
在 AWS 2025/2026 基准测试中:
- Aeron Transport Premium 可达到 29 微秒的往返延迟,Aeron Cluster Premium 可达到 98 微秒往返延迟。开源版本相比上代提升 70%(Transport)与 64%(Cluster)。Premium 相比开源版本仍领先 33%(Transport)与 29%(Cluster)
- 在 100 万消息/秒时,Aeron Premium 依然维持 P99 延迟,内核旁路让 Premium 相比开源版本在高吞吐下 P99 延迟降低超过 50%
Google Cloud 测试:开源版 Aeron 消息传输往返时间 57 微秒,Premium 降至 18 微秒;吞吐从 80 万条/秒提升到 470 万条/秒。Aeron Cluster 开源版延迟 109 微秒,Premium 降至 36 微秒;吞吐从 25 万条/秒提升到 220 万条/秒(约 8.8 倍)。
当前版本 1.50.3(RabbitMQ 对比文中提到)Aeron 的 IPC 延迟在几百纳秒级,网络吞吐在商用硬件上超过每秒百万消息。
七、关键性能技术
- 无锁设计——保证可预测的延迟与吞吐
- 直接内存访问——利用堆外缓冲区,速度更快、减少 GC 停顿
- 共享内存 IPC——同机走
/dev/shm,零拷贝 - Mechanical Sympathy——与现代 CPU 缓存架构协同,避免伪共享等问题
- 单写者原则——每个 Log Buffer 有明确写入者,避免竞争
八、与其他方案对比
Kafka 强在持久化与可伸缩性,适合分析管道,选择它是因为持久化和回放比超低延迟更重要;ZeroMQ 轻量灵活但缺少内建的可靠性与顺序保证;Chronicle Queue 强在低延迟磁盘持久化,适合事件溯源。关键差异在于:Aeron 即便在 100 万消息/秒下仍能保持微秒级延迟,而 Kafka 在超过每分区约 10 万消息/秒时延迟通常会显著下降。
九、典型使用场景
- 高频/算法交易(订单簿、撮合引擎、市场数据分发)
- 实时风控与信用检查
- 低延迟微服务通信(替代 gRPC 于内部关键路径)
- FIX 引擎(如 Artio)后端
- 实时分析与遥测
十、生态与配套
- Agrona——高性能数据结构库,Aeron 的基础依赖
- SBE(Simple Binary Encoding)——配套的极致高效二进制序列化
- Artio——基于 Aeron 的开源 FIX 引擎
- aeron-rs——Rust 客户端(aeron-rs 实现客户端功能,需要下载/编译来自 real-logic/aeron 的 Media Driver。集成测试假设 aeronmd 可执行文件在 PATH 中)
十一、部署要点
推荐 Java 11 或更高版本;生产环境推荐 Linux,可利用高精度定时器与高级网络特性。推荐至少 8 个专用物理 CPU 核心。Archive 使用 NVMe SSD;ulimit 至少 65536;Media Driver 目录放在 /dev/shm 以利用共享内存;Aeron 缓冲区使用堆外内存,避免 JVM GC 暂停,以获得可预测的微秒级延迟。
十二、商业模式
Aeron 采用开源 + Premium 双轨:开源版本为 Apache 2.0 许可,Premium 版本提供内核旁路、更高吞吐等能力,由 Adaptive Financial Consulting 商业支持。
总结:Aeron 是把消息中间件"broker 化"和"低延迟"这两条历来对立的路走通的方案——它没有中心 broker,靠共享内存 + UDP 直连 + Raft 实现了微秒级延迟的可靠传输和秒级故障切换的容错集群,是当今电子交易基础设施的事实标准之一。
除非注明，否则均为李锋镝的博客原创文章，转载必须以链接形式标明本文链接
文章评论
没看懂，有点太专业了