风暴眼中的坚守：基于 Intel Optane 持久内存的低延迟撮合引擎状态存储实践

作者： /

对于任何一个高性能交易系统，尤其是股票、期货或数字货币的撮合引擎而言，其架构设计的核心矛盾始终在于速度与一致性（持久化）之间的权衡。传统方案中，为了追求极致的低延迟，订单簿（Order Book）等核心状态必须全量置于内存（DRAM）中；而为了保证系统崩溃后状态不丢失，又必须通过网络复制或磁盘日志（WAL）等方式进行持久化。本文面向有经验的系统架构师和工程师，将深入剖析一种颠覆性的技术——Intel Optane 持久内存（PMEM），探讨其如何打破这一经典困境，在提供接近 DRAM 性能的同时，实现纳秒级的硬件级持久化，并给出从原理、实现到架构演进的完整路径。

现象与问题背景

在一个典型的撮合交易系统中，当一笔新订单（如“买入 100 股 XYZ，价格不高于 10.05”）进入系统时，引擎需要执行一系列原子操作：验证订单、在订单簿中找到相应价位、匹配已有对手单、生成成交回报（Trade）、更新订单簿状态。这个过程必须在微秒甚至更短的时间内完成。延迟每增加一毫秒，都可能意味着巨大的商业损失。

为了实现这种速度，状态（整个市场的买卖盘订单簿）必须存在于 DRAM。但 DRAM 是易失性存储，一旦断电或系统崩溃，所有数据将瞬间消失。这就引出了持久化的“经典两难”：

  • 方案一：基于磁盘的 WAL (Write-Ahead Logging)

    在内存状态变更前，先将操作（如“新增订单”、“取消订单”）序列化成日志，写入磁盘。这是数据库领域的经典做法。但在交易场景下，瓶颈是致命的：写日志涉及系统调用（`write()`），最终需要 `fsync()` 来确保数据落盘。`fsync()` 会触发内核态切换、I/O 调度、DMA 传输，并最终等待磁盘控制器返回确认。即使使用顶级的 NVMe SSD，一次 `fsync()` 的延迟也通常在数百微秒到数毫秒级别，这对于高频撮合引擎来说是完全无法接受的。

  • 方案二：基于网络的状态复制

    采用主备（Primary-Backup）模式，主节点在处理完请求后，通过网络将状态变更或操作日志同步给备用节点。这同样存在问题：网络延迟通常也在数十到数百微秒，且引入了分布式系统的复杂性，如脑裂问题、主备切换的可靠性、数据一致性协议（如 Raft/Paxos）带来的额外开销。同步复制会显著增加交易处理的端到端延迟，而异步复制则存在数据丢失的风险窗口（RPO > 0）。

长久以来，架构师们就在这两种“不够好”的方案中进行痛苦的取舍。我们渴望一种存储介质，它能像 DRAM 一样通过内存指令（`MOV`）直接访问，又能像 SSD 一样在断电后数据不丢失。这正是 Intel Optane 持久内存（PMEM）试图解决的核心问题。

关键原理拆解

要理解 PMEM 为何能带来范式转移，我们必须回到计算机存储体系结构的基础原理。这部分我将用严谨的学术视角来剖析。

1. 存储金字塔与“持久化鸿沟”

计算机存储系统是一个分层结构（Memory Hierarchy），从上到下依次是：CPU 寄存器、L1/L2/L3 Cache、DRAM、NAND Flash SSD、HDD。越往上，速度越快，每比特成本越高，容量越小。长期以来，DRAM 和 SSD 之间存在一条巨大的“持久化鸿沟”：

  • 访问方式：DRAM 是字节寻址（byte-addressable）的，CPU 可以通过 `load/store` 指令直接读写任意一个字节。而 SSD 是块寻址（block-addressable）的，必须通过内核的文件系统和块设备层，以 4KB 或更大的页面为单位进行读写。
  • 延迟：DRAM 的访问延迟在 100 纳秒左右，而 NVMe SSD 即使再快，也需要 10-100 微秒，两者有 2-3 个数量级的差距。

Intel Optane PMEM 的颠覆性在于，它在物理形态上是插在内存插槽（DIMM）上的，但在特性上横跨了这条鸿沟。它既是字节寻址的，又是持久化的（非易失性）。

2. DAX：绕过内核，直抵物理硬件

