Rust 低延迟之交易引擎与 tick-to-trade

凌晨四点四十五,上海集合竞价开盘前两小时,你坐在 CFFEX 张江 COLO 机房旁的运维室。你是国内一家头部私募 Rust 团队的负责人,沪深300 ETF (510300.SH) 做市策略;L1、L2、L3 三课合并的成果是一个名为 trading-engine 的可跑二进制,策略组的研究员要昨晚通宵回归的直方图报告。终端上滚出来的一行:tick_to_trade ns P50=920 P99=3300 P99.9=14000 P99.99=55000 —— P99 是 3.3 µs,从一个 ITCH 包打到内核到你的下单经 tokio::net::TcpStream 飞向合成交易所回声任务的端到端时延。3.4.5 L4 的 C++ 引擎是 P99 大约 1-3 µs;差距主要来自 tokio 异步调度开销与 Instant::now() 测量本身的代价,而 Rust 版本拿到的安全优势 —— 借用检查器对 Vec<Order> 池每一次索引访问的静态校验 —— 是本课从头到尾用 safe Rust 的根本理由。L4 是 Module 3.5.3 的组合 capstone:全部原语汇聚成一个引擎,每一段都被 hdrhistogram 测量,每一行都不用 unsafe。

五组件架构

整体形态和 3.4.5 的 C++ 路径一致,用 Rust 惯用法重新封装。Feed handler:一个 tokio::spawn 出来的异步任务,持有 UdpSocket 与 L3 的 ItchDecoder。Book update:一个用 core_affinity 钉到某一核的同步线程,从 Arc<ArrayQueue<MdEvent>> 弹出 MdEvent 并修改 OrderBook。Strategy:与 book-update 同线程,每条事件读 inside-of-book、算一个最简 mid-quote 信号、把 OrderEvent 推入第二条 Arc<ArrayQueue<OrderEvent>>。Risk + router:一个 tokio::spawn 出来的任务,弹出 OrderEvent,过 RiskGate,把通过的订单经 tokio::net::TcpStream 序列化出去。Measurement:每阶段一份 hdrhistogram::Histogram<u64>,在事件上挂一个 LatencyTrace 收集阶段间时延。

委托簿:safe-Rust 数组式价格阶梯

委托簿是一条以 (price_ticks - min_price_ticks) 为下标、Vec<Level> 为底的数组式价格阶梯,加上以 Vec<Order> 为底、u32 为索引的自由链表 (freelist) 池。无裸指针、无 unsafe、无 Drop 仪式 —— 借用检查器在编译期就把 3.4.5 L1 当年靠人工 review 保的索引纪律证明了。Fenced 下面是本课其余部分依赖的数据结构定义:

use rustc_hash::FxHashMap;

#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum Side { Buy, Sell }

pub type OrderHandle = u32;

#[derive(Debug, Clone, Copy)]
pub struct Order {
    pub order_id:    u64,
    pub side:        Side,
    pub price_ticks: i32,
    pub qty:         u32,
    pub prev:        Option<OrderHandle>,
    pub next:        Option<OrderHandle>,
}

#[derive(Debug, Clone, Copy, Default)]
pub struct Level {
    pub qty_total: u64,
    pub head:      Option<OrderHandle>,
    pub tail:      Option<OrderHandle>,
}

pub struct OrderPool {
    storage:   Vec<Order>,
    free_head: Option<u32>,
}

impl OrderPool {
    pub fn new(capacity: usize) -> Self {
        let mut storage: Vec<Order> = (0..capacity).map(|i| Order {
            order_id: 0, side: Side::Buy, price_ticks: 0, qty: 0,
            prev: None,
            next: if i + 1 < capacity { Some((i + 1) as u32) } else { None },
        }).collect();
        let _ = &mut storage;
        Self { storage, free_head: if capacity > 0 { Some(0) } else { None } }
    }
    pub fn allocate(&mut self) -> Option<OrderHandle> {
        let h = self.free_head?;
        self.free_head = self.storage[h as usize].next;
        Some(h)
    }
    pub fn deallocate(&mut self, h: OrderHandle) {
        self.storage[h as usize].next = self.free_head;
        self.free_head = Some(h);
    }
    pub fn get(&self, h: OrderHandle) -> &Order { &self.storage[h as usize] }
    pub fn get_mut(&mut self, h: OrderHandle) -> &mut Order { &mut self.storage[h as usize] }
}

