交易所撮合引擎性能优化：从50万TPS到100万TPS的实战经验

关注

原创最新推荐文章于 2026-08-24 17:15:09 发布 689 阅读 AI 写同款· GEO 优化 ›

数字货币交易所系列（二）：CEX 核心技术架构——撮合引擎、钱包系统与充提链路的深度拆解 CEX 的技术架构，本质上是在解决一个矛盾三角性能/ \/ \安全 ──── 一致性性能：撮合引擎要快到微秒级，行情推送不能有延迟安全：管着几十亿美元的资产，密钥管理不能有丝毫差错一致性：每一分钱都不能算错，清结算必须精确到小数点后 8 位在这三者之间取得平衡，就是 CEX 技术团队每天在做的事情。但技术架构只是防线的一半。另一半是——风控系统如何检测异常？安全事件发生时如何应对？监管框架如何约束交易所行为？这些问题，我们下一篇来拆解。下一篇。阅读详情

交易所撮合引擎性能优化：从50万TPS到100万TPS的实战经验

在数字资产交易的世界里，性能不是锦上添花，而是生死存亡的底线。当市场行情剧烈波动时，一个延迟毫秒的订单处理，可能意味着用户错失良机，平台流失客户。我们团队曾负责一个核心撮合引擎的迭代，目标明确而艰巨：将系统的吞吐量从稳定的50万笔交易每秒（TPS）提升至100万TPS。这不仅仅是数字的翻倍，更是对架构、算法和工程细节的极限挑战。这篇文章，我将抛开教科书式的理论，聚焦于我们踩过的坑、验证过的策略以及最终带来实质性提升的那些关键改动。无论你是正在设计新系统的架构师，还是致力于优化现有系统的工程师，希望这些从实战中萃取的思路能给你带来启发。

1. 性能瓶颈的深度诊断与量化分析

在动手优化之前，盲目地堆砌技术选型往往事倍功半。我们的第一步是建立一个全方位的性能观测体系，精准定位瓶颈所在。50万TPS的系统，其瓶颈可能隐藏在任何一个意想不到的角落。

我们构建了一个分层的监控仪表盘，核心关注以下几个维度的指标：

端到端延迟分布：不仅仅是平均延迟，更重要的是P99、P999（即99%和99.9%的请求延迟）的延迟情况。在高并发下，长尾延迟对用户体验的伤害是致命的。
系统资源饱和度：CPU使用率、内存带宽、各级缓存（L1/L2/L3）命中率、网络I/O、磁盘I/O（如果涉及）。我们发现，在达到50万TPS时，CPU使用率看似未达100%，但perf工具显示指令周期停滞（stall）率很高，暗示内存访问可能是瓶颈。
内部队列深度：从网络接收到订单，到进入撮合逻辑，中间可能经过多个内部队列。队列长度的激增是背压（backpressure）和延迟的直接信号。
垃圾回收（GC）影响：对于JVM系语言，GC的“世界暂停”（Stop-The-World）是吞吐量和延迟的隐形杀手。我们记录了每次Full GC的持续时间和频率。

通过一段时间的压力测试和数据采集，我们绘制出了系统的“热点图”。一个关键的发现是：超过60%的CPU时间花在了订单簿的查询和更新操作上，而订单簿底层使用的是一种通用的、线程安全的有序容器。这成为了我们首要的攻坚目标。

提示：性能优化必须数据驱动。在没有量化证据的情况下，凭直觉进行的“优化”很可能是无效的，甚至会导致性能回退。建立一个可持续的性能测试基准（Benchmark）环境至关重要。

2. 核心数据结构：为订单簿量身打造高性能引擎

订单簿是撮合引擎的心脏，它的数据结构直接决定了匹配效率。我们之前使用的现成数据结构虽然功能完备，但在极致性能场景下显得笨重。我们的目标是设计一个读多写少、高度并发、内存局部性友好的专用订单簿。

2.1 抛弃通用容器，设计锁无关（Lock-Free）订单簿

通用平衡树（如红黑树）或跳表（Skip List）保证了操作的O(log N)复杂度，但在高并发修改时，锁竞争或CAS重试开销巨大。我们借鉴了金融交易系统的常见实践，为买卖盘分别设计了基于价格档次（Price Level） 的专用结构。

核心思想是：市场报价的价格是离散的（有最小变动单位，如0.01美元）。我们将所有可能的报价预先划分为一系列“档次”。每个档次对应一个价格，并维护一个该价格下的订单队列（按时间优先排序）。这样，查询最优买一/卖一价变成了直接访问两个边界档次，复杂度是O(1)。

