亚毫秒级订单撮合解析

1. 起点

我们在 2022 年上线的撮合引擎是教科书式实现:用单线程事件循环对以嵌套 B-tree map 表示的价格-时间优先订单簿处理订单。从订单接收到执行报告的中位时延约为 4.2 ms,p99 约 11 ms。对零售流量来说还行,对任何试图做市的人来说则相当尴尬。

2. 时延预算

撮合本身很便宜 — 对热订单簿的典型订单只需 50–200 纳秒。剩下的 4 ms 分布在:内核网络栈、JSON 解析、校验、账目写入、复制以及报告。我们在负载下测量了每一段,发现最昂贵的部分是校验(~1.4 ms,30 多次白名单查询)和账目写入(~1.7 ms,需写入 Postgres)。

3. 我们做了哪些改变

校验改为一次写入快照

白名单、费率层级和按账户的限额过去是针对 Postgres 的缓存未命中。我们在每次变更时将它们快照到带 16 字节版本头的内存映射页中。撮合循环以无锁方式读取;更新原子地切换快照。校验时延降至约 80 µs。

账目改为日志方式

我们不在热路径上将成交直接写入 Postgres,而是把事件追加到按分片的环形缓冲并 ack 订单。一个独立的日志器在 5 ms 内做持久化 — 足以满足我们的一致性故事,而不会阻塞撮合。热路径上的账目时延降至约 30 µs。

网络栈:io_uring + 零拷贝

我们将订单入口从基于 epoll 的阻塞 I/O 迁移到带批量提交的 io_uring — 仅此一项就削减了约 400 µs 的系统调用开销。在网络入口侧,XDP 程序将热门交易对的数据包直接导入撮合引擎队列,无需穿越内核网络栈的其余部分,再节省约 300 µs。合计:往返时延减少约 700 µs。

4. 我们没有改变的部分

订单簿数据结构保持不变。价格-时间优先语义保持不变。执行报告格式保持不变。所有变更都发生在边缘 — 校验快照、异步日志器、网络栈。实际撮合代码没有任何变动。这让我们能够按分片逐步推出变更,并进行 bit-for-bit 的回放对比。

5. Results

• 中位时延: 4.2 ms → 580 µs (7×)
• p99 latency: 11 ms → 1.4 ms (8×)
• 每分片吞吐: 18,000 ops/s → 92,000 ops/s
• 账目持久性:同步 → 5 毫秒内异步(我们明确公开 SLA)

做市商在一周内注意到了变化。随着库存周转率跟上新的成交率,主流币种的价差收窄了 6–18 个基点。

6. 我们接下来要做的事

下一个瓶颈是复制 — 我们在三个区域间运行两阶段提交,跨区域确认现在是系统中最长的一跳。我们正在原型一个 Raft 变体,使撮合分片可在单区域多数派下完成订单,并异步复制,同时对故障切换时保留的内容设置明确的不变式。上线后会有跟进文章。