pub struct OrderBook {
    pub levels:           Vec<Level>,
    pub best_bid_idx:     usize,
    pub best_ask_idx:     usize,
    pub order_index:      FxHashMap<u64, OrderHandle>,
    pub pool:             OrderPool,
    pub min_price_ticks:  i32,
    pub num_ticks:        usize,
}

510300.SH 的参数:tick = 0.001 CNY,价格区间 [3.50, 5.00] CNY,1500 个 ticks 档位;OrderPool 容量 1_000_000 (与 3.4.5 L1 一致)。rustc_hash::FxHashMap 是 std::collections::HashMap 的快速非加密替代,与 Rust 编译器内部用的哈希表同源;它在国内一线 Rust 量化团队是默认选择,因为交易进程内根本不需要 SipHash 的加密硬化,而哈希耗费的每一纳秒都重要。add_order 的主体:从池里 allocate 一个 handle,按 (price_ticks - min_price_ticks) as usize 算 level 下标,把新单挂到该 level FIFO 的尾巴,更新 qty_total,塞进 order_index,如果新单开出新的 inside 则滚动 best_bid_idx 或 best_ask_idx;cancel_order 是对称的 unlink + deallocate。全程不用 unsafe。国内一线量化的 Rust 委托簿与这条架构基本一致,与 C++ 版本相比省下了大量 delete 与 Drop 顺序的人工 review 成本。

与 std::collections::BTreeMap 作底的参考委托簿相比,缓存热路径上 add_order / cancel_order 提速 10-20 倍,典型单次操作 5-10 ns。safe Rust 用一次 Vec 越界检查换安全,在紧循环里这条检查被优化器外提;借用检查器的成本是零运行时开销。这是一笔免费的安全网。

风控网关

每条订单出引擎前都过一遍 RiskGate。生产环境的四条检查按合约要求的顺序排列 —— kill-switch 第一,因为一旦触发必须瞬间停止一切;order-quantity 上限第二,因为 fat-finger 检查最便宜;position 限制第三,要做 current_position 算术;gross notional 限制第四,因为它是最贵的计算:

use std::sync::atomic::{AtomicBool, Ordering};

#[derive(Debug)]
pub enum RiskBreach {
    KillSwitch,
    OrderQtyExceedsLimit { requested: u32, limit: u32 },
    PositionLimit       { projected: i64, limit: i64 },
    NotionalLimit       { projected: f64, limit: f64 },
}

pub struct RiskGate {
    pub max_position_per_symbol: i64,
    pub max_gross_notional:      f64,
    pub max_order_qty:           u32,
    pub current_position:        i64,
    pub current_notional:        f64,
    pub kill_switch:             AtomicBool,
}

impl RiskGate {
    pub fn check(&mut self, order: &OrderEvent) -> Result<(), RiskBreach> {
        if self.kill_switch.load(Ordering::Acquire) {
            return Err(RiskBreach::KillSwitch);
        }
        if order.qty > self.max_order_qty {
            return Err(RiskBreach::OrderQtyExceedsLimit { requested: order.qty, limit: self.max_order_qty });
        }
        let signed = match order.side { Side::Buy => order.qty as i64, Side::Sell => -(order.qty as i64) };
        let projected = self.current_position + signed;
        if projected.abs() > self.max_position_per_symbol {
            return Err(RiskBreach::PositionLimit { projected, limit: self.max_position_per_symbol });
        }
        let projected_notional = self.current_notional + (order.qty as f64) * (order.price_ticks as f64);
        if projected_notional > self.max_gross_notional {
            return Err(RiskBreach::NotionalLimit { projected: projected_notional, limit: self.max_gross_notional });
        }
        Ok(())
    }
}

