本文面向具备一定分布式系统和底层技术认知的中高级工程师，深入剖析金融交易系统中做市商（Market Maker）报价机制的实现。我们将跳过概念性介绍，直接从系统面临的极端性能与并发挑战切入，逐层拆解其背后的计算机科学原理、核心模块实现、架构权衡与演进路径，揭示在高频、海量的报价更新场景下，一个健壮的交易系统是如何在延迟、吞吐和稳定性之间取得精妙平衡的。
现象与问题背景
在任何一个成熟的金融市场，无论是股票、期货还是数字货币，流动性都是其生命线。做市商的核心职责就是通过持续提供双边报价（同时报出买价和卖价）来创造流动性。然而，这种行为对交易系统的技术架构提出了与处理普通零售订单（Retail Order）截然不同的挑战。
一个典型的零售用户可能会在一天内提交几次到几十次订单，这些订单通常是独立的、低频的。而一个活跃的做市商，尤其是在算法驱动的高频交易（HFT）场景下，可能会针对单一交易对（例如 BTC/USDT）在一秒钟内提交数百甚至数千次报价更新。市场价格每波动一次，做市商的定价模型就会重新计算，并立即撤销旧报价、提交新报价。这种行为模式会产生以下几个致命的工程问题：
- 网络与网关风暴：如果每次报价更新都遵循传统的“先发撤单请求（OrderCancelRequest），再发新订单请求（NewOrderSingle）”模式，网络流量和消息处理量将放大一倍。成千上万的做市商策略并发运行时，足以压垮撮合引擎的入口网关。
- 撮合引擎过载：撮合引擎的核心数据结构，通常是基于价格优先、时间优先的订单簿（Order Book），其插入和删除操作虽然在算法上可以优化到 O(log N)，但在巨大的更新频率下，持续的写操作会导致锁竞争加剧、CPU 缓存失效，最终导致撮合延迟急剧上升，影响整个市场的公平性。
- 状态不一致风险：在“先撤后报”的模式中，存在一个微小的时间窗口，做市商在市场中没有任何报价，这违反了其“持续报价”的做市义务。反之，如果“先报后撤”，则可能出现新旧报价共存，导致非预期的成交（例如，与自己的旧报价成交），或占用过多保证金。
- 高昂的“无效操作”成本：做市商的报价通常集中在买一卖一价（BBO）附近。当市场价格变化时，可能其 95% 的深度报价（deep quotes）并不需要改变，改变的只是最靠近中间价的几个档位。如果每次都全量撤销再全量提交，就是巨大的资源浪费。
因此，设计一个专门的做市商报价处理机制，不再是锦上添花的功能，而是决定一个交易所能否进入专业和高频领域的生死线。
关键原理拆解
要解决上述问题，我们不能简单地堆砌服务器或增加网络带宽，必须回到计算机科学的基础原理，从数据结构、协议设计和并发模型上进行重构。这背后的思想，可以类比于操作系统内核对进程调度的优化，或是数据库系统从行锁到意向锁的演进——都是为了在宏观上提升系统效率。
（大学教授视角）
1. 数据结构与算法：从“个体操作”到“批量与增量”
传统的订单簿，无论是用平衡二叉树（如红黑树）还是跳表实现，其设计哲学是面向单个订单的原子操作。这在处理做市商报价时显得“颗粒度”过粗。核心的优化思想是将一个做市商在某个交易对上的所有报价视为一个逻辑整体（Quote Set）。系统不再关心单个 `quoteId` 的生灭，而是关心这个 `QuoteSet` 状态的变迁。这种抽象带来了算法上的飞跃：我们可以对新旧两个 `QuoteSet` 状态进行 **差分比较（Diff）**，计算出需要被执行的最小操作集（Delta）。这本质上是一种状态同步思想，时间复杂度从 O(M log N)（M 为报价数量）转变为 O(M) 的比较加上 O(K log N) 的更新（K 为实际变化的报价数量，通常 K << M）。这极大地降低了对核心订单簿的写压力。
2. 网络协议：减少序列化与网络往返开销
标准的 FIX 协议虽然通用，但其基于文本的特性带来了巨大的序列化和反序列化开销。对于高频场景，一个字节都弥足珍贵。因此，高性能交易所通常会提供专有的二进制协议。更重要的是，协议本身需要支持批量操作。FIX 协议中的 `Mass Quote` (MsgType=i) 消息就是为此而生。它允许在单个消息中包含多个报价条目（`QuoteEntry`），并定义了每个条目的状态（`New`, `Cancel`, `Modify`）。通过一个网络数据包提交一个完整的报价快照，极大地减少了网络 I/O 的调用次数和 TCP/IP 协议栈的开销。从操作系统的角度看，这意味着更少的 `send()` / `recv()` 系统调用，从而减少了用户态与内核态之间的上下文切换，这是微秒级延迟优化的关键一步。
3. 并发模型：单线程核心与事件溯源
撮合引擎的核心逻辑——订单匹配，为了避免复杂的锁机制带来的性能抖动和不确定性，业界公认的最佳实践是单线程模型。一个交易对的订单簿只由一个线程来操作。这保证了所有操作的严格串行化和确定性，排除了并发引入的各类数据竞争问题。然而，如何将外部并发的报价请求喂给这个单线程核心呢？LMAX Disruptor 框架所推广的 Ring Buffer 是一种高效的实现。它是一个无锁的、基于 CAS (Compare-And-Swap) 原子操作的生产者-消费者队列。外部的 I/O 线程（生产者）将解析后的报价请求放入 Ring Buffer，撮合核心线程（消费者）以极低的延迟批量消费。这种模型本质上是事件溯源（Event Sourcing）思想的体现：系统状态的每一次变迁，都是由一个不可变的事件（报价更新请求）驱动的。
4. 操作系统与硬件亲和性：追求“机械共振”
在极致的性能要求下，我们必须考虑代码如何与底层硬件协同工作，即所谓的“机械共振”（Mechanical Sympathy）。这意味着：
- CPU Cache 优化：频繁访问的数据，如订单簿的顶部节点、做市商的报价集合，应设计得尽可能小且在内存中连续存放，以提高 CPU Cache 命中率。避免不必要的指针跳转，因为这会导致缓存行失效（Cache Miss），带来上百个时钟周期的惩罚。
- 内存管理：避免在交易处理的关键路径上进行动态内存分配（如 `malloc` / `new`）。这会引入不可预测的延迟，甚至触发系统调用，造成性能抖动。通常采用预分配的内存池（Memory Pool）或对象池（Object Pool）技术。
- 线程绑定与 NUMA 架构：将处理特定交易对的撮合线程绑定到固定的 CPU 核心（CPU Affinity），可以避免线程在不同核心间切换带来的缓存失效。在多处理器的 NUMA (Non-Uniform Memory Access) 架构下，还应确保线程访问的内存位于其本地节点，避免跨节点内存访问的高昂延迟。
系统架构总览
一个支持高效做市商报价的交易系统，其架构通常由以下几个协同工作的组件构成，我们可以通过描述一次报价流程来串联它们：
一个做市商的量化策略程序通过专线连接到交易所的 **Quote Gateway（报价网关）**。这个网关是专门为做市商流量设计的，可能采用二进制协议，并部署在与做市商服务器物理位置极近的机房。网关收到一个 `MassQuote` 消息后，进行快速的协议解析和基础验证。
验证通过后，消息不会直接发往撮合引擎，而是被送入一个名为 **Quoting Engine（报价引擎）** 的中间件。这是整个设计的核心。报价引擎内部维护了每个做市商在每个交易对上的当前报价状态（`QuoteSet`）。
报价引擎收到新的 `MassQuote` 消息后，会执行前述的“增量变更（Delta）”计算。它会与内存中存储的该做市商的上一份报价进行比对，生成一份精确的指令集，例如：`{cancel_ids: [1001, 1002], add_orders: [{price: 10.0, qty: 5}, {price: 9.9, qty: 8}]}`。这份指令集被封装成一个内部的原子事务事件。
这个原子事件被投递到 **Matching Engine（撮合引擎）** 的输入队列（例如前述的 Ring Buffer）。撮合引擎的核心逻辑线程消费此事件，在一个事务中先执行所有撤单操作，再执行所有新增订单操作。由于这是在一个单线程内完成的，整个过程天然具备原子性，杜绝了状态不一致的风险。
撮合引擎完成操作后，产生的结果（如成交回报、订单确认）会通过消息总线（如 Kafka 或专有的低延迟消息系统）分发给下游，包括行情发布系统、清结算系统以及返回给做市商的执行回报（Execution Report）。
此外，整个链路还串联着一个 **Pre-Trade Risk Engine（事前风控引擎）**，它以极低的延迟检查报价是否符合风控规则（如价格偏离、持仓上限等），这是保障系统安全的关键一环。
核心模块设计与实现
（极客工程师视角）
1. Quote Gateway 与协议设计
别用 JSON/HTTP，那是给后台管理系统用的。在这里，每一纳秒都算数。我们通常会基于 SBE (Simple Binary Encoding) 或 Protobuf 设计自己的二进制协议。关键是 `MassQuote` 消息体的设计。
// 伪代码示例：一个简化的 MassQuote 消息结构体
type MassQuoteMessage struct {
MarketMakerID uint64
InstrumentID uint32
QuoteSetID uint64 // 用于标识一整批报价，方便追踪和幂等
Entries []QuoteEntry
}
type QuoteEntry struct {
QuoteID uint64 // 客户端侧的ID，用于做市商自我管理
Price int64 // 定点数表示价格，避免使用 float 带来的精度和性能问题
Quantity int64
Side byte // 0 for Bid, 1 for Ask
}
注意，这里的 `Price` 和 `Quantity` 强烈建议使用 `int64` 存储定点数，比如把价格 `123.45` 存储为 `1234500`。浮点数运算在某些 CPU 架构上比整数慢，更重要的是它有精度问题，在金融计算中是灾难。这个网关必须是无状态的，可以水平扩展，前面用 LVS 或者 F5 做负载均衡。
2. Quoting Engine 的增量算法
这才是真正的“黑魔法”所在。报价引擎的核心是一个巨大的多级哈希表，类似 `map[MarketMakerID]map[InstrumentID]*QuoteSet`。`QuoteSet` 里存着当前该做市商的所有有效报价。
当收到一个新的 `MassQuoteMessage` 时，核心逻辑如下：
// 伪代码：处理报价更新并计算 Delta
type QuoteSet struct {
Bids map[int64]uint64 // map[price]orderID
Asks map[int64]uint64
}
// quotesInMemory: map[marketMakerID]map[instrumentID]*QuoteSet
// newMassQuote: 刚收到的报价消息
func (qe *QuotingEngine) processUpdate(newMassQuote *MassQuoteMessage) {
// 1. 获取当前内存中的报价状态
currentSet := quotesInMemory[newMassQuote.MarketMakerID][newMassQuote.InstrumentID]
if currentSet == nil {
currentSet = &QuoteSet{Bids: make(map[int64]uint64), Asks: make(map[int64]uint64)}
}
// 2. 将新的报价列表转成方便查找的 map
newBids := make(map[int64]bool)
newAsks := make(map[int64]bool)
for _, entry := range newMassQuote.Entries {
if entry.Side == BID {
newBids[entry.Price] = true
} else {
newAsks[entry.Price] = true
}
}
// 3. 计算 Delta：需要撤销的订单
toCancelIDs := make([]uint64, 0)
for price, orderID := range currentSet.Bids {
if !newBids[price] {
toCancelIDs = append(toCancelIDs, orderID)
}
}
for price, orderID := range currentSet.Asks {
if !newAsks[price] {
toCancelIDs = append(toCancelIDs, orderID)
}
}
// 4. 计算 Delta：需要新增的订单
toAddOrders := make([]NewOrderParams, 0)
for _, entry := range newMassQuote.Entries {
var currentOrders map[int64]uint64
if entry.Side == BID {
currentOrders = currentSet.Bids
} else {
currentOrders = currentSet.Asks
}
if _, exists := currentOrders[entry.Price]; !exists {
toAddOrders = append(toAddOrders, NewOrderParams{
Price: entry.Price,
Quantity: entry.Quantity,
Side: entry.Side,
// ... 其他参数
})
}
}
// 5. 构建原子事务并发送给撮合引擎
tx := &AtomicQuoteTransaction{
CancelOrderIDs: toCancelIDs,
NewOrders: toAddOrders,
}
qe.matchingEngineChannel <- tx
// 6. 更新内存中的状态（在撮合引擎确认后执行更安全）
// ... 更新 quotesInMemory ...
}
这个 `processUpdate` 函数是系统性能的热点。它的实现必须极度高效，避免任何不必要的内存分配和拷贝。实践中，为了避免哈希冲突带来的性能抖动，对性能要求极致的系统可能会使用定制的、对 CPU 缓存更友好的数据结构来代替原生的 `map`。
性能优化与高可用设计
在工程实践中，理论上的完美设计会遇到无数现实的挑战。
- 热点交易对问题：系统中总有几个交易对（如 BTC/USDT, ETH/USDT）的交易量远超其他。这意味着处理这几个交易对的撮合线程会成为瓶颈。解决方案是将不同的交易对分配到不同的物理服务器或进程上，实现水平扩展。这种基于 `InstrumentID` 的 Sharding 是交易系统水平扩展的基础。
- GC 停顿：对于使用 Go 或 Java 这类带垃圾回收（GC）语言的系统，GC 停顿是延迟的头号敌人。在核心交易链路上，必须严格控制对象创建，力求“零 GC”。这需要大量使用对象池、预分配内存、甚至使用 `off-heap` 内存技术。或者，像许多顶级交易所那样，核心模块使用 C++ 或 Rust 编写，手动管理内存，从根源上消除 GC 问题。
- 高可用与数据一致性：撮合引擎是单点，如何实现高可用？通常采用主备（Active-Passive）模式。主节点处理所有交易，并将所有输入事件（已经序列化的请求）通过可靠的通道（如 Aeron 或专有复制协议）同步给备用节点。备用节点以完全相同的顺序重放这些事件，从而保持与主节点完全一致的内存状态。当主节点宕机时，可以秒级切换到备用节点。这个过程非常类似数据库的物理复制（Physical Replication）。绝对不能使用数据库作为撮合引擎的状态存储，磁盘 IO 的延迟对于撮合引擎来说是不可接受的。
- 网络优化：除了协议本身，网络传输路径的优化也至关重要。使用内核旁路（Kernel Bypass）技术如 DPDK 或 Solarflare 的 OpenOnload，可以让应用程序直接读写网卡硬件，绕过操作系统的网络协议栈，将网络延迟从几十微秒降低到几微秒。当然，这需要昂贵的硬件支持和极高的技术门槛。
架构演进与落地路径
一口气吃不成胖子。一个支持高效做市的交易系统也不是一天建成的。其演进路径通常遵循以下阶段：
第一阶段：兼容模式（MVP）
系统初期，没有专门的报价接口。做市商也被当作普通用户，通过标准的 `NewOrderSingle` 和 `OrderCancelRequest` 接口提交报价。系统为他们提供更高的 API 调用频率限制。这种方式实现简单，能快速上线，但性能瓶颈很快就会到来，仅适用于业务启动初期。
第二阶段：引入 Mass Quote 接口和原子操作
实现 `Mass Quote` 消息类型和后台的原子化“先撤后报”逻辑。此时可能还没有独立的 Quoting Engine，相关逻辑内嵌在撮合引擎进程中。这解决了做市商操作的原子性问题，并初步降低了网络开销。这是从“能用”到“好用”的关键一步，能满足大部分中等频率做市商的需求。
第三阶段：独立的报价引擎（Quoting Engine）
随着做市商数量和策略复杂度的增加，报价处理逻辑本身成为瓶颈。此时，需要将其拆分为独立的微服务——Quoting Engine。它与撮合引擎解耦，可以通过低延迟的 IPC（进程间通信，如共享内存）或高性能消息队列（如 Aeron UDP）通信。Quoting Engine 可以独立扩缩容，专门优化报价状态管理和增量计算，而撮-合引擎则更专注于核心的订单匹配，职责分离，架构更清晰。
第四阶段：极致优化与硬件加速
对于顶级交易所，竞争已经进入微秒甚至纳秒级别。此时演进的方向是软硬件一体化。
- 将无状态且计算密集的任务，如协议解析、风控规则校验等，下沉到 FPGA (现场可编程门阵列) 上完成，实现线速处理。
– 采用精准的时间同步协议（PTP）保证所有服务器时钟纳秒级同步，为事件打上精确的时间戳，确保公平性。
– 在物理层面，通过主机托管（Co-location）服务，允许做市商将他们的服务器部署在与交易所撮合引擎同一个机柜中，将网络延迟降到物理极限。
这条演进路径清晰地展示了技术架构是如何随着业务需求和竞争格局的升级而不断深化的。从一个简单的订单处理系统，到一个能够承载全球顶级做市商海量高频报价的复杂、精密、且极度低延迟的金融基础设施，每一步演进都是对技术深度和工程能力的巨大考验。
延伸阅读与相关资源
-
想系统性规划股票、期货、外汇或数字币等多资产的交易系统建设，可以参考我们的
交易系统整体解决方案。 -
如果你正在评估撮合引擎、风控系统、清结算、账户体系等模块的落地方式，可以浏览
产品与服务
中关于交易系统搭建与定制开发的介绍。 -
需要针对现有架构做评估、重构或从零规划，可以通过
联系我们
和架构顾问沟通细节，获取定制化的技术方案建议。