撮合引擎 · 2026
为什么高频撮合必须用 C++ 内存级架构？
撮合引擎是交易所的核心组件，负责将买单和卖单按照"价格优先、时间优先"的原则配对成交。它的性能直接决定了交易所的延迟、滑点和并发上限。
在万级 TPS 场景下，使用 Java 或 Go 这类带垃圾回收（GC）的语言会产生 5–200ms 的不可预测停顿，直接导致订单簿卡顿和用户滑点。这也是为什么头部交易所的撮合层普遍使用 C++ 或 Rust。
三个关键数字
- 单节点 10,000+ TPS——C++ 内存撮合的吞吐下限。Go 在同等硬件下通常只能达到 2,000–3,000 TPS。
- 微秒级清算延迟——订单簿完全驻留内存，不触碰磁盘，端到端延迟低于 1ms。
- 0 GC 停顿——预分配内存池，运行时不触发垃圾回收，避免周期性卡顿。
为什么不能用 Java 或 Go？
Java 和 Go 在业务层（用户中心、订单管理、API 网关）完全够用，但撮合层有两个硬约束：
- 确定性延迟：GC 会在任意时刻暂停线程，延迟抖动不可控，对做市商和高频用户来说是致命的。
- 内存吞吐：订单簿每秒需要处理上万次插入、删除、更新，GC 的对象扫描开销会显著降低吞吐。
结论
高并发交易所的撮合层必须使用 C++ 或 Rust，业务层可以用 Go 或 Java。这也是 Apex Engine 选择自研 C++/Go 混合架构、而不是基于开源项目魔改的根本原因——开源项目的撮合内核往往是单线程、低性能的，无法支撑万级并发。