510300.SH 参数:max_position_per_symbol = 100_000 shares、max_gross_notional = 5_000_000 CNY、max_order_qty = 10_000 shares。四步顺序如下:

1. 先读 kill-switch ——kill_switch.load(Ordering::Acquire) 与监督线程发出的 store(true, Ordering::Release) 配对;一旦触发必须先停一切,再不进入后续检查。
2. 其次过单笔数量上限 —— order.qty 与 max_order_qty 比较是单条整数比较,代价最低,fat-finger 在此处被拦下。
3. 第三步过仓位限制 —— 算 current_position + signed,然后 projected.abs() 与每只合约的上限比较。
4. 最后过 gross notional —— 数量乘价格累加到 current_notional,最贵的算术放在最后,前面都过了才跑。

每次 breach 都要记录、计数、发指标;策略侧绝不静默丢弃。生产环境上还会叠加几层:父策略监督触发的 kill-switch、交易所端的保证金重算、跨账户聚合的合规网关 —— 全部点名,留给 3.5.4 与真实生产代码。

tick-to-trade 测量

四个标准测点:packet-arrived 在 recv_from 返回,book-updated 在 book 修改完之后,signal-computed 在 strategy 返回后,order-emitted 在 TCP 发送处。每个点采集一次 std::time::Instant::now(),以一个小 LatencyTrace 挂在事件上传过整条管道:

use std::time::Instant;
use hdrhistogram::Histogram;

#[derive(Debug, Clone, Copy)]
pub struct LatencyTrace {
    pub t_packet_arrived: Instant,
    pub t_book_updated:   Option<Instant>,
    pub t_signal_computed: Option<Instant>,
    pub t_order_emitted:  Option<Instant>,
}

pub struct LatencyReporter {
    pub feed_to_book:     Histogram<u64>,   // ns; t_book - t_packet
    pub book_to_signal:   Histogram<u64>,   // ns; t_signal - t_book
    pub signal_to_order:  Histogram<u64>,   // ns; t_order - t_signal
    pub tick_to_trade:    Histogram<u64>,   // ns; t_order - t_packet
}

impl LatencyReporter {
    pub fn new() -> Self {
        // 1 ns to 60 s with 3 significant digits of precision.
        let new_hist = || Histogram::<u64>::new_with_bounds(1, 60_000_000_000, 3).unwrap();
        Self {
            feed_to_book:    new_hist(),
            book_to_signal:  new_hist(),
            signal_to_order: new_hist(),
            tick_to_trade:   new_hist(),
        }
    }
    pub fn record(&mut self, tr: &LatencyTrace) {
        if let (Some(tb), Some(ts), Some(to)) = (tr.t_book_updated, tr.t_signal_computed, tr.t_order_emitted) {
            self.feed_to_book.record((tb - tr.t_packet_arrived).as_nanos() as u64).ok();
            self.book_to_signal.record((ts - tb).as_nanos() as u64).ok();
            self.signal_to_order.record((to - ts).as_nanos() as u64).ok();
            self.tick_to_trade.record((to - tr.t_packet_arrived).as_nanos() as u64).ok();
        }
    }
    pub fn report(&self) {
        for (name, h) in [("feed_to_book", &self.feed_to_book), ("book_to_signal", &self.book_to_signal), ("signal_to_order", &self.signal_to_order), ("tick_to_trade", &self.tick_to_trade)] {
            println!("{name:>18} ns  P50={} P99={} P99.9={} P99.99={}", h.value_at_quantile(0.50), h.value_at_quantile(0.99), h.value_at_quantile(0.999), h.value_at_quantile(0.9999));
        }
    }
}

