从零构建Level 3订单簿：高频交易系统的基石

作者： /

本文面向构建低延迟、高可靠交易系统的工程师与架构师。我们将深入探讨如何处理Level 3级别的逐笔行情数据，并从零开始在内存中构建一个完整的、与交易所状态精准同步的订单簿（Order Book）。这不仅是高频交易策略的基础，也是理解市场微观结构的必经之路。我们将从数据结构的理论权衡，一路深入到网络协议、内存管理、多线程并发以及规避实际工程中的陷阱，最终呈现一个从原型到生产级别的架构演进路径。

现象与问题背景

在金融交易领域，行情数据按照信息粒度被划分为不同等级（Level）。对于绝大多数零售应用，Level 1数据，即最优买卖价（Best Bid/Offer），已经足够。它告诉你当前市场可以成交的最好价格。Level 2数据则更进一步，提供了多档位的深度信息，通常是聚合后的价格和数量，例如买一价有多少总委托量，买二价有多少总委托量。但对于高频交易（HFT）或做市商策略而言，L1和L2信息是严重不足的。

真正的战场在Level 3。Level 3数据，又称逐笔数据（Tick-by-Tick Data），是市场的最原始、最完整的记录。它包含了每一个进入市场的委托单（Add Order）、每一个撤单（Cancel Order）、每一次部分或全部成交（Trade Match）的详细信息，甚至包括订单修改（Modify Order）。这意味着，拥有L3数据，理论上我们可以在本地内存中完美复刻交易所的订单簿。这至关重要，因为它揭示了：

  • 订单的真实流动性： 你能看到是单个大单还是多个小单构成了某个价位的深度。
  • 市场参与者的行为模式： 跟踪特定订单ID的生命周期，可以用于分析“冰山订单”或某些算法交易的踪迹。
  • 最精准的延迟测量： 本地订单簿的时间戳与交易所撮合报告的时间戳之差，是衡量系统端到端延迟的黄金标准。

然而，这种信息的完备性带来了巨大的技术挑战。一个活跃的交易品种，其L3数据流可能达到每秒数万甚至数百万条消息。处理这条“数据火龙”，要求系统在极低的延迟（微秒级）下完成网络接收、数据解析、逻辑处理和订单簿更新，并保证数据的一致性和完整性。任何一个环节的瓶颈都将导致本地订单簿与交易所真实状态脱节，从而引发灾难性的交易决策。

关键原理拆解

在我们进入工程实现之前，必须回归计算机科学的基础，理解构建订单簿在理论上依赖哪些核心原理。这就像建筑师在画图纸前，必须精通材料力学和结构力学。

1. 订单簿的核心数据结构

订单簿本质上是一个按价格排序的双边队列。买单（Bid）按价格从高到低排序，卖单（Ask）按价格从低到高排序。对于同一价格水平（Price Level），订单遵循时间优先原则（FIFO）。我们需要一个数据结构，能够高效地支持以下操作：

  • 添加订单： O(log N) 或更优。
  • 删除订单： O(log N) 或更优，需要通过订单ID快速定位。
  • 修改订单： 实质上是删除旧订单，添加新订单。
  • 获取最优报价： O(1)。

从纯粹的算法角度分析，有几种经典选择：

  • 平衡二叉搜索树（如红黑树）： 这是最符合直觉的教科书式方案。我们可以用一个红黑树来管理所有的价格水平（Price Level）。树的每个节点代表一个价格，节点内部挂一个双向链表，链表中是该价格的所有订单。买单侧用一个最大树（Max-Tree），卖单侧用一个最小树（Min-Tree）。增删改查的时间复杂度都是 O(log P)，其中P是价格水平的数量。获取最优报价即取树的根节点（或最左/最右子节点），为 O(1)。
  • 哈希表 + 双向链表/堆： 这是一个在工程实践中更常见的混合方案。用一个哈希表 `map` 来存储所有订单，实现通过ID进行 O(1) 的快速查找和删除。同时，用另一个数据结构来维护价格的排序。例如，用两个堆（买单侧用最大堆，卖单侧用最小堆）来维护所有价格水平，这样获取最优报价是 O(1)。但修改非堆顶的价格水平是 O(log P)。更优化的做法是用哈希表 `map` 存储价格水平，然后用一个双向链表将这些价格水平串联起来，从而保持排序。这种结构在增删价位时需要维护链表指针，但避免了树结构的复杂平衡操作。

2. 数据传输的网络协议栈