// 简化概念示例 (C++风格伪代码)
class LockFreeOrderBook {
private:
    // 一个价格档次
    struct PriceLevel {
        std::atomic<int64_t> total_volume; // 该价位总挂单量
        // 使用无锁链表管理该价位下的订单
        LockFreeQueue<Order*> orders;
    };

    // 使用数组或稀疏哈希表映射价格 -> PriceLevel
    // 例如，价格 100.00 对应索引 10000
    std::vector<PriceLevel> buy_levels;
    std::vector<PriceLevel> sell_levels;

    // 当前最优买价和卖价的索引
    std::atomic<size_t> best_bid_index;
    std::atomic<size_t> best_ask_index;
public:
    // 插入订单：找到对应PriceLevel，无锁插入其队列，原子更新total_volume
    bool add_order(const Order& order);

    // 获取买卖一档：直接通过原子索引读取
    PriceLevel get_best_bid() const;
    PriceLevel get_best_ask() const;
};

这种设计的优势在于：

极致的读性能：获取市场深度、最优报价都是直接内存访问。
写操作局部化：新增或取消订单，大部分时候只在一个特定的PriceLevel内部进行无锁队列操作，极大地减少了竞争域。
内存友好：数据在内存中连续或按块存储，提高了CPU缓存命中率。

2.2 订单匹配算法的微优化

匹配逻辑（Matching Logic）是撮合引擎的算法核心。即使数据结构优化了，匹配循环内的细微效率差别，在每秒百万次调用下也会被放大。

我们重写了匹配循环，重点关注：

减少分支预测失败：将条件判断重构，使得最可能发生的路径（如部分成交）代码连续。
批量状态更新：在一次匹配事件中可能涉及多个订单状态的更新（完全成交、部分成交、撤单等）。我们不再每处理一个订单就对外发布一次事件，而是将其暂存在一个线程本地缓冲区（Thread-Local Buffer），待本次撮合周期结束后批量发布。这显著降低了事件总线的压力和对下游系统的冲击。
使用原生类型和位操作：对于订单状态、类型等枚举，使用uint8_t或位域（bit-field）表示，并在匹配逻辑中使用位运算进行快速检查。

3. 并发架构：从粗粒度锁到精细化并行

当单个订单簿的性能挖掘到一定程度后，横向扩展成为必由之路。我们的策略是分区（Sharding）。

3.1 按交易对分区并行撮合

最自然的分区维度是按交易对（如BTC/USDT, ETH/USDT）。不同的交易对之间没有撮合关系，完全独立。因此，我们可以将每个交易对的订单簿分配给一个独立的工作线程或协程，甚至部署在独立的物理核心上。

架构模式	描述	优点	挑战
单线程单引擎	所有交易对共用一个撮合线程。	实现简单，全局状态一致。	性能瓶颈明显，无法利用多核。
多线程单引擎（粗锁）	一个引擎，多线程通过全局锁操作订单簿。	相对简单。	锁竞争激烈，扩展性差。
单线程多引擎	每个交易对一个独立引擎实例，绑定一个线程。	无锁竞争，性能线性扩展。	线程资源管理、负载均衡。
协程多引擎	每个引擎实例由一个协程处理，由少量线程调度。	资源利用率高，上下文切换开销小。	需要语言/框架支持（如Go goroutine）。

我们采用了“单线程多引擎”模式。每个交易对的撮合线程独占一个CPU核心，并绑定（pinning）在该核心上运行，避免缓存失效和上下文切换的开销。线程间通过无锁的环形缓冲区（Ring Buffer）或类似Disruptor的机制接收新订单。

3.2 订单输入与结果输出的异步化

输入输出（I/O）绝不能阻塞核心的撮合循环。我们设计了完全异步的流水线：

网络层：使用epoll/kqueue或io_uring接收订单请求，解析后根据交易对ID，投递到对应交易对引擎的专属输入队列。
撮合层：每个引擎线程循环地从自己的输入队列取订单，执行撮合，生成成交结果和订单状态更新。
输出层：引擎将结果投递到一个全局的输出队列。由一组独立的I/O线程负责从输出队列取出结果，组播（Multicast）给行情推送服务、数据库、风控系统等下游消费者。

这种生产-消费者模型解耦了各环节，使得每个部分都能按照自己的节奏处理，系统整体吞吐量取决于最慢的环节，而不再是相互阻塞。