hdrhistogram::Histogram<u64>::new_with_bounds(1, 60_000_000_000, 3) 配置从 1 ns 到 60 s、3 位有效数字精度的直方图 —— 生产标准配置。HdrHistogram 算法提供 O(1) 写入、O(log n) 分位查询、有界相对误差;生产法则是「用 HdrHistogram,不要自己造分位计算,不要用滑动窗口均值 —— 均值在尾部撒谎」。Instant::now() 在 Ice Lake-SP 上一次大约 25 ns,落在 5-50 µs 预算里完全可接受,但一旦推向亚微秒就是错误原语;那时要换成硬件 NIC 时间戳加 PTP 同步时钟,归 3.6.6。

接线

tokio::main 的形态把五个任务连起来。多线程 runtime 四个 worker;一条 Arc<ArrayQueue<MdEvent>> 共享 L3 到 strategy 的跳,一条 Arc<ArrayQueue<OrderEvent>> 共享 strategy 到 router 的跳;book + strategy 跑在一个同步 OS 线程上,钉到指定核:

use std::sync::Arc;
use std::sync::atomic::AtomicU64;
use crossbeam_queue::ArrayQueue;
use tokio::net::{TcpStream, UdpSocket};

#[tokio::main(flavor = "multi_thread", worker_threads = 4)]
async fn main() -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    // Shared queues.
    let md_queue:    Arc<ArrayQueue<MdEvent>>    = Arc::new(ArrayQueue::new(1024));
    let order_queue: Arc<ArrayQueue<OrderEvent>> = Arc::new(ArrayQueue::new(256));
    let lost_md:     Arc<AtomicU64> = Arc::new(AtomicU64::new(0));

    // 1. Feed-handler task on CPU 3.
    let feed_socket = UdpSocket::bind("0.0.0.0:30001").await?;
    feed_socket.join_multicast_v4("239.0.0.1".parse()?, std::net::Ipv4Addr::UNSPECIFIED)?;
    let md_q = Arc::clone(&md_queue);
    let lost_md_c = Arc::clone(&lost_md);
    let feed_handle = tokio::spawn(async move {
        // pin to CPU 3 (set via core_affinity inside the task in the exercise)
        run_feed_handler(feed_socket, md_q, lost_md_c).await
    });

    // 2 + 3. Book-update + strategy on a dedicated thread pinned to CPU 2.
    let md_q = Arc::clone(&md_queue);
    let ord_q = Arc::clone(&order_queue);
    let book_thread = std::thread::Builder::new().name("book+strategy".into()).spawn(move || {
        let core_ids = core_affinity::get_core_ids().unwrap();
        core_affinity::set_for_current(core_ids[2]);
        run_book_and_strategy(md_q, ord_q);
    })?;

    // 4. Risk + router task on CPU 4.
    let ord_q = Arc::clone(&order_queue);
    let exchange = TcpStream::connect("127.0.0.1:40001").await?;
    let router_handle = tokio::spawn(async move {
        run_router(ord_q, exchange).await
    });

    // Shutdown on Ctrl-C; dump LatencyReporter on the way out.
    tokio::signal::ctrl_c().await?;
    let _ = (feed_handle, router_handle, book_thread);
    Ok(())
}

同步的 book+strategy 线程不用 tokio::spawn,因为热路径要直接掌控调度;tokio runtime 在网络边缘很好,但你不希望它对你的 book 修改做协作式调度。core_affinity::set_for_current(core_ids[2]) 把线程钉到 CPU 2,让这一核的 L1d 一直是 book 的热数据;3.4.3 / 3.4.4 已经介绍的内核引导参数 isolcpus=2-7 nohz_full=2-7 rcu_nocbs=2-7 把调度器从这些核上完全踢开,使 strategy 线程不被任何中断或迁移打扰,这是国内一线量化在 colo 机房调优的标准做法。

生产部署

下面的 Cargo.toml 与构建标志是国内一线量化部署 Rust 引擎的基线;版本钉、profile 设置、env-var、启动命令在两区版本上是逐字节一致的,因为这套纪律是普适的:

# Cargo.toml additions
[dependencies]
tokio              = { version = "1", features = ["full"] }
tokio-util         = { version = "0.7", features = ["codec"] }
tokio-stream       = "0.1"
bytes              = "1"
crossbeam-queue    = "0.3"
crossbeam-utils    = "0.8"
core_affinity      = "0.8"
hdrhistogram       = "7"
rustc-hash         = "1"
thiserror          = "1"

[profile.release]
opt-level     = 3
lto           = "fat"
codegen-units = 1
panic         = "abort"

# Production build invocation
$ RUSTFLAGS="-C target-cpu=native -C codegen-units=1 -C lto=fat" cargo build --release

# Kernel-side discipline (reused from 3.4.3 / 3.4.4)
# /etc/default/grub:
#   GRUB_CMDLINE_LINUX="... isolcpus=2-7 nohz_full=2-7 rcu_nocbs=2-7"
#
# Production launch
$ taskset -c 2-7 numactl --cpunodebind=0 --membind=0 chrt --rr 99 ./target/release/trading-engine

opt-level = 3 加 lto = "fat" 加 codegen-units = 1 加 panic = "abort" 是四行咒语;target-cpu=native 在构建机上启用 AVX2 / AVX-512 / BMI2 / FMA,但产物只能在同微架构或更新的 CPU 上跑 —— 仅在构建与部署目标完全匹配时使用。cargo pgo 做 profile-guided optimisation (插桩构建 → 代表性工作负载跑一遍 → 优化构建,分支密集代码典型 5-15% 收益) 此处点名,前向指针到 3.5.4 / 3.6.5。tikv-jemallocator crate 把 #[global_allocator] 换成 jemalloc,是长时间运行服务进程的标准选择,镜像 C++ 侧的 LD_PRELOAD=libjemalloc.so;本课不实操,仅点名供参考。

LatencyReporter::report 在调好的开发机上预期的输出形态;阶段标签与百分位列头在两区版本上是逐字节一致的,数字仅作示意:

       feed_to_book ns  P50=320 P99=1100 P99.9=4500 P99.99=18000
     book_to_signal ns  P50=180 P99=750  P99.9=3100 P99.99=12000
    signal_to_order ns  P50=420 P99=1500 P99.9=6800 P99.99=25000
      tick_to_trade ns  P50=920 P99=3300 P99.9=14000 P99.99=55000

tick-to-trade 的生产预算:tokio + crossbeam_queue + safe-Rust 价格阶梯,调优后大约 5-50 µs;亚微秒只在内核旁路 NIC 加 DPDK 或 AF_XDP 加手写无锁队列加 L1 常驻热路径的极端栈上能做到 —— 那是 3.5.4 与生产现场的料。本课的 Rust 引擎落在覆盖 90% 低延迟量化工作负载的微秒区间。后续生产的前向指针:PyO3 (与研究环境的 Python 互通) 在 3.5.4 L2;bindgen / cxx (与 C / C++ 互通,继承已有策略代码) 在 3.5.4 L3;完整 FIX 4.4 会话状态机在 3.5.4 L4;跨交易所 / Smart Order Routing 在进阶阅读;硬件 NIC 时间戳与 PTP 同步时钟在 3.6.6 Observability & System Design;内核旁路 DPDK / AF_XDP / tokio-uring 在 3.5.4 与进阶阅读;部署 / 容器化 / SRE 值班 runbook 在 3.6.5 / 3.6.6。

本课硬件锚点继续沿用 L1 / L2 / L3 的 Intel Xeon Gold 6342 (Ice Lake-SP, 24 核) 配 Rocky Linux 9 或 Ubuntu 22.04 LTS,部署在 CFFEX 张江 / SSE 浦东 / SZSE 福田 COLO 机房;策略线程钉 CPU 2,feed-handler 任务钉 CPU 3,router 任务钉 CPU 4。该硬件在国内一线量化的 Rust 引擎实测下 tick-to-trade P99 通常落在 2-8 µs,与 3.4.5 L4 的 C++ 1-3 µs P99 相比慢 2-3 倍,主要差距在 tokio 异步层调度开销与 Instant::now() 采样成本,这两项在 3.5.4 用 tokio-uring 与硬件时间戳进一步压窄。