交易所为了追求极致的广播效率和低延迟，通常使用 UDP Multicast 来广播L3行情数据。这与我们熟悉的TCP有根本不同。

  • TCP (Transmission Control Protocol): 是一个可靠的、面向连接的协议。它保证数据包按序、无丢失地到达。但这种可靠性是有代价的：三次握手、ACK确认、拥塞控制和重传机制都会引入不可预测的延迟（Jitter）。在高频场景下，一个由于网络抖动导致的TCP重传，可能意味着几百微秒甚至毫秒级的延迟，这是致命的。

    • –

  • UDP (User Datagram Protocol): 是一个不可靠的、无连接的协议。它像一个邮差，只管把数据包扔出去，不保证是否到达、何时到达、是否按序到达。这恰恰是低延迟广播所需要的——没有任何协议层面的等待和确认。

选择UDP意味着，我们必须在应用层自己处理UDP的“不可靠”特性。交易所的L3数据流中，每条消息都会带有一个连续递增的序列号（Sequence Number）。我们的应用程序必须在本地维护一个期望序列号，逐一检查收到的消息。如果 `收到的序列号 > 期望的序列号`，就意味着发生了数据包丢失（Packet Loss），即产生了一个“Gap”。此时，本地的订单簿状态已经不完整。交易所会提供一个独立的、基于TCP的重传服务（Retransmission Service），我们的系统需要立即通过该服务请求丢失的序列号区间的数据，并将本地状态恢复到一致。这个“Gap检测与恢复”机制是L3系统稳定性的命脉。

系统架构总览

一个生产级的L3订单簿构建系统，绝不是一个单一程序，而是一组分工明确、高度优化的组件构成的流水线。我们可以将其划分为以下几个核心部分：

1. 数据网关 (Market Data Gateway)
这是系统的入口，直接与交易所网络对接。它通常是一个独立的物理服务器，运行着一个或多个高度优化的C++进程。其职责包括：

  • 监听一个或多个UDP组播地址，从网卡（NIC）接收原始的UDP数据包。在极端性能要求下，会使用内核旁路（Kernel Bypass）技术如DPDK或Solarflare Onload，让应用程序直接读写网卡缓冲区，绕过操作系统的网络协议栈，将延迟从几十微秒降低到个位数微秒。
  • 进行最基础的数据包合法性校验，并提取出核心信息，如序列号和消息体。
  • 将带有元信息（如接收时间戳）的原始消息快速推送到内部消息队列（如共享内存IPC）中，供下游处理。

2. 序列化与解码引擎 (Sequencer & Decoder)
这个组件是流水线的第二站，负责将原始、无序的数据流整理成有序、可用的业务事件。

  • 定序器 (Sequencer): 从上游队列中消费数据包，根据序列号进行排序。它会维护一个小缓冲区来处理乱序包（网络中后发的包可能先到）。如果发现序列号不连续，即产生Gap，它会立即触发Gap处理逻辑，暂停向下游派发数据，并向重传服务请求数据。
  • 解码器 (Decoder): 在数据定序后，解码器将二进制的原始消息（通常是交易所私有的FIX/FAST、SBE等高效格式）解析成程序内部的结构化对象，例如 `NewOrderEvent`, `CancelEvent`, `TradeEvent`。这里的关键是零拷贝（Zero-Copy）解析，避免不必要的内存复制。

3. 订单簿核心 (Order Book Core)
这是系统的心脏。它是一个单线程或精心设计的并发模块，负责维护内存中的订单簿状态。

  • 消费解码后的业务事件。
  • 根据事件类型，对内部的订单簿数据结构执行增、删、改操作。
  • 在每次状态变更后，可以生成订单簿的快照（Snapshot），或者将变更事件（Diff）发布出去，供下游的交易策略使用。

4. 策略接口与快照服务 (Strategy API & Snapshot Service)
这是系统的出口，为交易策略提供数据。为避免读写冲突，通常采用无锁（Lock-Free）数据结构或单写多读模式（如LMAX Disruptor Ring Buffer），让策略线程可以安全、高效地读取订单簿状态，而不会阻塞核心更新线程。

核心模块设计与实现

现在，让我们像一个极客工程师一样，深入到代码层面，看看这些模块的关键实现。

订单簿数据结构实现

我们采用“哈希表 + 平衡二叉树”的混合模型。`std::map` 在C++中通常是红黑树实现，可以满足排序需求。用 `std::unordered_map` 来快速定位订单。


#include <map>
#include <list>
#include <unordered_map>
#include <cstdint>

// 极简的订单对象
struct Order {
    uint64_t order_id;
    uint32_t quantity;
    // ... other fields like trader id, etc.
};