4. 内存管理与网络通信的极致优化

当CPU和并发架构的潜力被挖掘后，内存和网络这两个子系统往往成为新的瓶颈。

4.1 定制化内存分配与对象池

频繁的订单对象创建和销毁会导致大量的内存分配（malloc/new）和垃圾回收。我们的优化措施包括：

预分配对象池：在系统启动时，预先分配一大块内存，并切割成固定大小的订单对象。使用时从池中取，用完后归还，避免系统级内存分配器的开销。
缓存行对齐：现代CPU以缓存行（通常64字节）为单位读写内存。如果两个高度竞争的原子变量位于同一个缓存行，会导致严重的“伪共享”（False Sharing）问题，即一个CPU核心更新变量会无效化另一个核心的缓存。我们使用编译器指令（如C++的 alignas(64)）将关键变量隔离到不同的缓存行。

// 避免伪共享的例子
struct alignas(64) PaddedCounter { // 保证整个结构体独占一个缓存行
    std::atomic<int64_t> value;
    char padding[64 - sizeof(std::atomic<int64_t>)];
};

PaddedCounter global_counter_a;
PaddedCounter global_counter_b; // a和b不会共享缓存行

4.2 应用层协议与序列化优化

网络协议方面，我们放弃了JSON等文本协议，采用了二进制的自定义协议。

协议设计：消息头定长，包含消息类型、长度、交易对ID等。消息体紧凑排列字段。一个新增订单的消息可能被压缩到几十个字节。
序列化：使用FlatBuffers或Cap'n Proto这类零拷贝（Zero-copy）序列化库。它们在序列化时不需要打包/解包，可以直接在原始缓冲区上读取结构化数据，极大地减少了CPU开销和内存分配。
网络包处理：启用TCP_NODELAY禁用Nagle算法，减少小包延迟。对于行情推送这种一对多的场景，采用UDP组播替代TCP，进一步降低延迟和服务器负载。

5. 实战案例：一次完整的性能压测与调优迭代

理论最终需要实践验证。我分享一次针对“大宗订单处理导致延迟毛刺”问题的调优全过程。

问题现象：在持续80万TPS的压力下，系统P99延迟稳定在1毫秒以内，但每分钟会出现几次持续约50毫秒的延迟尖峰。

排查过程：

监控关联：发现延迟尖峰出现时，GC日志显示发生了“年轻代GC”（Young GC），但耗时正常（<10ms），并非主要原因。
性能剖析：使用async-profiler对尖峰时段进行on-CPU采样。发现热点不在撮合逻辑，而在输出事件序列化模块。
深入分析：大宗订单成交会瞬间产生大量成交记录（Trade）。这些记录需要在输出线程中被序列化为二进制格式。原来的序列化代码为每条成交记录单独分配了一个临时缓冲区，导致在尖峰时刻大量、密集的内存分配，触发了操作系统的内存管理瓶颈和CPU缓存抖动。

解决方案：我们修改了输出模块的序列化逻辑，为每个输出线程预分配一个大的、可重用的缓冲区。在需要序列化一批成交记录时，直接向这个缓冲区的空闲位置追加写入，仅在一次网络发送时，才将整个大缓冲区提交给网络栈。

// 优化前：每条记录单独序列化并发送
for (Trade trade : tradeList) {
    byte[] serialized = serializer.serialize(trade); // 每次分配新数组
    networkChannel.send(serialized);
}

// 优化后：批量序列化到复用缓冲区
ThreadLocal<ByteBuffer> reusableBuffer = ...;
ByteBuffer buffer = reusableBuffer.get();
buffer.clear();
for (Trade trade : tradeList) {
    serializer.serializeTo(trade, buffer); // 写入到buffer的当前位置
}
networkChannel.send(buffer.flip()); // 一次性发送

效果：经过这一改动，延迟毛刺完全消失，系统P999延迟降低了70%，并且平稳支撑住了100万TPS的长期压力测试。

性能优化是一场永无止境的旅程，从50万TPS到100万TPS，我们走过的路证明，巨大的提升并非来自某个“银弹”，而是源于对系统每一层、每一处细节的深刻理解与精心打磨。它要求我们既是宏观架构的设计师，又是微观指令的雕刻师。当你觉得优化无从下手时，不妨回到起点：拿出性能剖析工具，找到最热的那行代码，然后问自己，我们能否为这个特定场景做得更少、更快、更直接？