课后阅读:《Rust for Rustaceans》第 10 章 async 设计与第 11 章 unsafe (英文);《Rust Atomics and Locks》(marabos.nl/atomics) 第 8-9 章 OS 原语 (英文);HdrHistogram 论文与 docs.rs/hdrhistogram/ 文档;docs.rs/core_affinity/ 与 docs.rs/tikv-jemallocator/;CppCon 2017 演讲 'When a Microsecond Is an Eternity' (英文,架构决策语言无关);《Trading and Exchanges》(中文译本《交易与交易所》);《Market Microstructure Theory》(英文,微结构基础);3.4.5 L1 / L2 / L3 / L4 各课的阅读清单与本课参考完全一致 (架构同源,语言不同);国内一线量化 (幻方 / 鸣熙 / 九坤 / 明汯 / 灵均) 与 PingCAP TiKV / 火山引擎 / 字节跳动等 Rust 团队在 InfoQ 中文站 / 公众号上的生产 Rust 经验分享,以及 纳斯达克 TotalView ITCH 5.0 spec (英文公开,L3 已引用)。

Exercise

行业背景

国内做完整 Rust 交易引擎的私募与自营头部:幻方、鸣熙、九坤、明汯、灵均、宽德、思勰、衍盛、磐松资管、博普科技、宁聚资产、致诚卓远、英仕曼中国、上海致远启盛、衍盛资产、宁聚资产、千衍资产、思勰投资、聚宽量化;券商自营线包括中信证券、中信建投、华泰证券、海通证券、招商证券、国泰君安、中金公司、广发证券、东方证券、华泰资管、海通资管、银河证券、中信资管、申万宏源。生产中触及的标的:510300.SH、510500.SH、510050.SH、510880.SH、159915.SZ、159928.SZ、159949.SZ、510900.SH、IF / IC / IH / IM 股指期货、TS / TF / T 国债期货、SC 上海原油、SHFE 上期所的螺纹钢 / 铜 / 黄金 / 白银 / 镍 / 锌 / 铝、CZCE 郑商所的 PTA / OI / SR / CF、DCE 大商所的豆粕 / 铁矿石 / 焦炭 / 焦煤 / 棕榈油、INE 上期能源中心。下游清算与监管面:中国证监会、上海证券交易所、深圳证券交易所、中国金融期货交易所、上海期货交易所、郑州商品交易所、大连商品交易所、上海国际能源交易中心、中国证券登记结算公司、上海清算所、中国期货市场监控中心、国家税务总局。

通向 Module 3.5.4 的桥

到这里你拥有了一个可跑、被测量、全 safe-Rust 的交易引擎:五组件架构、Vec<Order> 池支撑的 safe-Rust OrderBook、四步 RiskGate、tokio 路由配测量的 TCP 路径、给出每阶段 P50 / P99 / P99.9 / P99.99 的 hdrhistogram::Histogram<u64> reporter。Module 3.5.4 接着进入互操作与生产部署层:PyO3 接到研究环境的 Python、bindgen 与 cxx 接到既有 C / C++ 策略代码、完整 FIX 4.4 会话状态机、tokio-uring 与 AF_XDP 与 DPDK 等内核旁路追求亚微秒、profile-guided optimisation,以及把二进制变成持续生产部署的 SRE 值班 runbook。3.5.3 让你养成的纪律 —— 先测量、按缓存铺数据、有意识选队列、用 tokio_util::codec 解 wire、每段都用 hdrhistogram 计时 —— 让 3.5.4 那些主题是精细化而不是重写。