PMEM 要发挥其威力，关键在于绕过传统 I/O 栈。这依赖于一项名为 DAX (Direct Access) 的技术。当我们将 PMEM 设备挂载为支持 DAX 的文件系统（如 ext4 或 XFS）时，应用程序通过 `mmap()` 系统调用映射一个文件，内核不会为这个文件在 DRAM 中建立页面缓存（Page Cache），而是直接将应用的虚拟地址空间映射到 PMEM 的物理地址上。这意味着，当你的程序执行一条 `MOV` 指令去修改这片内存时，数据是直接写入 PMEM 控制器，而无需内核介入。这彻底消除了内核态/用户态切换、数据在 Page Cache 和用户缓冲区之间的多次拷贝，是实现超低延迟持久化的基石。

3. 持久化域与 CPU Cache 的挑战

然而，故事并没有这么简单。一个常见的误解是：只要执行了 `MOV` 指令，数据就安全了。这是错误的。 在现代 CPU 架构中，`store` 指令首先将数据写入 CPU 的 L1/L2/L3 Cache，这些 Cache 是基于 SRAM 的，同样是易失性的。数据从 Cache 中被“驱逐（evict）”到内存控制器，再最终写入 PMEM DIMM，这个过程并非瞬时完成。如果在数据仍在 CPU Cache 中时发生断电，数据同样会丢失。

我们必须确保数据越过了所谓的“持久化域（Persistence Domain）”，即到达了 PMEM 控制器。为此，CPU 提供了一系列专门的指令：

  • CLFLUSH / CLFLUSHOPT / CLWB：这些指令用于将指定的 Cache Line（通常是 64 字节）从 CPU Cache 中写回（flush）到内存控制器。
  • SFENCE (Store Fence)：这是一条内存屏障指令，它确保在 `SFENCE` 之前的所有 `store` 操作都已完成，其结果对其他 CPU 核可见，并确保 `CLFLUSH` 等指令在后续操作前完成。

因此，一个真正原子的、持久化的写操作，其底层序列是：修改内存 -> `CLFLUSH` 刷新包含该内存的 Cache Line -> `SFENCE` 保证顺序。只有完成了这三步，我们才能在应用层确认数据已经安全持久化。这套机制将持久化的控制权从操作系统交还给了应用程序员，提供了前所未有的性能和灵活性，也带来了新的编程复杂性。

系统架构总览

基于 PMEM 的撮合引擎架构会变得异常简洁和高效。让我们用文字描绘一下这幅新的架构图：

  • 硬件层：一台或多台高性能服务器，配置大容量的 Intel Optane PMEM（例如 1.5TB）和少量 DRAM（用于运行操作系统和非核心进程）。CPU 必须支持 PMEM 相关指令集。

    • – **存储层**：PMEM 设备被格式化为支持 DAX 的文件系统（如 XFS）。在该文件系统上创建一个巨大的文件，比如 `orderbook.pmem`，大小为数百 GB，足以容纳整个市场的订单数据。

    – **应用层**：

    1. 撮合引擎进程启动时，通过 `mmap()` 将 `orderbook.pmem` 文件完整映射到其虚拟地址空间。
    2. 操作系统利用 DAX，直接建立虚拟地址到 PMEM 物理地址的映射。
    3. 引擎在内存中构建其核心数据结构，例如 `std::map` 或更高效的自定义哈希表/红黑树。这些数据结构的所有节点和数据，都直接分配在这片 mmap 出来的 PMEM 内存区域内。
    4. 当一个新订单到来，引擎直接在这片内存中修改数据结构（创建新节点、修改指针等）。
    5. 在完成所有内存修改后，它不再调用 `write()` 或 `fsync()`，而是调用一个封装了 `CLFLUSH` 和 `SFENCE` 的函数，将被修改的几个 Cache Line 持久化。这个过程的延迟是纳秒级的。
    6. 如果系统崩溃或断电重启，引擎只需重新 `mmap()` 同一个文件，所有的数据结构和状态瞬间恢复，无需从任何日志或快照中重建。

在这个架构下，持久化不再是一个独立的、缓慢的步骤，而是融入了业务逻辑执行的最后一环，成为一个轻量级的内存操作。整个系统的瓶颈重新回到了纯粹的计算和内存访问速度上。

核心模块设计与实现

直接操作 PMEM 和 Cache Flush 指令过于底层和危险。工程实践中，我们通常使用 Intel 提供的 PMDK (Persistent Memory Development Kit) 库，特别是 `libpmemobj`，它为 C/C++ 提供了事务性的对象存储模型。下面，我将以一个极客工程师的视角，展示关键代码的实现思路。

模块一：PMEM 内存池初始化与根对象

`libpmemobj` 将一个 `mmap` 的大文件视为一个“内存池（Pool）”。池中的所有数据都以“对象”的形式存在。我们需要一个入口点来访问所有数据，这就是“根对象（Root Object）”。