// 代表一个价格水平，包含该价格的所有订单队列
using OrderList = std::list<Order>;
// 用 map 来维护价格排序，key 是价格，value 是订单列表
// 对于卖单侧 (asks)，用 std::less (默认) 即可，价格从低到高
// 对于买单侧 (bids)，需要用 std::greater，价格从高到低
using PriceLevels = std::map<uint64_t, OrderList, std::greater<uint64_t>>; // Bids example

class OrderBook {
public:
    void add_order(uint64_t price, const Order& order) {
        // 1. 添加到订单簿
        auto& orders_at_price = bids_[price];
        orders_at_price.push_back(order);

        // 2. 建立 order_id -> iterator 的快速索引
        // 这很关键，为了O(1)复杂度的删除
        order_map_[order.order_id] = {price, std::prev(orders_at_price.end())};
    }

    void cancel_order(uint64_t order_id) {
        auto it = order_map_.find(order_id);
        if (it == order_map_.end()) {
            // 订单不存在，可能已经被撮合或已撤销
            return;
        }

        auto& location = it->second;
        uint64_t price = location.price;
        auto order_it = location.iterator;

        // 1. 从价格水平的链表中删除
        bids_[price].erase(order_it);
        // 如果该价格水平空了，从 map 中移除，避免内存膨胀
        if (bids_[price].empty()) {
            bids_.erase(price);
        }

        // 2. 从快速索引中删除
        order_map_.erase(it);
    }
    
    // ... 其他方法，如获取最优报价等

private:
    struct OrderLocation {
        uint64_t price;
        OrderList::iterator iterator;
    };
    
    PriceLevels bids_; // 买单侧
    // PriceLevels asks_; // 卖单侧，用 std::less

    // 核心优化：order_id 到订单在链表中位置的直接映射
    std::unordered_map<uint64_t, OrderLocation> order_map_;
};

工程坑点： 上面的 `std::map` 和 `std::list` 在每次操作时都可能涉及堆内存分配，在高频场景下会造成性能抖动。真正的HFT系统会使用自定义的内存池/对象池（Memory Pool / Object Pool）。在启动时预分配一大块连续内存，之后所有 `Order` 和 `OrderList` 节点的创建和销毁都只是在这个内存池里移动指针，完全避免了与操作系统内核的昂贵 `malloc/free` 调用交互。

Gap检测与恢复逻辑

这是保证数据一致性的核心逻辑。伪代码如下：


var expectedSeqNum uint64 = 0
var messageBuffer = make(map[uint64]Message) // 缓存乱序消息

func processMessage(msg Message) {
    if expectedSeqNum == 0 { // 第一次收到消息
        expectedSeqNum = msg.SeqNum + 1
        applyToOrderBook(msg)
        return
    }

    if msg.SeqNum == expectedSeqNum {
        // 序列号正确，直接处理
        applyToOrderBook(msg)
        expectedSeqNum++
        
        // 检查缓冲区中是否有可以连续处理的消息
        for {
            bufferedMsg, found := messageBuffer[expectedSeqNum]
            if !found {
                break // 没有连续的消息了
            }
            applyToOrderBook(bufferedMsg)
            delete(messageBuffer, expectedSeqNum)
            expectedSeqNum++
        }
    } else if msg.SeqNum > expectedSeqNum {
        // 发现Gap！
        fmt.Printf("GAP detected! Expected %d, got %d\n", expectedSeqNum, msg.SeqNum)
        messageBuffer[msg.SeqNum] = msg // 缓存当前消息
        
        // **关键动作**: 立即向TCP重传服务请求 [expectedSeqNum, msg.SeqNum - 1] 的数据
        requestRetransmission(expectedSeqNum, msg.SeqNum - 1)
        
        // 此时，必须将订单簿标记为“Stale”(不新鲜)状态，所有交易策略暂停
        markOrderBookAsStale()
    } else {
        // msg.SeqNum < expectedSeqNum: 迟到的重复包，直接丢弃
    }
}

func onRetransmissionDataReceived(recoveredMsgs []Message) {
    // 处理恢复的数据...
    for _, msg := range recoveredMsgs {
        if msg.SeqNum >= expectedSeqNum {
            applyToOrderBook(msg)
            expectedSeqNum = msg.SeqNum + 1
        }
    }
    // 恢复完成后，检查缓冲区，然后将订单簿标记为“Live”
    markOrderBookAsLive()
}

工程坑点： Gap恢复逻辑远比这复杂。如果重传过程中又收到了新的UDP数据怎么办？如果重传通道本身也慢怎么办？生产系统需要一个复杂的状态机来管理 `Live`、`Stale`、`Recovering` 等多种状态。此外，对缓冲区的管理必须有大小和时间限制，不能无限期等待，否则内存会被打爆。通常设定一个超时，若Gap在规定时间内（如几百毫秒）无法恢复，系统可能需要从交易所获取一个完整的订单簿快照（Snapshot）来重建，这是一个更重的操作。

