撮合引擎（Matching Engine）是交易所的心脏：从证券、期货、期权到加密货币 CEX，每一笔成交价格的形成都发生在一段不超过几十微秒的代码里。它是一个看似简单、实则对工程师心智负担极重的子系统——数据结构只有一个”订单簿（Order Book）“，算法只有一个”价格时间优先（Price-Time Priority）“，但围绕它的所有周边：确定性回放、主备一致性、订单类型组合爆炸、自成交预防、集合竞价、分片与 Gateway 协同，构成了现代交易所工程师最难啃的一块骨头。
上一篇《交易所核心系统架构》里我们把撮合引擎当作一个黑盒放在图中央。本文打开这个黑盒：订单是怎么进入的？订单簿是怎么存的？匹配是怎么发生的？为什么几乎所有主流交易所都选择”单线程、无锁、按 symbol 分片”这条路？为什么说”撮合必须是确定性的”，这一句话同时决定了数据结构选型、随机数使用、时间戳来源、甚至日志格式？
本文面向两类读者：一类是想自己写一个玩具撮合引擎、理解 Nasdaq ITCH/OUCH 协议背后机制的工程师；一类是正在交易所、券商、或加密所工作，需要对撮合引擎的性能瓶颈、升级路径、灾备切换做技术判断的架构师。我们会从数据结构讲到 LMAX Disruptor，再到 Rust/Go 的可运行示例，最后给出一份”撮合引擎代码审查清单”。
中央限价订单簿（Central Limit Order Book，CLOB）是所有主流交易所撮合引擎的底层模型。它由两侧组成：
每一侧在同一价格上会有多笔订单，按到达时间先后排队，形成价格层（Price Level）内的 FIFO 队列。最优买价（Best Bid）和最优卖价（Best Ask）之间的差额叫买卖价差（Spread），它是流动性的最直接度量。
ASK (卖方, 升序)
┌─────────────────────────┐
100.05 │ O7(200) O8(150) │ 350
100.04 │ O5(100) │ 100
100.03 │ O3(500) O4(300) O6(200) │ 1000 ← Best Ask
├─────────────────────────┤
─── SPREAD 0.01 ────┤
├─────────────────────────┤
100.02 │ O1(300) O2(400) │ 700 ← Best Bid
100.01 │ O9(600) │ 600
100.00 │ O10(1000) │ 1000
└─────────────────────────┘
BID (买方, 降序)当新订单到达并且可成交时（买单价格 ≥ 最优卖价，或卖单价格 ≤ 最优买价），撮合发生；否则订单被加入到相应价格层的队尾。
撮合引擎对订单簿的核心操作只有四个：
| 操作 | 频率 | 目标复杂度 |
|---|---|---|
| 查询最优价（Best Bid / Best Ask） | 极高 | O(1) |
| 插入新订单 | 高 | O(log N) 或 O(1) |
| 撤单（按 order_id） | 高 | O(1) |
| 弹出最优价层的队头订单 | 中 | O(1) |
满足这组需求的典型实现有三种：
平衡树（红黑树 / AVL）+ 哈希索引
最常见的做法。用
std::map<Price, PriceLevel>（C++）或
BTreeMap<Price, PriceLevel>（Rust）按价格排序存储价格层，每个价格层内部是一个双向链表实现的
FIFO 队列。再维护一个
HashMap<OrderId, ListNode*> 用于 O(1)
定位到节点实现快速撤单。
跳表（Skip List）
Redis ZSET
的做法，与平衡树复杂度相同，但实现更简单、插入删除的常数因子略低，易于做
lock-free 变种。一些 Go 实现（如
goex/go-exchange 的早期版本）使用跳表。
定点价格梯（Fixed-Tick Price Ladder）
当价格精度是固定档位（tick size，如股票 0.01 元、期货 0.5
点）且波动范围有界时，可以用一个数组直接存储所有价格层，下标
= (price - min_price) / tick_size。
best_bid_idx
指针，O(1)CME Globex、Nasdaq INET、以及多数追求极致低延迟的撮合引擎都采用数组价格梯。Jane Street 有一篇著名博客描述了它如何用数组（而非红黑树）把撮合延迟压到 3 微秒以内。对于加密货币撮合（价格波动大、tick size 可能变化），仍以红黑树 / 跳表为主。
价格层内部始终是 FIFO 队列（对价格时间优先规则而言）。但它不仅要支持队尾入队、队头出队，还要支持中间删除（撤单）。因此典型实现是双向链表 + HashMap 索引：
PriceLevel {
price: i64
qty: u64 // 该价格层总量（O(1) 查询用）
head: OrderNode*
tail: OrderNode*
}
OrderNode {
order_id, account_id, qty, ts_ns
prev, next
}
Index: HashMap<OrderId, OrderNode*>这样插入、撤单、队头出队都是 O(1)。唯一的 O(log N) 操作是新建 / 删除价格层时对树的操作。
冰山订单（Iceberg） 在订单簿中只暴露一部分显示量（Visible Qty / Peak），剩余为隐藏量（Hidden Qty / Reserve）。实现上，每次显示量被吃掉，引擎自动从隐藏量”补货”，但补货后的新切片会在队尾重新排队（因为时间优先要求：后来的量不能优先于同价位的其他订单）。
Iceberg Order: display=100, reserve=900
┌──────────────────────────────────┐
│ PriceLevel 100.03 queue: │
│ A(300) B(100-visible) C(200) │ ← B 是冰山，显示 100
└──────────────────────────────────┘
↓ B 被吃掉 100
┌──────────────────────────────────┐
│ A(300) C(200) B'(100-visible) │ ← 补货后 B' 重新排队尾
│ (B reserve: 800) │
└──────────────────────────────────┘隐藏单（Hidden Order / Iceberg with display=0） 则完全不出现在公开行情中，但在成交时仍然按价格 / 时间优先参与撮合，且通常让利于显示单（见 1.5）。
订单簿对外输出的行情有三种深度：
L3 信息是撮合引擎内部状态的最完整对外投影，但只给做市商、专业交易者；普通用户看到的是 L2 或 L1。详见下一篇《行情分发》。
绝大多数现货、股票、加密交易所采用价格时间优先：
伪代码：
function match(incoming_order):
while incoming_order.qty > 0:
best_level = opposite_book.top()
if best_level is None: break
if not crosses(incoming_order.price, best_level.price): break
maker_order = best_level.head
trade_qty = min(incoming_order.qty, maker_order.qty)
emit_trade(incoming_order, maker_order, best_level.price, trade_qty)
maker_order.qty -= trade_qty
incoming_order.qty -= trade_qty
if maker_order.qty == 0:
best_level.pop_head()
if best_level.empty(): opposite_book.remove(best_level)
if incoming_order.qty > 0 and incoming_order.type == LIMIT:
same_book.insert(incoming_order)成交价取 maker（被动方） 的挂单价格，而非 taker（主动方）的价格——这是”价格改进（Price Improvement）“的来源，也是和”询价 / RFQ”模式的本质区别。
在某些高度集中、买卖价差经常为一个 tick 的市场（如 CME 某些短期利率期货、欧洲 Bund），价格时间优先会导致”谁快谁通吃”、做市商过度拥堵。Pro-Rata 规则把到来的订单量按比例分配给同一价格层的所有挂单：
PriceLevel 100.03 (total 1000):
A(600), B(300), C(100)
Incoming SELL 500 @ 100.03:
A 分得 500 * 600/1000 = 300
B 分得 500 * 300/1000 = 150
C 分得 500 * 100/1000 = 50Pro-Rata 鼓励挂大单，但引入了另一个问题：大单可能被故意挂出去再撤单（Spoofing 嫌疑），因此监管对 Pro-Rata 市场的 Layering/Spoofing 监控更严。
为了缓解”大单垄断”，很多期货市场采用混合规则：
CME Globex 针对不同合约有多种匹配算法：FIFO、Allocation、Pro-Rata、Threshold Pro-Rata、Configurable TPRO、LMM（Lead Market Maker）Allocation。每个合约在上市前就固定，不允许随意切换。
连续竞价（Continuous Trading）之外，交易所在开盘、收盘（以及某些情况的临时停复牌）会进行集合竞价：接受订单但不立即撮合，在某个时间点以一个统一价格一次性成交最大量。
集合竞价定价算法通常遵循最大成交量 → 最小未匹配量 → 参考价附近三优先原则：
flowchart TD
A[订单持续进入集合竞价簿] --> B[T-1s 停止接单]
B --> C[计算每个候选价的可成交量]
C --> D{是否存在唯一最大量价格?}
D -- 是 --> E[该价即开盘价]
D -- 否 --> F[选剩余量最小的]
F --> G{仍有并列?}
G -- 是 --> H[取最接近参考价的]
G -- 否 --> E
E --> I[以开盘价统一成交 按价格时间优先分配]
I --> J[进入连续竞价]上交所、深交所开盘集合竞价 9:15–9:25（其中 9:20–9:25 不允许撤单），收盘集合竞价 14:57–15:00。港交所、欧交所、Nasdaq 都有自己的集合竞价窗口。
同一交易账户（或关联账户组）的买卖单在订单簿中相遇时，按法规和交易所规则不应成交（会被视为 wash trade，操纵市场嫌疑）。STP 策略常见有：
| 策略 | 处理方式 |
|---|---|
| Cancel Taker (CT) | 撤销主动方新单 |
| Cancel Maker (CM) | 撤销被动方旧单 |
| Cancel Both (CB) | 双方全撤 |
| Decrement Both (DB) | 按较小量同时减少；若一方归零则撤，另一方保留剩余 |
实现上，在匹配循环检测到
incoming.account_group == maker.account_group
时分叉走 STP 分支。注意：STP
会影响价格发现（被迫跳过一些挂单），所以通常只针对同一账号、或同一账号组（如
master-subaccount 关系），不跨账户。
Binance、Bybit 公开 API 中 STP
模式是下单参数之一：selfTradePreventionMode=EXPIRE_TAKER|EXPIRE_MAKER|EXPIRE_BOTH|NONE。Coinbase
默认 Decrement and Cancel。
订单类型是撮合引擎复杂度的主要来源。下表概括最常见的订单类型及其在引擎内部的实现要点：
| 类型 | 含义 | 实现要点 |
|---|---|---|
| Limit (GTC) | 限价单，Good-Till-Cancel | 撮合剩余部分挂入订单簿 |
| Market | 市价单 | 按对手方价格逐档吃，直到填满或对手方空；剩余直接拒绝（A 股）或按最差价保护拒绝（美股 NBBO 保护） |
| IOC | Immediate-or-Cancel | 可成交部分立即成交，剩余撤销 |
| FOK | Fill-or-Kill | 如不能全部立即成交则全部撤销 |
| GTD | Good-Till-Date | 带过期时间的 GTC；引擎或定时任务在到期时自动撤销 |
| Post-Only / Maker-Only | 只允许做 maker | 如果会立即成交则撤销（不当 taker） |
| Stop / Stop-Limit | 触发式 | 价格触发条件满足后转为 Market / Limit 单进入撮合 |
| Iceberg | 冰山 | 显示量 + 隐藏量，显示量吃完从隐藏量补货并重排 |
| Hidden / Dark | 隐藏单 | 不出现在公开行情；通常成交优先级低于显示单 |
| Peg | 钉盘单 | 价格跟随最优买 / 卖价自动调整 |
| MOC / LOC | Market/Limit-on-Close | 仅参与收盘集合竞价 |
Stop 单不进入订单簿，而是进入一个独立的”待触发单”结构，按触发价索引（再按 symbol 分片）。撮合引擎每次成交后，拿最新成交价去该结构里找”触发价被穿过”的 Stop 单，把它们转为 Limit/Market 注入主撮合循环。
关键约定：Stop 单的触发与进入撮合之间必须是同一个事件循环内的连续步骤，否则会被抢跑。这也是为什么几乎所有撮合引擎都坚持单线程（见第六章）。
FOK 要求”要么全部立即成交，要么全部撤销”。实现上先预扫描订单簿对手侧，计算若以该价格吃进所有可成交单，累计量是否 ≥ 订单量。若是，正式进入匹配循环；若否，直接拒绝。预扫描不得修改簿状态。
GTD / GTC with expiry 需要一个过期清理线程或时间轮，到期后把订单从簿中撤出。清理本身必须通过撮合主循环的消息队列（而非直接修改簿），以保持事件顺序的确定性。
“确定性（Deterministic）”指：给定相同的初始状态和相同的输入序列，撮合引擎必须产生逐字节相同的输出（成交记录、订单簿快照、行情事件）。这是以下能力的前提：
任何违反确定性的代码（如
time.Now()、rand.Intn()、goroutine
调度、HashMap
遍历顺序）都必须被输入化——即把不确定来源变成输入事件的一部分。
撮合引擎使用的时间戳必须来自输入事件（Gateway
打上的 ingress 时间），而不是引擎内部
time.Now()。这样，备机重放时间戳来自同一条输入流。
# 错误做法
func onOrder(order *Order) {
order.AcceptedAt = time.Now() // 非确定性
book.Add(order)
}
# 正确做法
type Input struct {
SeqNo uint64
IngressTs int64 // Gateway 打上，随 WAL 持久化
Payload Order
}
func onInput(in *Input) {
in.Payload.AcceptedAt = in.IngressTs
book.Add(&in.Payload)
}所有进入撮合的请求（下单、撤单、改单、定时触发、行情快照请求……）被 Gateway 层统一编号成一个单调递增的输入序列，以该序列为 WAL 写入顺序、也是撮合处理顺序。输出事件（Trade、Ack、Reject、BookUpdate）同样带连续 seq，供下游消费与回放对齐。
Input WAL:
seq=1001 ts=... NEW_ORDER order_id=A qty=100 px=10.03
seq=1002 ts=... NEW_ORDER order_id=B qty=50 px=10.03
seq=1003 ts=... CANCEL order_id=A
seq=1004 ts=... NEW_ORDER order_id=C qty=200 px=10.04 ← 触发撮合
Output WAL:
seq=2001 ref=1004 TRADE taker=C maker=B qty=50 px=10.03
seq=2002 ref=1004 ACK order_id=C remaining=150
seq=2003 ref=1004 BOOK level=10.04 +150如果业务确实需要随机（如 Pro-Rata
中有零头时的分配），从输入事件里带入种子，或用
hash(seq_no)
作为确定性随机源。严禁使用
/dev/urandom 或系统 RNG。
撮合引擎核心一律单线程（见第六章），这是解决并发不确定性最简单粗暴的办法。
撮合引擎本质上是一个纯函数：
next_state, output_events = match(prev_state, input_event)State = 订单簿 + 待触发单 + 账户持仓（部分引擎把持仓剥离出去），Input 来自上游 Gateway 的有序流，Output 是成交 + 行情事件 + ACK。这是典型的状态机复制（State Machine Replication）模型——与 Raft、Multi-Paxos 管理的状态机完全同构。
每条输入在进入撮合前先落盘 WAL。WAL 的几个关键设计：
O_DSYNC /
fsync 每条都落盘（安全但慢），或每 N 毫秒 / M
条批量 fsync（折中）只有 WAL 无法应对长时间运行（重放整天 WAL 太慢）。引擎定期把整个订单簿序列化成快照（Snapshot），落盘时记录”对应到哪个 WAL seq”。恢复时：加载最近快照 + 重放该 seq 之后的 WAL。
快照的关键工程点：
applied_seq，不得”撕裂”主备架构有两种主流模式：
Active-Passive with Log Shipping
主机把 WAL 条目流式发送给备机，备机应用相同事件序列，得到相同状态。切换时备机接管 Gateway 流量。这是 Nasdaq、Deutsche Börse、CME 等传统交易所使用的模式。
flowchart LR
G[Gateway] -->|seq序列化| P[Primary ME]
P -->|WAL| D1[(Local Disk)]
P -->|Replicate| B[Backup ME]
B -->|Apply same seq| D2[(Local Disk)]
P --> M[Market Data]
B -.standby.-> MRaft / Paxos 复制
写入 WAL 本身就走共识协议，至少 2/3 副本落盘才返回。一致性更强（无需额外切换协议），但延迟高一档（多一次 RTT）。dYdX v4 链上 CLOB 撮合走 Cosmos SDK + CometBFT（Tendermint），走的就是这条路：撮合逻辑本身跑在多个全节点上，通过 BFT 共识达成一致。
主备切换场景下要避免的最大灾难是脑裂下的双撮合。常见手段：
撮合引擎的计算非常轻——大部分订单的处理只是几次指针操作、一次树查找、一次链表操作——CPU 几十到几百纳秒就能完成。真正的瓶颈不是 CPU，而是：
所以业界共识是：单 symbol 的撮合必须单线程。多 symbol 通过分片（Sharding）并行：不同 symbol 分到不同撮合线程 / 实例上。BTC/USDT、ETH/USDT 各自跑一个 worker，没有任何跨 symbol 状态。
LMAX（伦敦一家多资产交易所）2010 年开源了 Disruptor 模式，把并发队列换成了环形缓冲区 + CAS 序号，在一台机器上做到每秒 600 万 TPS，单次订单处理延迟稳定在微秒级。核心思想：
Disruptor 的流水线版本最终形态：
flowchart LR
GW[Gateway<br/>多生产者] --> RB[Ring Buffer<br/>单一事件序列]
RB --> J[Journal 线程<br/>WAL]
RB --> R[Replication 线程<br/>发备机]
RB --> ME[Matching 线程<br/>核心撮合]
J -.fence.-> ME
R -.fence.-> ME
ME --> OUT[Output 线程<br/>广播]撮合线程等待 Journal、Replication 都越过了自己要处理的 seq 才处理（通过 fence / barrier 等待），确保”撮合输出的都是已持久化、已复制的订单”。
slab allocator 连续分配enum + switch
而非多态（编译器内联、分支预测更友好）u32 id，账户转为 u64 id按 symbol（合约） 分片是唯一广泛采用的策略。优点是跨分片零通信（订单、撤单、成交都在单一 symbol 内）。缺点是热门 symbol（如 BTC/USDT）单分片压力大，这时要靠垂直扩展（更快的 CPU、RDMA、内核旁路网络）。
按用户分片 不可行，因为一笔订单涉及两个用户（taker/maker），会触发跨分片事务，撮合立即退化成分布式事务。
按价格区间分片 在学术上被讨论过，但工程上没有严肃使用：价格会漂移，区间划分难以稳定。
撮合引擎之外的延迟优化（与本文主题相关但不展开）：
Nasdaq INET、Deutsche Börse T7、CME Globex 的”机柜到撮合”往返延迟在个位数微秒。
下面给出一个可运行的 Rust 简化撮合引擎：价格时间优先、支持 Limit/Market/Cancel、单线程。真实引擎要再加 WAL、快照、STP、订单类型、统计、行情分发，但核心循环就是这些。
use std::collections::{BTreeMap, HashMap, VecDeque};
pub type OrderId = u64;
pub type Price = i64; // 定点价格, 乘以 tick=1e-4 得到实际价格
pub type Qty = u64;
pub type Ts = i64;
#[derive(Copy, Clone, Debug, PartialEq, Eq)]
pub enum Side { Buy, Sell }
#[derive(Copy, Clone, Debug, PartialEq, Eq)]
pub enum OrdType { Limit, Market }
#[derive(Clone, Debug)]
pub struct Order {
pub id: OrderId,
pub side: Side,
pub ord_type: OrdType,
pub price: Price, // Market 单忽略
pub qty: Qty,
pub account: u64,
pub ts: Ts,
}
#[derive(Clone, Debug)]
pub struct Trade {
pub taker: OrderId,
pub maker: OrderId,
pub price: Price,
pub qty: Qty,
pub ts: Ts,
}pub struct Book {
// Buy 用 Reverse(Price) 让最大价在前; 这里用 BTreeMap 正序存, 取 iter().next_back() 得最大
bids: BTreeMap<Price, VecDeque<OrderId>>,
asks: BTreeMap<Price, VecDeque<OrderId>>,
orders: HashMap<OrderId, Order>, // 全量索引, 便于撤单
}
impl Book {
pub fn new() -> Self {
Self { bids: BTreeMap::new(), asks: BTreeMap::new(), orders: HashMap::new() }
}
pub fn best_bid(&self) -> Option<Price> { self.bids.keys().next_back().copied() }
pub fn best_ask(&self) -> Option<Price> { self.asks.keys().next().copied() }
fn insert(&mut self, o: Order) {
let side_map = match o.side { Side::Buy => &mut self.bids, Side::Sell => &mut self.asks };
side_map.entry(o.price).or_default().push_back(o.id);
self.orders.insert(o.id, o);
}
pub fn cancel(&mut self, id: OrderId) -> Option<Order> {
let o = self.orders.remove(&id)?;
let side_map = match o.side { Side::Buy => &mut self.bids, Side::Sell => &mut self.asks };
if let Some(q) = side_map.get_mut(&o.price) {
if let Some(pos) = q.iter().position(|&x| x == id) {
q.remove(pos);
}
if q.is_empty() { side_map.remove(&o.price); }
}
Some(o)
}
}生产级实现中，价格层应用双向链表而不是 VecDeque，以支持 O(1) 中间删除；VecDeque remove 是 O(N)。这里为了代码简短用 VecDeque。
impl Book {
pub fn place(&mut self, mut order: Order) -> Vec<Trade> {
let mut trades = Vec::new();
loop {
if order.qty == 0 { break; }
// 取对手方最优价
let (opp_px, opp_q_front_id) = match order.side {
Side::Buy => {
let Some((&px, q)) = self.asks.iter_mut().next() else { break; };
(px, *q.front().unwrap())
}
Side::Sell => {
let Some((&px, q)) = self.bids.iter_mut().next_back() else { break; };
(px, *q.front().unwrap())
}
};
// 是否可成交
let crosses = match (order.ord_type, order.side) {
(OrdType::Market, _) => true,
(OrdType::Limit, Side::Buy) => order.price >= opp_px,
(OrdType::Limit, Side::Sell) => order.price <= opp_px,
};
if !crosses { break; }
// 自成交预防 (简化: Cancel Taker)
let maker = self.orders.get(&opp_q_front_id).unwrap().clone();
if maker.account == order.account {
order.qty = 0; // taker 全撤
break;
}
let fill = order.qty.min(maker.qty);
trades.push(Trade {
taker: order.id,
maker: maker.id,
price: opp_px,
qty: fill,
ts: order.ts,
});
order.qty -= fill;
// 更新 maker
let maker_remaining = maker.qty - fill;
if maker_remaining == 0 {
self.cancel(maker.id);
} else {
self.orders.get_mut(&maker.id).unwrap().qty = maker_remaining;
}
}
// 剩余挂簿 (Limit 且有剩余)
if order.qty > 0 && matches!(order.ord_type, OrdType::Limit) {
self.insert(order);
}
trades
}
}#[cfg(test)]
mod tests {
use super::*;
fn ord(id: u64, side: Side, t: OrdType, px: Price, qty: Qty, acc: u64) -> Order {
Order { id, side, ord_type: t, price: px, qty, account: acc, ts: id as i64 }
}
#[test]
fn empty_book_limit_rests() {
let mut b = Book::new();
let trades = b.place(ord(1, Side::Buy, OrdType::Limit, 10_000, 100, 1));
assert!(trades.is_empty());
assert_eq!(b.best_bid(), Some(10_000));
}
#[test]
fn partial_fill() {
let mut b = Book::new();
b.place(ord(1, Side::Sell, OrdType::Limit, 10_000, 100, 1));
let trades = b.place(ord(2, Side::Buy, OrdType::Limit, 10_000, 60, 2));
assert_eq!(trades.len(), 1);
assert_eq!(trades[0].qty, 60);
assert_eq!(b.best_ask(), Some(10_000)); // maker 剩 40 仍挂着
}
#[test]
fn full_fill() {
let mut b = Book::new();
b.place(ord(1, Side::Sell, OrdType::Limit, 10_000, 100, 1));
let trades = b.place(ord(2, Side::Buy, OrdType::Limit, 10_000, 100, 2));
assert_eq!(trades.len(), 1);
assert_eq!(trades[0].qty, 100);
assert_eq!(b.best_ask(), None);
}
#[test]
fn sweep_multiple_levels() {
let mut b = Book::new();
b.place(ord(1, Side::Sell, OrdType::Limit, 10_000, 30, 1));
b.place(ord(2, Side::Sell, OrdType::Limit, 10_001, 40, 1));
b.place(ord(3, Side::Sell, OrdType::Limit, 10_002, 50, 1));
let trades = b.place(ord(4, Side::Buy, OrdType::Limit, 10_002, 100, 2));
assert_eq!(trades.len(), 3);
assert_eq!(trades.iter().map(|t| t.qty).sum::<u64>(), 100); // 30 + 40 + 30
assert_eq!(b.best_ask(), Some(10_002)); // O3 剩 20 仍挂
}
#[test]
fn self_trade_prevents() {
let mut b = Book::new();
b.place(ord(1, Side::Sell, OrdType::Limit, 10_000, 100, 7));
let trades = b.place(ord(2, Side::Buy, OrdType::Limit, 10_000, 50, 7));
assert!(trades.is_empty()); // 同账户, taker 被撤
assert_eq!(b.best_ask(), Some(10_000)); // maker 保留
}
#[test]
fn market_no_counterparty() {
let mut b = Book::new();
let trades = b.place(ord(1, Side::Buy, OrdType::Market, 0, 100, 1));
assert!(trades.is_empty());
// 市价单不入簿
assert_eq!(b.best_bid(), None);
}
#[test]
fn cancel() {
let mut b = Book::new();
b.place(ord(1, Side::Buy, OrdType::Limit, 10_000, 100, 1));
let canceled = b.cancel(1);
assert!(canceled.is_some());
assert_eq!(b.best_bid(), None);
}
}Go 的 BTree 需要引入第三方库（如
google/btree），示例骨架：
type Book struct {
bids *btree.BTreeG[*Level] // 按 -price 排序
asks *btree.BTreeG[*Level] // 按 price 排序
orders map[uint64]*Order
}
type Level struct {
price int64
queue *list.List // container/list 双向链表, 每个元素是 *Order
total uint64
}
func (b *Book) Place(o *Order) []Trade {
var trades []Trade
for o.Qty > 0 {
best := b.bestOpposite(o.Side)
if best == nil || !crosses(o, best) { break }
e := best.queue.Front()
m := e.Value.(*Order)
if m.Account == o.Account {
o.Qty = 0 // 简化的 STP
break
}
fill := min(o.Qty, m.Qty)
trades = append(trades, Trade{Taker: o.ID, Maker: m.ID, Price: best.price, Qty: fill})
o.Qty -= fill
m.Qty -= fill
if m.Qty == 0 {
best.queue.Remove(e)
delete(b.orders, m.ID)
if best.queue.Len() == 0 { b.removeLevel(best) }
}
}
if o.Qty > 0 && o.Type == Limit { b.insert(o) }
return trades
}stateDiagram-v2
[*] --> Received: Gateway 接收
Received --> Validated: 风控 / 资金冻结通过
Received --> Rejected: 校验 / 资金不足
Validated --> Accepted: 进入撮合队列
Accepted --> PartiallyFilled: 部分成交
Accepted --> Filled: 全部成交
Accepted --> Canceled: 用户撤单
Accepted --> Expired: GTD 到期
PartiallyFilled --> Filled: 继续成交填满
PartiallyFilled --> Canceled: 用户撤单剩余
PartiallyFilled --> Expired: GTD 到期
Filled --> [*]
Canceled --> [*]
Rejected --> [*]
Expired --> [*]sequenceDiagram
participant C as Client
participant G as Gateway
participant W as WAL
participant ME as Matching
participant MD as Market Data
participant R as Risk/Clearing
C->>G: NewOrder(BTC/USDT, BUY, 10, 65000)
G->>G: 签名校验 / 限流
G->>R: 冻结 10*65000 USDT
R-->>G: OK
G->>W: Append seq=N (NEW_ORDER)
W-->>G: persisted
G->>ME: dispatch by symbol
ME->>ME: match loop (单线程)
ME-->>G: Ack + Trades + BookDelta
ME->>MD: 行情事件
ME->>R: 成交 → 扣资金 / 加持仓
G-->>C: Exec Report (8=FIX...)
MD-->>C: L1/L2/L3 更新学习撮合引擎最好的方式是读开源代码：
price_int = round(price * 10^decimals)）。用
double 的系统都会在某一天遇到
0.1 + 0.2 != 0.3 的成交价问题。rand、多线程日志、异步
GC——逐一审计。| 场景 | 建议 |
|---|---|
| 创业加密所、日均 < 10 万单 | Go / Rust 单进程 + Postgres WAL 模拟，优先把 STP、订单类型、对账做对，别过度优化 |
| 专业加密所、日均百万单 | Rust / C++，自建 WAL + 快照，按 symbol 分片，Disruptor 风格线程模型，P99 < 1ms 可达 |
| 传统证券 / 期货交易所 | 闭源商业引擎（Nasdaq INET、Cinnober TRADExpress、FIS MillenniumIT）+ 深度定制；自研团队 50+ 人，3 年以上周期 |
| 链上 CLOB（DeFi） | 直接基于 Cosmos SDK / dYdX v4 分叉，撮合通过 BFT 共识；延迟档次牺牲，换来可验证性与无 KYC |
| 教学 / 研究 | exchange-core、liquibook 源码 + 本文 Rust 示例 |
BTC/USDT 订单簿快照 (L2)
Price Bid Qty Ask Qty Depth Visualization
65,010 3.50
65,008 2.10
65,006 1.80
65,004 0.90
65,002 0.40 Best Ask
Spread = 2 USDT
65,000 0.60 Best Bid
64,998 1.50
64,996 2.80
64,994 3.20
64,992 4.10
每档内部 = 多个订单 FIFO 队列 (L3 中单独展开为独立事件)评估撮合引擎性能时，常见的错误做法：
recordValueWithExpectedInterval 专治。一个较严肃的测法：
cpupower frequency-set -g performance
taskset -c 3 ./me_bench # pin 到隔离核
# isolcpus=3,5,7 在内核启动参数里
# irqbalance 停掉, 把所有 IRQ 绑到非撮合核撮合侧不应该做余额 / 仓位校验——那是风控（Pre-Trade Risk Check）的职责。但撮合侧必须做的检查：
一个账户在极端行情下想”全撤”，如果撮合侧是单线程，一次 MassCancel 触发上千个 CANCEL 事件会堵住主循环几毫秒。实现技巧：
canceled，但实际从簿里移除可以异步（打
tombstone）虽然费率计算通常在撮合之后（Clearing 侧）进行，但 maker/taker 标签是撮合时才能确定的：吃单方是 taker，挂单方是 maker。这个标签必须在 Trade 事件里携带，供清算侧计算不同费率。
某些交易所（如 Binance VIP 做市商项目）还有”负费率”——做市商挂单成交收到 rebate。此时引擎需要把”做市商标识”随 Trade 事件一并带出。
做市商经常”秒内报撤几千次”，这会压垮撮合。应对：
A 股有涨跌停（±10%、ST ±5%、注册板 ±20%）+ 当日 10% 异动停牌机制；美股用 LULD（Limit Up-Limit Down）；加密所用价格带 / 自动去杠杆（ADL）。
撮合引擎线上升级是高风险操作。两种主要策略：
Hot-Standby 升级： 1. 备机升级到新版本 2. 用主机 WAL 回放建立状态 3. 业务低峰窗口做主备切换 4. 观察新主机 30 分钟后升级旧主机为新备机
交易时段外停机升级：A 股等有明确盘后窗口的市场可以直接停机升级。
灰度 by symbol：先把小众 symbol 分片切到新版本，观察稳定后再切热门 symbol。但跨版本的行情格式兼容必须提前处理。
撮合引擎的核心指标：
日志必须结构化（JSON / Protobuf），带
trace_id（客户端请求贯穿）、seq（撮合内部排序）。延迟数据走
HDR Histogram 周期性采样导出到 Prometheus /
VictoriaMetrics。
撮合引擎只解决一件事：在给定规则下，从输入订单序列产生确定的成交序列。它小而深：数据结构不超过三百行，但把 WAL、快照、主备、确定性、订单类型、集合竞价、STP 全部加齐后是一个三万行起步的系统。
上一篇：《交易所核心系统架构：撮合、行情、做市、风控、清算》
下一篇：《行情分发：MBP/MBO、快照+增量、组播/TCP、FIX/ITCH》
把当前热点继续串成多页阅读，而不是停在单篇消费。
2026-04-22 · architecture / fintech
从订单网关到撮合引擎、从 L1/L2/L3 行情到清算与结算，系统梳理证券、期货、加密货币交易所的五大核心子系统；给出低延迟工程技术栈（Disruptor、Kernel Bypass、FPGA）、订单生命周期状态机、主流交易所（NYSE Pillar、Nasdaq INET、上交所新一代、CME Globex、Binance、dYdX v4）对比、以及 Flash Crash 与 Knight Capital 的工程教训。
2026-04-22 · architecture / fintech
金融科技（FinTech）不是普通后端加一张账户表。钱的原子性、监管的硬边界、一个小数点的代价，把这个领域推进到工程强度最高的那一档。本文是【金融科技工程】25 篇的总目录与阅读地图：先交代为什么它比一般业务系统更难，再给出对账体、支付体、交易体、风控合规体四维分类，把后续 24 篇挂到骨架上，最后给出一份绿地项目的落地顺序建议。
2026-04-22 · architecture / fintech
支付与账务系统里，"这笔操作能不能重放一遍"几乎是每一次故障复盘都会问到的问题。本文从网络重试的本质谈起，讲清楚幂等（idempotency）的三层设计、Idempotency-Key 的工程细节、订单状态机的落库方式，并横向对比 2PC、TCC、SAGA、可靠消息四种分布式事务方案，配合 Outbox Pattern、CDC、补偿策略与真实事故案例，给出一份可以直接落地的检查清单。
2026-04-22 · architecture / fintech
从业务系统到支付宝、微信、银联、Visa、Stripe、Airwallex，中间这一层"支付网关"承担了路由、限流、熔断、补单、签名、异步通知分发等几乎所有脏活累活。本文系统整理一个自研或半自研支付网关的工程设计，包括数据模型、双状态机、路由策略、密钥管理与可观测性。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。