#include <libpmemobj>.h>

// 定义我们的根结构体，它包含指向订单簿的指针
struct Root {
    PMEMoid order_book; // PMEMoid 是一个指向 PMEM 对象的胖指针
};

// 定义订单簿和订单的结构体
struct OrderBook { ... };
struct Order { ... };

// 初始化或打开内存池
PMEMobjpool *pop = pmemobj_open("/mnt/pmem/orderbook.pmem", POBJ_LAYOUT_NAME("matching_engine"));

if (pop == nullptr) {
    // 文件不存在，首次创建
    pop = pmemobj_create("/mnt/pmem/orderbook.pmem", POBJ_LAYOUT_NAME("matching_engine"), PMEMOBJ_MIN_POOL, 0666);
    if (pop == nullptr) {
        perror("pmemobj_create");
        return 1;
    }
    // 获取根对象并初始化
    PMEMoid root_oid = pmemobj_root(pop, sizeof(Root));
    Root *root_p = (Root *)pmemobj_direct(root_oid);
    
    // 在事务中分配 OrderBook 对象
    TX_BEGIN(pop) {
        root_p->order_book = pmemobj_tx_alloc(sizeof(OrderBook), 0);
        // ... 初始化 OrderBook ...
    } TX_END
}

这段代码展示了程序的启动逻辑。它尝试打开一个 PMEM 池文件。如果失败，就创建一个新的。关键在于 `pmemobj_root` 获取一个固定的入口点，所有持久化的数据结构都应该从这个根对象可达。

模块二：事务性地添加一笔订单

撮合引擎最核心的操作是修改订单簿。例如，添加一个订单节点可能涉及：1. 分配新订单对象的内存；2. 修改价格链表的头指针；3. 修改新旧节点的 `next/prev` 指针。这些操作必须是原子的，否则断电可能导致链表断裂。`libpmemobj` 提供了事务宏来保证这一点。


void add_order(PMEMobjpool *pop, Order new_order_data) {
    PMEMoid root_oid = pmemobj_root(pop, sizeof(Root));
    Root *root_p = (Root *)pmemobj_direct(root_oid);
    OrderBook *book_p = (OrderBook *)pmemobj_direct(root_p->order_book);

    try {
        // 开启一个事务
        TX_BEGIN(pop) {
            // 1. 在事务中分配新订单内存，失败会自动回滚
            PMEMoid new_order_oid = pmemobj_tx_alloc(sizeof(Order), 0);
            Order *new_order_p = (Order *)pmemobj_direct(new_order_oid);
            memcpy(new_order_p, &new_order_data, sizeof(Order));

            // 2. 找到要插入的位置，并对将要修改的内存区域拍快照
            // 假设我们要在 an_existing_order 之后插入
            Order *existing_order_p = ...; // find_insertion_point(book_p, ...);
            pmemobj_tx_add_range_direct(existing_order_p, sizeof(Order));
            if (existing_order_p->next != OID_NULL) {
                 // 对下一个节点也拍快照
                 pmemobj_tx_add_range(existing_order_p->next, 0, sizeof(Order));
            }
            
            // 3. 执行指针修改，这些修改目前只在事务日志中
            new_order_p->next = existing_order_p->next;
            existing_order_p->next = new_order_oid;
            // ... 修改 prev 指针等 ...

        } TX_ONABORT {
            // 如果事务中间失败（如内存不足），这里会被调用
            log_error("Transaction aborted!");
        } TX_END
    } catch (const pmem::transaction_error &e) {
        log_error("Transaction failed: %s", e.what());
    }
}

说白了，`TX_BEGIN/TX_END` 就是一个轻量级的、用户态的 WAL。`pmemobj_tx_add_range` 会把被修改内存的原始值保存在 PMEM 的一块专用区域。`TX_END` 提交时，它会原子性地标记事务成功。如果在中间断电，重启后 `libpmemobj` 会检查未完成的事务日志，并自动执行回滚，保证数据结构的一致性。这一切都在用户态内存中完成，无任何系统调用。

性能优化与高可用设计

即使使用了 PMEM，也依然有大量的工程坑点需要处理，才能榨干硬件的每一分性能，并保证系统整体的健壮性。

