Arch Day 63: 证券交易系统架构

日期: 2026-06-01 (Day 63) 阶段: 第二阶段 - 金融域深度 标签: #撮合引擎 #订单簿 #行情系统 #清算交收 #低延迟

---

核心概念

一句话定义

证券交易系统是实现订单接收、撮合成交、行情发布、清算交收等功能的全链路系统，是资本市场的核心基础设施。其设计挑战在于极致性能(微秒级延迟)、绝对正确性(一笔都不能错)和高可用性(交易时段零停机)的同时满足。

为什么关注

• 金融核心：全球每日股票交易额超万亿美元，交易系统是金融市场的"心脏"
• 性能极致：Nasdaq撮合引擎延迟低至14微秒，代表工程极限
• 架构典范：交易系统的确定性状态机、事件驱动等设计思想影响深远
• CeFi→DeFi桥梁：理解传统撮合引擎才能深入对比AMM的创新
• 面试高频：撮合引擎设计是系统设计面试的经典题目

误区与反模式

---

知识点详解

1. 证券交易系统全景架构

证券交易系统全景：

┌─────────────────────────────────────────────────────────┐
│                     交易所全景架构                        │
│                                                         │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐             │
│  │ 交易网关  │  │ 撮合引擎  │  │ 行情系统  │             │
│  │(Gateway) │→│(Matching │→│(Market   │             │
│  │          │  │ Engine)  │  │ Data)    │             │
│  └──────────┘  └──────────┘  └──────────┘             │
│       ↑              ↑              ↓                   │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐             │
│  │ 委托管理  │  │ 风控系统  │  │ 信息发布  │             │
│  │(OMS)    │  │(Pre-trade│  │(MDP)    │             │
│  │          │  │ Risk)    │  │          │             │
│  └──────────┘  └──────────┘  └──────────┘             │
│       ↑                              ↓                   │
│  ┌──────────┐                  ┌──────────┐             │
│  │ 会员系统  │                  │ 清算系统  │             │
│  │(Member) │                  │(Clearing)│             │
│  │          │                  │          │             │
│  └──────────┘                  └──────────┘             │
│       ↑                              ↓                   │
│  ┌──────────┐                  ┌──────────┐             │
│  │ 券商/机构 │                  │ 交收系统  │             │
│  │(Broker) │                  │(Settlement│            │
│  │          │                  │          │             │
│  └──────────┘                  └──────────┘             │
└─────────────────────────────────────────────────────────┘

2. 撮合引擎(Matching Engine)核心设计

撮合引擎设计原则

原则1: 确定性(Determinism)
  → 相同的输入序列必须产生相同的输出
  → 核心执行必须单线程(避免非确定性)
  → 不依赖外部时钟(使用逻辑时钟/序列号)

原则2: 公平性(Fairness)
  → 价格优先：更优价格的订单先成交
  → 时间优先：同价格下先到的订单先成交
  → 不能有任何"插队"的可能

原则3: 高性能(Performance)
  → Nasdaq撮合引擎：14微秒延迟(最快)
  → 一般目标：亚毫秒级(<1ms)
  → 吞吐量：每秒数百万订单

原则4: 正确性(Correctness)
  → 一笔都不能错
  → 所有状态变更必须可审计
  → 支持准确的灾难恢复

订单簿(Order Book)数据结构

订单簿逻辑结构：

        卖方(Ask)                    买方(Bid)
  价格    │  数量    时间        价格    │  数量    时间
  ────────┼──────────────        ────────┼──────────────
  $102.50 │  500    09:30:01    $100.50 │  300    09:30:00
  $102.00 │  200    09:30:02    $100.00 │  1000   09:29:58
  $101.50 │  800    09:30:00    $99.50  │  500    09:29:55
  $101.00 │  150    09:30:03    $99.00  │  200    09:29:50

  最优卖价(Best Ask) = $101.00
  最优买价(Best Bid) = $100.50
  买卖价差(Spread) = $0.50

  Level 1行情：最优买卖价+量
  Level 2行情：前5/10档
  Level 3行情：全部订单(Full Depth)

订单簿数据结构实现

/**
 * 高性能订单簿实现
 *
 * 关键数据结构选择：
 * - 价格层级：TreeMap(红黑树) → O(log n) 插入/查找
 * - 同价格订单：LinkedList → O(1) 追加，FIFO出队
 * - 订单索引：HashMap → O(1) 按ID查找(用于撤单)
 *
 * 更高性能方案：
 * - 价格层级用数组(价格→索引映射) → O(1)
 * - 内存池预分配 → 避免GC
 * - 紧凑布局 → 缓存友好
 */
public class OrderBook {
    // 买方：降序排列(最高价在前)
    private final TreeMap<Long, PriceLevel> bids =
        new TreeMap<>(Comparator.reverseOrder());

    // 卖方：升序排列(最低价在前)
    private final TreeMap<Long, PriceLevel> asks =
        new TreeMap<>();

    // 订单索引：O(1) 按ID查找
    private final HashMap<Long, Order> orderIndex = new HashMap<>();

    /**
     * 添加限价订单
     */
    public MatchResult addLimitOrder(Order order) {
        // Step 1: 尝试撮合
        MatchResult result = tryMatch(order);

        // Step 2: 未完全成交的部分挂到订单簿
        if (order.getRemainingQty() > 0) {
            addToBook(order);
        }

        return result;
    }

    /**
     * 核心撮合逻辑
     */
    private MatchResult tryMatch(Order order) {
        MatchResult result = new MatchResult();
        TreeMap<Long, PriceLevel> oppositeSide =
            order.isBuy() ? asks : bids;

        while (order.getRemainingQty() > 0 && !oppositeSide.isEmpty()) {
            Map.Entry<Long, PriceLevel> bestLevel =
                oppositeSide.firstEntry();
            long bestPrice = bestLevel.getKey();

            // 检查价格是否可成交
            if (order.isBuy() && bestPrice > order.getPrice()) break;
            if (!order.isBuy() && bestPrice < order.getPrice()) break;

            PriceLevel level = bestLevel.getValue();

            // 在同一价格层级内按时间优先撮合
            while (order.getRemainingQty() > 0 && !level.isEmpty()) {
                Order restingOrder = level.peekFirst();
                long matchQty = Math.min(
                    order.getRemainingQty(),
                    restingOrder.getRemainingQty()
                );

                // 生成成交记录
                Trade trade = new Trade(
                    order, restingOrder, bestPrice, matchQty
                );
                result.addTrade(trade);

                // 更新数量
                order.reduceQty(matchQty);
                restingOrder.reduceQty(matchQty);

                // 移除完全成交的挂单
                if (restingOrder.getRemainingQty() == 0) {
                    level.removeFirst();
                    orderIndex.remove(restingOrder.getId());
                }
            }

            // 移除空的价格层级
            if (level.isEmpty()) {
                oppositeSide.pollFirstEntry();
            }
        }

        return result;
    }

    /**
     * 撤单
     */
    public boolean cancelOrder(long orderId) {
        Order order = orderIndex.remove(orderId);
        if (order == null) return false;

        TreeMap<Long, PriceLevel> side =
            order.isBuy() ? bids : asks;
        PriceLevel level = side.get(order.getPrice());

        if (level != null) {
            level.remove(order);
            if (level.isEmpty()) {
                side.remove(order.getPrice());
            }
        }
        return true;
    }
}

/**
 * 价格层级：同一价格下的订单队列
 */
class PriceLevel {
    private final LinkedList<Order> orders = new LinkedList<>();
    private long totalQty = 0;

    public void add(Order order) {
        orders.addLast(order);  // FIFO: 新订单加到队尾
        totalQty += order.getRemainingQty();
    }

    public Order peekFirst() {
        return orders.peekFirst();  // 时间优先: 最早的订单在前
    }

    // ... 其他方法
}

撮合算法

集合竞价算法

集合竞价(Call Auction)算法：

目标：找到一个价格P，使得以该价格成交的总量最大

算法步骤：
1. 收集时段内所有委托
2. 对每个可能的价格P：
   - 计算买方愿意以P或更高价格买入的总量 = BuyQty(P)
   - 计算卖方愿意以P或更低价格卖出的总量 = SellQty(P)
   - 可成交量 = min(BuyQty(P), SellQty(P))
3. 选择可成交量最大的P作为开盘价/收盘价
4. 平局规则：选择未成交量最小的价格

示例：
  买入委托：100@$10, 200@$9.5, 150@$9
  卖出委托：80@$8.5, 120@$9, 200@$9.5

  价格=$9时：
    BuyQty = 100+200+150 = 450
    SellQty = 80+120 = 200
    成交量 = min(450, 200) = 200

  价格=$9.5时：
    BuyQty = 100+200 = 300
    SellQty = 80+120+200 = 400
    成交量 = min(300, 400) = 300 ← 最大

  开盘价 = $9.5, 成交量 = 300

3. 行情系统(Market Data)

行情数据层级

Level 1 (最优报价)：
  ├── Best Bid: $100.50 x 300
  ├── Best Ask: $101.00 x 150
  ├── Last Trade: $100.75 x 100
  ├── Volume: 1,234,567
  └── VWAP: $100.62
  延迟要求：<1ms | 带宽：低

Level 2 (深度行情)：
  ├── Top 5/10/20 Bid档位(价格+汇总量)
  ├── Top 5/10/20 Ask档位(价格+汇总量)
  └── 适合机构交易者
  延迟要求：<5ms | 带宽：中

Level 3 (逐笔/完整订单簿)：
  ├── 每一笔委托/成交/撤单
  ├── 完整订单簿重建
  └── 适合高频交易/做市商
  延迟要求：<1ms | 带宽：高

行情推送架构

行情系统架构：

┌──────────┐    ┌──────────┐    ┌──────────┐
│ 撮合引擎  │───→│ 行情聚合  │───→│ 行情分发  │
│(成交事件) │    │(合并/计算)│    │(多播推送) │
└──────────┘    └──────────┘    └──────────┘
                     │                │
                     ▼                ▼
              ┌──────────┐    ┌──────────┐
              │ 快照管理  │    │ 增量推送  │
              │(Snapshot)│    │(Delta)   │
              └──────────┘    └──────────┘

推送模式对比：
┌──────────┬──────────┬──────────┬──────────┐
│ 模式     │ 说明      │ 延迟     │ 带宽     │
├──────────┼──────────┼──────────┼──────────┤
│ 快照     │ 定时发送  │ 高(周期) │ 高       │
│          │ 完整状态  │          │          │
├──────────┼──────────┼──────────┼──────────┤
│ 增量     │ 只发送变化│ 低       │ 低       │
│          │          │          │          │
├──────────┼──────────┼──────────┼──────────┤
│ 快照+增量│ 定期快照  │ 中       │ 中       │
│          │ +实时增量 │          │          │
└──────────┴──────────┴──────────┴──────────┘

技术选型：
├── 传输协议：UDP Multicast(最低延迟)
├── 序列化：SBE(Simple Binary Encoding) / FlatBuffers
├── 消息队列：Aeron(超低延迟消息)
└── 压缩：增量编码 + 字典压缩

4. 委托管理(Order Management System, OMS)

订单状态机

stateDiagram-v2
    [*] --> PendingNew: 提交委托
    PendingNew --> New: 交易所确认
    PendingNew --> Rejected: 风控拒绝

    New --> PartiallyFilled: 部分成交
    New --> Filled: 完全成交
    New --> PendingCancel: 请求撤单
    New --> PendingReplace: 请求改单

    PartiallyFilled --> Filled: 剩余成交
    PartiallyFilled --> PendingCancel: 请求撤单
    PartiallyFilled --> PendingReplace: 请求改单

    PendingCancel --> Cancelled: 撤单成功
    PendingCancel --> PartiallyFilled: 撤单前部分成交
    PendingCancel --> Filled: 撤单前完全成交

    PendingReplace --> Replaced: 改单成功
    PendingReplace --> New: 改单拒绝(保持原单)

    Filled --> [*]
    Cancelled --> [*]
    Rejected --> [*]

订单类型

5. 清算交收(Clearing & Settlement)

清算交收全流程

交易日 T：
  09:15-09:25  集合竞价
  09:30-11:30  连续竞价(上午)
  13:00-15:00  连续竞价(下午)
  15:00-15:30  清算处理

T+0日(交易当天)：
  ├── 成交确认(Trade Confirmation)
  ├── 轧差计算(Netting)
  │   ├── 双边轧差：A欠B $100, B欠A $70 → A净付B $30
  │   └── 多边轧差(CCP)：所有参与方对CCP轧差
  ├── 保证金计算
  └── 结算指令生成

T+1日(交收日，中国A股/美股)：
  ├── 资金划转(Payment)
  ├── 证券过户(Delivery)
  ├── DVP检查(Delivery versus Payment)
  │   └── 确保"一手交钱一手交货"
  └── 交收完成确认

CCP(中央对手方)模式

无CCP模式(双边清算)：
  A ←→ B
  A ←→ C
  B ←→ C
  问题：任何一方违约影响所有对手方

有CCP模式(如中国结算/DTCC)：
  A ←→ CCP ←→ B
  A ←→ CCP ←→ C
  优势：
  ├── 多边轧差减少资金/证券交割量
  ├── 违约隔离(CCP承担对手方风险)
  ├── 匿名化(交易对手看不到彼此)
  └── 标准化(统一交收流程)

CCP风险管理层次(Default Waterfall)：
  第1层：违约方保证金
  第2层：违约方违约基金
  第3层：CCP自有风险准备金
  第4层：非违约方违约基金
  第5层：CCP资本金
  第6层：政府救助(极端情况)

6. 交易系统极致性能

延迟指标(2025-2026行业数据)

低延迟技术栈

网络层优化：
├── 内核旁路(Kernel Bypass)：DPDK/Solarflare OpenOnload
├── RDMA：远程直接内存访问(跳过OS)
├── FPGA：硬件加速网络处理
├── AWS Nitro硬件时间戳(2025)：纳秒级精度
└── 共置(Co-location)：服务器放在交易所机房

序列化优化：
├── SBE(Simple Binary Encoding)：零拷贝序列化
├── FlatBuffers：无解析开销
├── Protocol Buffers：通用场景
└── 自定义二进制协议：极致性能

内存管理：
├── 预分配内存池(Object Pool)
├── 无GC设计(C++/Rust或Java off-heap)
├── 缓存行对齐(Cache Line Alignment)
├── NUMA感知内存分配
└── 大页内存(Huge Pages)

并发设计：
├── LMAX Disruptor：无锁环形缓冲区
├── 单线程核心(Single-Writer Principle)
├── CPU亲和性(CPU Pinning)
├── Busy Spinning(忙等待替代阻塞)
└── Aeron：超低延迟消息传递

LMAX Disruptor模式

LMAX架构核心思想：
  - 单线程处理所有业务逻辑(撮合、风控)
  - 通过机械同情(Mechanical Sympathy)榨取硬件性能
  - 无锁设计，避免上下文切换

性能数据：
  - 单线程处理600万订单/秒
  - 平均延迟 < 1微秒

┌──────────┐
│ 网络IO线程│
│ (接收订单)│
└─────┬────┘
      ▼
┌──────────────────────────────────────┐
│         Ring Buffer (无锁环形缓冲)     │
│  ┌───┬───┬───┬───┬───┬───┬───┬───┐  │
│  │ 0 │ 1 │ 2 │ 3 │ 4 │ 5 │ 6 │ 7 │  │
│  └───┴───┴───┴───┴───┴───┴───┴───┘  │
│     ↑                   ↑             │
│  Writer Cursor      Reader Cursor     │
└──────────────────────────────────────┘
      ▼
┌──────────┐
│ 业务处理  │ ← 单线程: 风控→撮合→行情→日志
│ (单线程)  │
└──────────┘

7. FIX协议

FIX(Financial Information eXchange)协议：
  - 金融交易领域的标准通信协议
  - 版本：FIX 4.2/4.4/5.0(最新FIXT 1.1)
  - 覆盖：订单/执行/行情/清算等全生命周期

FIX消息示例(新订单)：

8=FIX.4.4|9=148|35=D|49=CLIENT1|56=EXCHANGE|
34=1|52=20260601-09:30:01.123|
11=ORD-001|55=AAPL|54=1|38=100|40=2|44=150.00|
59=0|10=128|

字段解释：
  8  = BeginString (协议版本)
  35 = MsgType (D=新订单)
  49 = SenderCompID (发送方)
  56 = TargetCompID (接收方)
  11 = ClOrdID (客户订单ID)
  55 = Symbol (证券代码)
  54 = Side (1=买 2=卖)
  38 = OrderQty (数量)
  40 = OrdType (2=限价)
  44 = Price (价格)
  59 = TimeInForce (0=当日有效)

FIX引擎选型：
  ├── QuickFIX/J (Java，开源，最广泛)
  ├── QuickFIX/n (.NET)
  ├── Chronicle-FIX (低延迟Java)
  └── 自研(追求极致性能)

---

对比分析

传统交易所 vs 加密货币交易所 vs DEX

撮合算法对比

---

架构设计实操

设计目标

设计一个"简易撮合引擎"，支持：

• 限价单/市价单
• 价格-时间优先撮合
• 订单簿管理(添加/撤单/改单)
• 行情快照生成
• 10万+ 订单/秒处理能力

系统架构

简易撮合引擎架构：

┌──────────────────────────────────────────────┐
│                  网络接入层                     │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐     │
│  │ TCP接入  │  │ FIX网关  │  │ WebSocket│     │
│  └────┬────┘  └────┬────┘  └────┬────┘     │
│       └─────────────┼───────────┘            │
│                     ▼                         │
│            ┌──────────────┐                   │
│            │  协议解析器   │                   │
│            │  (SBE反序列化)│                   │
│            └──────┬───────┘                   │
└───────────────────┼──────────────────────────┘
                    ▼
┌──────────────────────────────────────────────┐
│              前置风控(Pre-Trade Risk)          │
│  ├── 委托价格限制(涨跌停)                      │
│  ├── 委托数量限制                              │
│  ├── 资金/持仓检查                             │
│  └── 频率限制                                  │
└───────────────────┼──────────────────────────┘
                    ▼
┌──────────────────────────────────────────────┐
│           Ring Buffer (Disruptor)             │
│  ┌───┬───┬───┬───┬───┬───┬───┬───┐         │
│  │   │   │   │   │   │   │   │   │         │
│  └───┴───┴───┴───┴───┴───┴───┴───┘         │
└───────────────────┼──────────────────────────┘
                    ▼
┌──────────────────────────────────────────────┐
│          撮合引擎(单线程)                      │
│  ┌─────────────────────────────────────┐    │
│  │           撮合处理器                  │    │
│  │  ┌──────────┐  ┌──────────┐        │    │
│  │  │  订单簿   │  │  撮合算法  │       │    │
│  │  │(OrderBook)│  │(Matcher) │       │    │
│  │  └──────────┘  └──────────┘        │    │
│  └─────────────────────────────────────┘    │
│           │              │                   │
│     ┌─────┘              └──────┐            │
│     ▼                           ▼            │
│  ┌──────────┐           ┌──────────┐        │
│  │  成交事件  │          │  行情更新  │        │
│  │  (Trade)  │          │  (Quote)  │        │
│  └──────────┘           └──────────┘        │
└──────────────────────────────────────────────┘
        │                       │
        ▼                       ▼
┌──────────────┐       ┌──────────────┐
│   成交回报    │       │   行情发布    │
│  (Execution  │       │  (Market     │
│   Report)    │       │   Data)      │
└──────────────┘       └──────────────┘

ADR: 撮合引擎并发模型选型

## ADR-063: 撮合引擎并发模型

### 状态: 已采纳

### 上下文
撮合引擎需要在高吞吐量下保持确定性和低延迟。

### 可选方案
A. 多线程 + 锁(传统)
B. 单线程事件循环(LMAX模式)
C. Actor模型(Akka)
D. 每个证券一个线程

### 决策
采用方案B：单线程事件循环(LMAX Disruptor模式)

### 理由
1. 确定性：单线程=确定性序列处理，无并发bug
2. 性能：无锁设计避免上下文切换，延迟极低
3. 简单性：状态管理简单，容易推理和调试
4. 恢复：事件回放即可精确恢复状态
5. 实际验证：LMAX单线程处理600万订单/秒

方案D(每证券一线程)在证券数量极多(数千+)时可作为扩展。

### 后果
- 单证券吞吐受限于单核性能
- 跨证券操作需要消息传递
- CPU单核性能成为瓶颈

---

AI增强实践

AI在交易系统中的应用

1. 智能路由(Smart Order Routing)
   ├── AI预测各交易所流动性
   ├── 最优执行算法(VWAP/TWAP/POV)
   ├── 减少市场冲击(Impact Cost)
   └── 合规最佳执行报告

2. 做市策略AI
   ├── 深度学习预测短期价格
   ├── 强化学习优化报价策略
   ├── 库存风险管理
   └── 对冲策略自动化

3. 市场监控AI
   ├── 异常交易模式检测(Spoofing/Layering)
   ├── 内幕交易关联分析
   ├── 市场操纵识别
   └── Flash Crash预警

4. LLM在交易的新应用(2025-2026)
   ├── 新闻事件→交易信号(NLP)
   ├── 财报分析→投资建议
   ├── 合规文件自动解读
   └── 交易异常的自然语言解释

5. FPGA/硬件AI加速
   ├── FPGA实现的神经网络推理
   ├── 硬件级别的行情处理
   └── 纳秒级信号生成

AWS 2025年硬件时间戳创新

AWS Nitro硬件包时间戳(2025年6月)：
├── 功能：在网络包的硬件层面附加64位纳秒级时间戳
├── 意义：绕过软件层延迟，提供最精确的事件时序
├── 应用：
│   ├── 交易公平性审计(精确的到达时间)
│   ├── 延迟测量优化
│   └── 监管合规(MiFID II时间戳要求)
└── 对加密交易所：数字资产交易所可在AWS上
    实现接近传统交易所的时间精度

---

与Web3/DeFi的关联

传统撮合 vs AMM vs Intent-Based

撮合引擎(传统)：
  买卖双方 → 订单簿 → 价格-时间优先撮合 → 成交

AMM(Uniswap V2)：
  交易者 → 流动性池(x*y=k) → 按曲线定价 → 成交
  问题：无常损失、资本效率低

集中流动性AMM(Uniswap V3)：
  LP指定价格范围 → 集中流动性 → 类似限价单的效果
  趋势：向订单簿方向演进

Intent-Based(CoW Protocol/UniswapX)：
  用户表达"意图"(Intent) → Solver竞争最优执行
  → 可以组合链上/链下流动性
  趋势：最灵活的执行方式

Hybrid(混合订单簿+AMM)：
  dYdX v4: 去中心化订单簿(Cosmos链)
  Serum: 链上订单簿(Solana)
  趋势：DeFi在重建传统交易基础设施

传统清算 vs 链上清算

---

今日思考

三个深度问题

1. 单线程撮合的扩展性极限：LMAX单线程600万订单/秒已经很快，但如果市场活跃度继续增长(AI高频交易)，单线程终将成为瓶颈。如何在保持确定性的前提下实现水平扩展？按证券分片是最优方案吗？跨分片操作(如篮子交易)如何处理？

2. DeFi为什么选择AMM而非订单簿？ 纯粹是技术限制(区块链吞吐量不足以支撑订单簿)，还是AMM有独特的产品优势？随着L2/L3吞吐量提升(如dYdX v4)，DeFi是否会回归订单簿？AMM和订单簿会长期共存吗？

3. T+0即时清算的"双刃剑"：DeFi的即时清算消除了对手方风险和清算周期，但也消除了"轧差"带来的资金效率。传统市场通过T+1清算和多边轧差，实际需要交割的资金/证券量远小于交易总量。DeFi如何兼顾即时性和资金效率？

---

面试题准备

面试题1: 撮合引擎如何保证高性能？

30秒回答： 高性能撮合引擎的核心是LMAX Disruptor模式——单线程处理所有撮合逻辑，通过无锁环形缓冲区接收订单。配合内存中的订单簿数据结构(TreeMap+LinkedList实现O(log n)插入)、SBE零拷贝序列化、CPU亲和性绑定和内核旁路网络，可实现单线程600万订单/秒、微秒级延迟。Nasdaq最新撮合引擎已做到14微秒door-to-door延迟。

2分钟详细回答： 高性能撮合引擎的设计可以从四个层面来分析：

第一层：并发模型。采用单线程事件驱动模型(LMAX模式)，核心撮合逻辑在单线程中执行，完全避免锁竞争和上下文切换。输入通过无锁Ring Buffer传递，输出同样通过Ring Buffer扇出到多个消费者(行情/回报/日志)。

第二层：数据结构。订单簿用TreeMap(红黑树)按价格排序，每个价格层级用链表维护FIFO队列，订单索引用HashMap实现O(1)查找(撤单需要)。更极致的方案是用数组替代TreeMap(价格映射到数组下标)，达到O(1)复杂度。内存预分配对象池避免GC。

第三层：网络与序列化。使用内核旁路技术(DPDK/Solarflare)绕过操作系统网络栈。序列化采用SBE(Simple Binary Encoding)实现零拷贝。消息传递使用Aeron低延迟框架。

第四层：硬件优化。CPU亲和性绑定(避免调度抖动)、NUMA感知内存分配、大页内存、缓存行对齐。物理部署使用交易所共置(Co-location)。

追问准备：

• Q: 单线程性能到极限怎么办？
• A: 按证券分片，每个证券(或一组证券)一个撮合线程。跨证券操作通过消息传递协调。

面试题2: 订单簿数据结构如何选择？

30秒回答： 订单簿数据结构选择取决于性能要求。通用方案用TreeMap(红黑树)存储价格层级(O(log n)插入/查找)，每个价格层级用LinkedList(FIFO，O(1)入队出队)。极致性能方案用数组(价格→索引映射，O(1))。所有方案都需要额外的HashMap做订单ID索引(O(1)撤单查找)。

2分钟详细回答：

数据结构选择需要考虑三个核心操作的时间复杂度：

TreeMap方案适合通用场景(价格范围大、证券数量多)。数组方案适合价格范围有限且tick size固定的场景(如股票价格0.01元为单位)。两种方案都需要注意缓存友好性——紧凑的内存布局比算法复杂度更重要。

追问准备：

• Q: 如何支持冰山单？
• A: 在Order中增加displayQty和totalQty字段。订单簿只按displayQty排序参与撮合，每次部分成交后自动"补充"显示数量。

---

学习资源

---

明日预告

Day 64: 资产管理系统架构

• 净值计算引擎(NAV)深度解析
• TA(Transfer Agent)系统设计
• 理财产品参数化(产品工厂)
• 智能投顾(Robo-Advisor)架构
• 资产托管系统概览