性能优化与高可用设计

构建这样一个系统，性能和稳定性是同等重要的。

性能优化（对抗延迟）:

  • CPU亲和性 (CPU Affinity): 这是HFT的标配。将不同的处理线程绑定到独立的、隔离的CPU核心上。例如，核心0处理网卡中断，核心1处理序列化和解码，核心2处理订单簿更新。通过 `isolcpus` 内核参数将这些核心从通用调度中隔离出来，确保你的关键线程不会被操作系统任意迁移，从而消除上下文切换带来的延迟抖动。
  • 缓存友好 (Cache-Friendly) 的数据结构: CPU从L1/L2 Cache读取数据的速度比从主内存快几个数量级。使用数组、或内存池中连续分配的对象，远比在堆上零散分配、通过指针跳转的树或链表要快，因为前者能更好地利用CPU的预取机制和缓存行。这就是所谓的“机械共鸣”（Mechanical Sympathy）。
  • 无锁编程 (Lock-Free Programming): 在多线程间传递数据时，锁是性能杀手。使用无锁数据结构，如LMAX Disruptor Ring Buffer，可以让单个写入线程（订单簿更新）和多个读取线程（交易策略）并发工作，而无需任何锁或原子操作，实现极高的吞吐量和低延迟。

高可用设计（对抗故障）:

  • A/B双路热备: 交易所通常会提供A/B两条完全冗余的数据线路。你的系统应该同时从两条线路接收数据，并在序列化层进行仲裁，取先到的那个有效序列号。如果一条线路中断或出现大量丢包，可以无缝切换到另一条。
  • 主备机热备: 部署两台完全相同的机器，同时运行上述整套系统，构建各自的订单簿。它们是主备（Active-Passive）关系。主服务器对外提供服务。两台机器间通过心跳检测保持联系。一旦主服务器宕机（进程崩溃、硬件故障），备用服务器可以立即接管。
  • 状态校验: 如何确保主备服务器的订单簿状态完全一致？可以在特定序列号或时间点，对订单簿状态计算一个校验和（Checksum）。主备机之间交换校验和，如果不一致，则说明状态发生偏离，需要触发报警和恢复流程。

架构演进与落地路径

罗马不是一天建成的。一个微秒级的HFT系统也不可能一蹴而就。正确的路径是分阶段演进。

第一阶段：功能验证原型 (Proof of Concept)

  • 目标： 验证业务逻辑的正确性。
  • 技术选型： 使用高级语言（如Java/Go），标准库数据结构，连接交易所的TCP行情数据源。这个阶段完全不考虑性能，重点是把订单簿的增删改逻辑、成交匹配逻辑做对。延迟可能在毫秒级。

第二阶段：生产级低延迟系统 (Production-Ready)

  • 目标： 延迟进入亚毫秒级别，系统稳定可靠。
  • 技术选型： 切换到C++，引入UDP组播数据源，实现完整的Gap检测与恢复逻辑。采用多线程流水线架构，进行初步的性能优化，如使用更高效的数据结构，但可能还未使用内核旁路等终极手段。实现A/B双路数据和主备热备，保证高可用。

第三阶段：极致性能HFT系统 (Ultra-Low Latency)

  • 目标： 延迟压榨到微秒级。
  • 技术选型： 在第二阶段基础上，引入内核旁路（DPDK/Onload）。使用自定义内存管理，实现全链路零拷贝。进行CPU核心绑定和内核参数调优。对最热点的代码路径（如消息解码），可能使用SIMD指令进行汇编级别的优化。在终极阶段，甚至会将解码、过滤等逻辑固化到FPGA硬件上。

通过这样的演进路径，团队可以在每个阶段都有明确的目标和可交付的成果，逐步构建起对系统复杂度的掌控能力，最终打造出能够在瞬息万变的金融市场中立于不败之地的核心基础设施。

延伸阅读与相关资源

  • 想系统性规划股票、期货、外汇或数字币等多资产的交易系统建设，可以参考我们的
    交易系统整体解决方案。
  • 如果你正在评估撮合引擎、风控系统、清结算、账户体系等模块的落地方式，可以浏览
    产品与服务
    中关于交易系统搭建与定制开发的介绍。
  • 需要针对现有架构做评估、重构或从零规划，可以通过
    联系我们
    和架构顾问沟通细节，获取定制化的技术方案建议。
滚动至顶部