对于高频交易、数字货币交易所等金融场景，撮合引擎是决定系统生死存亡的核心。其本质诉求是矛盾的：既要追求内存级的极致处理速度，又要保证数据库级的状态持久化与数据不丢失。传统架构往往在二者间痛苦权衡。Intel Optane 持久内存（PMEM）作为一种颠覆性的硬件，为解决这一矛盾提供了全新的思路。本文将从第一性原理出发，剖析如何利用 PMEM 构建一个兼具纳秒级访问延迟和断电即恢复能力的撮合状态存储系统，并深入其在操作系统、CPU Cache 行为和工程实现中的关键细节。
现象与问题背景
一个典型的撮合引擎，其核心状态包括：买卖盘口（Order Book）、委托列表（Orders）、以及成交记录（Trades）。这些状态在内存中以高效数据结构（如红黑树、跳表或自定义数组）组织。每一笔新委托（Place Order）、撤单（Cancel Order）都必须原子性地修改这些状态，并保证在任何情况下（进程崩溃、机器宕机、断电）都不会丢失已确认的委托和成交。这是金融系统的生命线，即 RPO（Recovery Point Objective）必须为 0。
传统的解决方案通常有以下几种，但都存在固有缺陷：
- 内存撮合 + 异步日志/快照： 这是最常见的模式。撮合完全在 DRAM 中进行，速度极快。状态变更操作会写入一个内存队列，由独立线程异步刷到磁盘（如 Kafka、数据库 WAL 或本地文件）。这种方案的撮合延迟最低，但存在一个明确的数据丢失窗口。如果机器在日志刷盘前断电，最后几毫秒甚至几十毫秒的已确认交易将会丢失。RPO > 0。
- 内存撮合 + 同步日志： 为了实现 RPO=0，可以将日志刷盘操作改为同步。即，在向用户确认委托成功前，必须等待对应的日志记录成功写入磁盘。这引入了巨大的延迟。一次典型的 SSD `fsync` 操作可能耗时数百微秒到数毫秒，期间涉及系统调用、内核态/用户态切换、文件系统层、块设备层、DMA 传输等漫长路径，完全无法满足高频交易对延迟的要求。
- 基于数据库的撮合： 直接将盘口和委托存储在类似 MySQL 或专有数据库中。这种方案持久性得到了保证，但每次操作都涉及网络 I/O、SQL 解析、事务处理和磁盘 I/O，延迟是毫秒级别，吞吐量极低，仅适用于低频场景。
问题的本质在于，冯·诺依曼体系结构中，内存（DRAM）和外部存储（SSD/HDD）之间存在一道巨大的性能鸿沟。我们需要一种存储介质，它能像内存一样被 CPU 以字节粒度（byte-addressable）通过 `load/store` 指令直接访问，同时又具备像 SSD 一样的非易失性（non-volatile）。这正是 Intel Optane 持久内存（PMEM）所要解决的核心问题。
关键原理拆解
要真正理解 PMEM 的威力，我们必须回到计算机体系结构的基础。这部分内容，我将以一位大学教授的视角来阐述。
1. 存储层次结构与 PMEM 的定位
经典的存储层次结构（Memory Hierarchy）是一个金字塔，从上到下，速度递减，容量递增，成本递减：
- CPU 寄存器 (Registers) – 纳秒级（~1ns）
- CPU 缓存 (L1/L2/L3 Cache) – 纳秒级（~3-30ns）
- 主存 (DRAM) – 亚微秒级（~100ns）
- — 性能鸿沟 —
- 持久存储 (SSD/HDD) – 微秒到毫秒级（10μs – 10ms）
PMEM 被设计用来填充 DRAM 和 SSD 之间的鸿沟。它的延迟大约在 300-500ns 范围，比 DRAM 慢一个数量级，但比 NVMe SSD 快两个数量级。最关键的区别在于其访问模式：PMEM 挂载在内存总线上，CPU 可以像访问 DRAM 一样直接通过内存地址访问它，而无需经过 I/O 总线（如 PCIe）和复杂的内核存储栈。
2. App Direct Mode 与 DAX (Direct Access)
PMEM 有两种工作模式，但对我们有意义的是 App Direct Mode。在此模式下，操作系统将其识别为一个持久内存设备。通过在其上创建支持 DAX（Direct Access）的文件系统（如 ext4-dax 或 xfs-dax），应用程序可以通过 `mmap` 系统调用将 PMEM 的物理地址空间直接映射到自己的虚拟地址空间。这意味着，对这块内存的读写操作将完全绕过内核的 Page Cache 和块设备层，直接由 CPU 的 `load/store` 指令执行，数据直达 PMEM 控制器。这是实现低延迟持久化的基石。
3. 持久化的最后“一公里”：CPU Cache 的挑战
即便我们使用了 App Direct Mode，一个棘手的问题依然存在。当 CPU 执行一条 `mov` 指令向一个 PMEM 地址写入数据时，根据现代 CPU 的写回（Write-Back）缓存策略，该数据首先被写入 CPU 的 L1/L2/L3 Cache（这些都是 SRAM，是易失的）。数据并不会立即写入到 PMEM 介质。如果此时发生断电，CPU Cache 中的数据将全部丢失，持久化承诺被打破。
为了解决这个问题，我们需要确保数据被“冲刷”（flushed）出 CPU Cache，并真正到达持久化域（Persistence Domain）。Intel 提供了专门的指令集：
CLFLUSH/CLFLUSHOPT/CLWB(Cache Line Write Back): 这些指令用于将指定的 Cache Line（通常是 64 字节）从 CPU Cache 中驱逐出去，并确保其被写入内存控制器。CLWB是最优化的，它只写回数据而不使 Cache Line 失效，避免了后续读取时的 Cache Miss。SFENCE(Store Fence): 这是一个内存屏障指令。它确保在SFENCE之前的所有写操作都已完成，才能执行SFENCE之后的写操作。在持久化场景中，我们必须确保在执行 Cache Line Flush 指令后，这些 Flush 操作本身已经完成。因此，一个标准的持久化写操作序列是：`mov` -> `clwb` -> `sfence`。
理解这一点至关重要：在 PMEM 上实现真正的原子性和持久性，不仅是数据结构层面的问题，更是深入到 CPU 指令集和内存模型层面的底层工程。 幸运的是，Intel 提供了 PMDK (Persistent Memory Development Kit) 这样的库，为我们封装了这些复杂的底层操作。
系统架构总览
基于以上原理，我们来设计一个利用 PMEM 的单节点撮合引擎架构。为了突出 PMEM 的作用，我们暂时不考虑分布式一致性，先将单点的性能和可靠性做到极致。
这是一个文字描述的架构图：
- 接入层 (Gateway): 负责处理客户端的 TCP/FIX/WebSocket 连接，解析协议，并将标准化的委托请求放入一个无锁队列（如 Disruptor RingBuffer）。
- 定序器 (Sequencer): 从无锁队列中取出请求，为其分配一个全局单调递增的序列号（Transaction ID）。这个序列号是系统恢复和复制的基准。
- 撮合核心 (Matching Engine Core): 单线程运行，从定序器获取带序列号的请求，执行核心的撮合逻辑。这是系统的业务心脏。
- 持久化状态机 (Persistent State Machine): 这是我们的核心创新点。撮合引擎的所有状态（订单簿、账户余额等）都存放在由 `mmap` 映射的 PMEM 区域中。所有状态的修改都通过 PMDK 的事务性 API 来完成。
- 出向服务 (Egress Service): 负责将撮合结果（成交回报、委托确认）通过 Gateway 发送回客户端。
- 异步复制器 (Async Replicator): 撮合核心在完成一次 PMEM 事务提交后，会将该事务的操作日志（或变更数据）发布到另一个无锁队列。复制器线程消费此队列，将数据异步发送到备用节点或归档系统（如 Kafka），用于高可用（HA）和灾难恢复（DR）。
在这个架构中，关键路径（Critical Path） 是从 Gateway 接收请求，到撮合核心在 PMEM 中完成事务提交，再到向客户端发送确认。这个路径的延迟决定了系统的性能。由于 PMEM 的存在，我们可以在这个关键路径上实现同步持久化，同时将延迟控制在微秒级别。
核心模块设计与实现
现在，切换到极客工程师的视角，我们来看一些“脏活累活”，聊聊代码和坑。
1. PMEM 空间初始化与数据结构布局
你不能直接在 PMEM 上用 `new` 或者 `malloc`，也不能用 `std::map`。因为这些标准库所管理的内存和指针都是基于易失性内存设计的。重启之后，进程的虚拟地址空间完全不同，之前存储的绝对地址指针会全部失效，变成野指针，导致段错误。
正确的做法是使用 PMDK 中的 `libpmemobj`。它提供了一个基于对象和事务的持久内存池管理方案。
首先，你需要初始化一个持久内存池，它通常对应一个 `mmap` 的大文件。这个池子里会有一个“根对象”（Root Object），作为你所有持久化数据结构的入口。
#include <libpmemobj++/p.hpp>
#include <libpmemobj++/pool.hpp>
#include <libpmemobj++/transaction.hpp>
#include <libpmemobj++/make_persistent.hpp>
struct root {
// pmem::obj::p<> is a persistent-safe smart pointer
pmem::obj::p<MyOrderBook> buy_book;
pmem::obj::p<MyOrderBook> sell_book;
};
const char* LAYOUT = "matching_engine";
// On startup
auto pool_path = "/mnt/pmem0/engine_state";
pmem::obj::pool<root> pop;
try {
// Open existing pool, or create if it doesn't exist
pop = pmem::obj::pool<root>::open(pool_path, LAYOUT);
} catch (pmem::pool_error &e) {
pop = pmem::obj::pool<root>::create(pool_path, LAYOUT, PMEMOBJ_MIN_POOL);
}
auto proot = pop.root(); // Get the root object
这里的 `pmem::obj::p<>` 是一种特殊的智能指针，它存储的不是绝对虚拟地址，而是相对于内存池起始地址的偏移量。这样，即使程序重启，`mmap` 到了不同的虚拟地址，它依然可以通过 `偏移量 + 新的基地址` 的方式找到正确的对象。
2. 持久化事务与原子性保证
撮合引擎的任何一个操作，比如“下一个买单，吃掉两个卖单”，都可能涉及对多个数据结构的修改（从买单簿移除一个节点，从卖单簿修改两个节点，创建三条成交记录）。这些操作必须是原子的。`libpmemobj` 提供了事务机制来保证这一点。
下面是一个极度简化的“下市价买单”的伪代码，展示了事务的用法：
void process_market_buy_order(pmem::obj::pool_base &pop, pmem::obj::p<root> proot, const MarketOrder& order) {
try {
// Start a transaction
pmem::obj::transaction::run(pop, [&]{
uint64_t remaining_qty = order.quantity;
// Iterate through the sell order book (which should be a persistent data structure)
while (remaining_qty > 0 && !proot->sell_book->is_empty()) {
auto best_sell_order_node = proot->sell_book->get_min();
// Add the order to the transaction's undo log.
// If the transaction aborts, the change will be rolled back.
pmem::obj::transaction::snapshot(best_sell_order_node);
uint64_t matched_qty = std::min(remaining_qty, best_sell_order_node->qty);
// ... logic to create a persistent trade record ...
// auto trade = pmem::obj::make_persistent(...);
best_sell_order_node->qty -= matched_qty;
remaining_qty -= matched_qty;
if (best_sell_order_node->qty == 0) {
// Delete the order object from the persistent book
// pmem::obj::delete_persistent(best_sell_order_node);
}
}
// ... if there is remaining quantity, add a new buy order ...
}); // The transaction commits here. On success, all changes are flushed to PMEM.
} catch (pmem::transaction_error &e) {
// Handle transaction abort
}
}
关键点在于 `pmem::obj::transaction::run`。它创建了一个事务作用域。你在 lambda 表达式内部对持久内存的所有修改，都会被库自动记录到 undo log 中。当 lambda 正常结束时，事务提交。`libpmemobj` 在底层会自动调用 `clwb` 和 `sfence` 等指令，确保所有变更都安全地落到 PMEM 介质上。如果在执行过程中发生异常或进程崩溃，下次程序启动时，`libpmemobj` 会自动检测到未完成的事务，并利用 undo log 进行回滚，保证数据状态的一致性。
性能优化与高可用设计
对抗与权衡 (Trade-off)
- PMEM vs. DRAM + AOF (Append-Only File): PMEM 方案的端到端延迟通常更低且更稳定（低抖动）。传统方案中，即使是异步刷盘，磁盘 I/O 也会争用系统资源，可能导致毛刺。而同步刷盘的延迟则完全不可接受。PMEM 的写入延迟在亚微秒级，非常稳定。但其编程模型更复杂，对开发人员的要求更高。
- RTO (Recovery Time Objective) 对比: 这是 PMEM 的杀手锏。基于日志恢复的系统，RTO 取决于日志的大小，从几秒到几十分钟不等。而 PMEM 系统，恢复就是一次 `mmap` 操作，RTO 几乎为零。对于需要 7×24 小时运行的交易系统，这种近乎瞬时的恢复能力价值巨大。
- 成本: PMEM 每 GB 的价格高于 NVMe SSD，但远低于 DRAM。在需要大容量内存且对持久性有苛刻要求的场景下，它可能比“DRAM + 高速 SSD”的组合更具性价比。
高可用 (High Availability) 设计
PMEM 解决了单点故障（断电、进程崩溃）的问题，但无法解决整机硬件损坏或机房故障。因此，高可用依然是必需的。
一个可靠的 HA 方案是 主备复制 (Primary-Standby)。主节点（Primary）是前面描述的基于 PMEM 的撮合引擎。它在每次 PMEM 事务成功提交后，将该事务对应的逻辑操作日志（例如，“OrderID 123, MarketBuy, Qty 100”）通过低延迟网络（如 RDMA）发送给备用节点（Standby）。
备用节点同样可以部署 PMEM。它接收到日志后，在自己的 PMEM 状态机上回放这些操作。由于备机也是在内存中执行操作，回放速度非常快，可以紧密地跟随主机。当主机发生故障时，可以秒级切换到备机，由于备机状态几乎是同步的，对外业务影响极小。这种架构实现了 RPO=0 和极低的 RTO。
架构演进与落地路径
对于一个现有系统，直接切换到 PMEM 架构可能风险过高。一个务实的演进路径如下：
- 阶段一：现状评估与性能基线。 采用传统的内存撮合 + 异步日志架构。充分压测，明确其性能瓶颈、延迟分布以及在故障场景下的 RPO 和 RTO 数据。这是后续优化的基准。
- 阶段二：引入 PMEM 作为快速快照/恢复机制。 保持原有的 DRAM 撮合逻辑不变，但增加一个旁路功能：定期（如每秒）将内存中的完整状态（Order Book 等）以高效格式序列化并 dump 到 PMEM 中。这并不能实现 RPO=0，但可以将 RTO 从分钟级大幅缩短到秒级，因为恢复时只需从 PMEM 加载最新的快照，而无需回放大量日志。
- 阶段三：核心状态 PMEM 化。 这是最核心的一步。重构撮合引擎，将订单簿等核心数据结构迁移到 `libpmemobj` 管理的持久内存池中。将核心撮合逻辑改造为基于 PMEM 事务。此时，系统便具备了单点的 RPO=0 和近乎为零的 RTO。
- 阶段四：构建主备高可用。 在阶段三的基础上，增加主备复制逻辑，实现机器级的冗余和快速故障切换，最终形成一个在单点和整机层面都具备极高可靠性和恢复速度的现代化撮合系统。
总结而言，Intel Optane 持久内存并非简单地替换 SSD 或 DRAM，它是一种从根本上改变数据处理范式的技术。通过将持久化能力直接赋给内存，它消除了传统 I/O 路径上的巨大开销，使得构建同时满足极致低延迟和零数据丢失的系统成为可能。对于金融交易这类对性能和可靠性要求达到极致的领域，深入理解并掌握 PMEM 的原理与实践，将成为架构师手中一把强大的利器。
延伸阅读与相关资源
-
想系统性规划股票、期货、外汇或数字币等多资产的交易系统建设，可以参考我们的
交易系统整体解决方案。 -
如果你正在评估撮合引擎、风控系统、清结算、账户体系等模块的落地方式，可以浏览
产品与服务
中关于交易系统搭建与定制开发的介绍。 -
需要针对现有架构做评估、重构或从零规划，可以通过
联系我们
和架构顾问沟通细节，获取定制化的技术方案建议。