性能优化要点：

  • NUMA 亲和性：PMEM DIMM 和 CPU Core 都属于某个 NUMA Node。处理撮合的线程必须被绑定（pin）在与 PMEM 所在的同一个 NUMA Node 的 CPU Core 上。跨节点的内存访问会经过 QPI/UPI 总线，延迟会急剧增加。这是性能优化的第一铁律。
  • 数据结构对齐：确保被频繁修改且需要一起持久化的数据位于同一个 Cache Line（64 字节）内。例如，一个订单的价格和数量应该紧邻存放。这可以减少 `CLFLUSH` 指令的调用次数。
  • 减少事务开销：`libpmemobj` 的事务虽然快，但仍有开销（记录 undo log）。对于一些可以容忍非原子更新的场景（比如更新统计数据），可以绕过事务，手动调用 `pmemobj_persist()` 函数，它封装了 `CLFLUSH` 和 `SFENCE`，实现更底层的持久化。
  • 避免伪共享（False Sharing）：如果两个线程频繁修改位于同一个 Cache Line 但逻辑上无关的数据，会导致 Cache Line 在不同 CPU Core 之间频繁失效和同步，造成巨大性能损耗。合理填充（padding）数据结构以保证热点数据分散在不同 Cache Line 是必要的。

高可用设计：

PMEM 解决了单机断电恢复的问题，但无法抵御硬件永久性损坏（如主板烧毁）或整个机房的灾难。因此，高可用（HA）设计依然是必须的，但 PMEM 改变了 HA 的范式。

新的 HA 架构是：主节点（Primary）使用 PMEM 进行本地状态存储，并异步地将操作日志复制到备用节点（Backup）。

  • 主节点：交易请求的响应时间仅取决于在 PMEM 上的事务提交延迟（微秒级）。它不依赖任何网络确认。
  • 复制通道：主节点将已在本地 PMEM 成功提交的事务日志，通过低延迟网络（如 InfiniBand）发送给备用机。
  • 备用节点：备用节点可以在内存中（DRAM 或 PMEM）应用这些日志，实时追赶主节点的状态。

这个模型的巨大优势在于，它将持久化和高可用解耦了。交易的延迟（Latency）由本地 PMEM 保证，而系统的恢复点目标（RPO）由异步复制的延迟决定。我们可以接受几毫秒的数据丢失风险窗口，来换取交易处理延迟降低几个数量级。这对于大多数交易场景来说，是一个非常理想的 trade-off。

架构演进与落地路径

对于一个已有的、采用传统架构的系统，直接切换到完全基于 PMEM 的模型风险和成本都很高。我建议一个分阶段的演进路线：

第一阶段：PMEM 作为高速 WAL 设备

维持现有应用架构不变，即内存状态在 DRAM，持久化依赖 WAL。唯一的改变是，将 WAL 文件从 NVMe SSD 迁移到一块配置为“块设备模式”（Block Mode）的 PMEM 上。此时应用仍然调用 `write()` 和 `fsync()`，但由于 PMEM 的块设备驱动非常高效，`fsync()` 的延迟会从数百微秒降低到几微秒。这是一个低风险、高收益的步骤，可以快速验证 PMEM 带来的价值。

第二阶段：核心热点数据结构 PMEM 化

识别系统中对延迟最敏感、最核心的数据结构，比如订单簿本身。将其从 DRAM 迁移到基于 `libpmemobj` 的 PMEM 内存池中进行管理。系统的其他部分（如账户信息、历史成交）可以暂时保持原样。这是一种混合模式，允许团队逐步熟悉和掌握 PMEM 编程模型，同时解决最大的性能瓶颈。

第三阶段：全面 PMEM 化

当团队对 PMEM 的开发和运维都积累了足够经验后，可以将撮合引擎的全部核心状态（订单簿、账户资金、持仓等）都迁移到 PMEM 中。此时，传统的 WAL 机制可以被彻底移除，系统架构演变为前文所述的简洁高效模型。这是最终目标。

第四阶段：构建异步复制高可用方案

在单机 PMEM 模型稳定运行后，增加异步复制功能，构建主备或多活的数据中心容灾能力，形成最终的生产级高可用架构。

通过这样的演进路径，团队可以在控制风险的前提下，平滑地拥抱 PMEM 这项革命性技术，最终构建出兼具极致性能和强大可靠性的新一代交易系统。

延伸阅读与相关资源

  • 想系统性规划股票、期货、外汇或数字币等多资产的交易系统建设，可以参考我们的
    交易系统整体解决方案。
  • 如果你正在评估撮合引擎、风控系统、清结算、账户体系等模块的落地方式，可以浏览
    产品与服务
    中关于交易系统搭建与定制开发的介绍。
  • 需要针对现有架构做评估、重构或从零规划，可以通过
    联系我们
    和架构顾问沟通细节，获取定制化的技术方案建议。
滚动至顶部