微秒必争：基于RDMA的超低延迟撮合引擎通信架构剖析

作者： /

在高频交易（HFT）与数字货币交易所等金融场景中，延迟是决定成败的唯一标尺。当系统优化的战场从业务逻辑深入到CPU缓存、操作系统内核时，传统的TCP/IP网络栈便成为那个无法绕过的性能天花板。本文将面向已有深厚工程背景的架构师与技术负责人，从计算机底层原理出发，剖析TCP/IP的延迟根源，并系统性地阐述如何利用RDMA（远程直接内存访问）技术，构建一套微秒级的撮合集群通信架构，以应对最严苛的低延迟挑战。

现象与问题背景

一个典型的现代化撮合交易系统，其核心链路通常包含网关（Gateway）、定序器（Sequencer）、撮合引擎（Matching Engine）以及行情发布（Market Data Publisher）等多个模块。当一笔订单（Order）进入系统，其生命周期内的延迟预算会被严格切分到每一个环节。在万兆（10GbE）甚至25GbE/100GbE网络环境下，我们常常发现，即便硬件再快，节点间的通信延迟依然顽固地停留在数十到上百微秒的量级，这对于追求极致性能的系统是不可接受的。

让我们量化一下问题。假设一次订单处理的端到端（end-to-end）延迟目标是100微秒。其中，网关到定序器、定序器到撮合引擎、撮合引擎主备节点间的状态复制，每一跳的网络通信都可能消耗20-50微秒。仅仅是网络通信本身，就可能吃掉大部分延迟预算，留给核心业务逻辑（如订单匹配、风险计算）的时间所剩无几。这种延迟并非源于网络物理传输的耗时（光速限制），而是深植于操作系统内核的网络协议栈中。

传统的基于Socket API的TCP/IP通信，数据从发送方用户空间内存到达接收方用户空间内存，需要经历一个漫长而复杂的旅程：

  • 多次内存拷贝：数据需要从用户空间缓冲区拷贝到内核空间的Socket缓冲区，再由网卡（NIC）通过DMA（Direct Memory Access）从内核缓冲区拷贝到网卡自身的缓冲区进行发送。接收端则是一个逆向过程。这个过程中至少涉及两次CPU参与的内存拷贝。
  • 大量的上下文切换：应用程序调用send()/recv()等系统调用（syscall）时，会触发从用户态到内核态的切换，这是一个开销巨大的操作，涉及到CPU寄存器状态的保存与恢复。
  • 协议栈处理开销：在内核中，数据包需要经过完整的TCP/IP协议栈处理，包括分段、校验和计算、TCP状态机维护（连接跟踪、拥塞控制、确认与重传等），这些都消耗大量的CPU周期。
  • 中断处理：数据包到达网卡后，会向CPU发起硬件中断，迫使CPU暂停当前工作来处理网络数据，这会污染CPU缓存并带来不确定性。

在低延迟场景下，以上每一点都是致命的。我们需要一种能彻底绕过（Bypass）内核、消除（Zero）内存拷贝的技术，而这正是RDMA的用武之地。

关键原理拆解：告别内核，直达内存

（教授视角） 要理解RDMA的颠覆性，我们必须回到操作系统与网络I/O模型的基础。传统I/O模型是“内核中心化”的，所有I/O操作都必须经由内核作为中介，这是为了实现资源隔离、安全与多任务调度。但这种设计的代价就是性能开销。RDMA则是一种“用户态中心化”的网络模型，它将数据通路（Data Path）的控制权直接交还给了应用程序。

RDMA的核心思想可以概括为两点：内核旁路（Kernel Bypass） 和 零拷贝（Zero-Copy）。

  • 内核旁路：支持RDMA的智能网卡（RNIC）拥有自己的处理单元，能够直接解析和执行RDMA协议。应用程序通过一个特定的用户态驱动库（如libibverbs）下发指令，这些指令直接提交给RNIC的硬件队列，整个数据传输过程完全不经过操作系统内核。CPU只在连接建立、资源注册和最终完成通知等控制路径（Control Path）上介入，数据路径则完全由硬件接管。

    • li>零拷贝：发送方应用可以直接指定一块用户空间内存，让RNIC直接从这块内存中抓取数据并发送出去。接收方RNIC在收到数据后，根据报文头中的目标地址信息，直接将数据写入到接收方应用预先指定的另一块用户空间内存中。整个过程数据始终在用户空间和网卡之间流动，无需在内核缓冲区中转，实现了真正意义上的零拷贝。

为了实现这一目标，RDMA引入了一套全新的编程接口与核心组件，我们称之为Verbs API：

  • 队列对（Queue Pair, QP）：这是RDMA通信的基本单元，类似于一个双向的Socket连接。每个QP包含一个发送队列（Send Queue, SQ）和一个接收队列（Receive Queue, RQ）。应用通过向这些队列提交工作请求（Work Request, WR）来发起数据传输。
  • 完成队列（Completion Queue, CQ）：当RNIC完成了某个工作请求后（无论是发送完成还是接收完成），它会向关联的CQ中放入一个完成队列项（Work Completion, WC）。应用程序通过轮询（Polling）或等待（Blocking）CQ来获知操作的结果。在追求极致低延迟的场景中，通常会使用一个专用的CPU核心进行忙等待轮询（Busy-polling），以消除中断和上下文切换的延迟。
  • 内存注册（Memory Registration）：这是RDMA安全模型的基石。应用程序必须先向RDMA驱动注册一块内存区域（Memory Region, MR）。注册过程会“钉住”（Pin）这块内存对应的物理页，确保其不会被操作系统交换到磁盘。注册成功后，应用会获得一个内存句柄（lkey/rkey），远程节点必须持有这个key才能对这块内存进行读写。这个注册操作本身是有开销的，因此高性能应用通常在启动时就预分配并注册好大块的内存池。

在物理网络层面，实现RDMA主要有两种技术路线：InfiniBand（IB） 和 RoCE（RDMA over Converged Ethernet）。InfiniBand是为RDMA原生设计的网络技术，拥有独立的交换机和网络协议，提供最低的延迟和最高的可靠性，但成本高昂。RoCE则是在标准以太网上运行RDMA，它将IB的传输层报文封装在以太网帧中。RoCE需要“无损以太网”（Lossless Ethernet）的支持，通常通过PFC（Priority-based Flow Control）等技术实现，以避免丢包导致RDMA性能急剧下降。对于延迟极其敏感的金融交易系统，尽管成本更高，但InfiniBand因其稳定可预测的性能而更受青睐。

系统架构总览：RDMA在撮合系统中的定位

理论的优雅需要落到实际的架构中。在一个撮合系统中，并非所有通信链路都值得用RDMA改造。我们需要精准地识别出延迟最敏感、对系统吞吐量影响最大的“关键路径”。

以下是我们设计的基于RDMA优化的撮合集群逻辑架构：

  • 接入层与外部通信：客户端通过TCP/IP协议连接到接入网关。这一层仍然使用TCP，因为它需要处理大量的并发连接和广域网的不确定性，RDMA并不适用。
  • 核心处理集群内部通信：这是RDMA发挥价值的核心区域。
    1. 定序器到撮合引擎的订单分发：定序器完成订单的排序和初步校验后，需要将其快速、有序地分发给后端多个撮合引擎分区（按交易对或用户ID分片）。这条路径是系统吞吐量的瓶颈之一，要求极低的广播/多播延迟。
    2. 撮合引擎主备节点状态复制：为了实现高可用（High Availability），撮合引擎通常采用主备（Primary-Backup）模式。主节点处理完每一笔订单或状态变更后，必须将对应的状态日志（State Log）或事务日志（Transaction Log）同步复制给备用节点。这个复制过程必须是同步或接近同步的，其延迟直接叠加在每笔交易的处理时间上。这是对RDMA最经典、最完美的“对口”应用场景。
  • 下游服务通信：撮合引擎将成交回报（Execution Report）和行情快照（Market Data Snapshot）推送到下游的清算系统和行情发布系统。这些链路对延迟也敏感，但相比核心撮合链路，容忍度稍高，可以作为第二阶段的优化目标。

因此，我们的架构优化焦点将集中在“定序器->撮合引擎”和“撮合引擎主->备”这两条生命线上。前者可以使用RDMA的双向Send/Receive操作，实现高效的消息队列。后者则可以发挥RDMA单向Write操作的极致优势，实现无感知的远程内存写入。

核心模块设计与实现：深入RDMA编程范式

（极客工程师视角） 理论说完了，来看点硬核的。RDMA编程跟写Socket完全是两码事，它更像是直接操作硬件。你得手动管理内存，自己处理可靠性，每一行代码都得跟性能死磕。

模块一：内存池化与预注册

千万别在收到每条消息时去调用ibv_reg_mr()，这玩意儿慢得要死，一次调用可能耗费数微秒甚至更多，直接毁掉你的所有优化。正确的姿势是在程序启动时，就向操作系统申请一大块连续的、对齐的内存（比如使用posix_memalign或Huge Pages），然后一次性把它全部注册掉，做成一个内存池。


/* 这是一个极简的内存池初始化概念代码 */
#include <infiniband/verbs.h>
#include <stdlib.h>

// 假设我们预分配一个1GB的内存池
#define POOL_SIZE (1024 * 1024 * 1024)

struct rdma_mem_pool {
    void* buffer;
    struct ibv_mr* mr;
    // ... 其他池管理元数据
};

int init_memory_pool(struct rdma_mem_pool* pool, struct ibv_pd* pd) {
    // 使用posix_memalign保证页面对齐
    if (posix_memalign(&pool->buffer, 4096, POOL_SIZE) != 0) {
        perror("posix_memalign failed");
        return -1;
    }

    // 注册整个内存池，赋予本地写和远程读写权限
    int access_flags = IBV_ACCESS_LOCAL_WRITE | 
                       IBV_ACCESS_REMOTE_WRITE | 
                       IBV_ACCESS_REMOTE_READ;

    pool->mr = ibv_reg_mr(pd, pool->buffer, POOL_SIZE, access_flags);
    if (!pool->mr) {
        perror("ibv_reg_mr failed");
        return -1;
    }

    // lkey和rkey现在可以在通信中使用了
    printf("Memory pool registered. lkey: %u, rkey: %u\n", pool->mr->lkey, pool->mr->rkey);
    
    // 接下来可以基于这个大buffer实现自己的slab/buddy allocator
    return 0;
}

后续所有需要网络发送的数据，都从这个池里分配一小块，用完再归还。这样，运行时的内存操作就变成了极快的指针移动，而不是昂贵的系统调用。

模块二：利用RDMA Write实现无感知的状态复制

这是RDMA最强大的功能——单向操作（One-Sided Operation）。主撮合引擎可以直接修改备用引擎的内存，而备用引擎的CPU完全不参与数据传输过程，甚至都不知道内存被修改了（直到它去检查特定内存区域或完成队列）。这对于状态复制来说是天作之合。

流程如下：

  1. 连接建立阶段：备用节点分配一块大的内存区域作为日志缓冲区（Log Buffer），注册后，将其内存地址、长度和rkey通过带外方式（比如一个普通的TCP连接）发送给主节点。
  2. 运行时：主节点每生成一条事务日志，就从自己的内存池中取一块buffer，填充日志内容，然后发起一次RDMA_WRITE操作。这个操作的目标地址就是备用节点的Log Buffer地址，并附上之前收到的rkey。
  3. 硬件接管：主节点的RNIC看到这个写请求，直接读取本地内存，将数据打包成RDMA报文发出去。备用节点的RNIC收到报文，验证rkey，直接将数据写入指定内存地址。整个过程无CPU干预。

// Go伪代码，展示主节点发起RDMA Write的逻辑
// 假设rdmaConn已经封装好了QP, CQ, Memory Pool等

type PrimaryMatcher struct {
    rdmaConn      *RDMAConnection
    backupInfo    BackupNodeInfo // 存储备节点的内存地址和rkey
    logSequence   uint64
}

type BackupNodeInfo struct {
    RemoteAddr uint64
    RemoteKey  uint32
}

func (p *PrimaryMatcher) replicateLog(logData []byte) error {
    // 1. 从预注册的内存池中获取一个buffer
    buffer := p.rdmaConn.memPool.Get(len(logData))
    copy(buffer.Bytes(), logData)

    // 2. 构造一个RDMA Write工作请求
    wr := &ibv.SendWR{
        Opcode: ibv.WR_RDMA_WRITE,
        SGEs: []ibv.SGE{
            {Addr: buffer.Addr(), Length: uint32(len(logData))},
        },
        WR: ibv.WR{
            RDMA: ibv.RDMAWR{
                RemoteAddr: p.backupInfo.RemoteAddr + p.logSequence, // 计算远程写入位置
                RKey:       p.backupInfo.RemoteKey,
            },
        },
        // 设置SIGNALED标志，这样操作完成后才会在CQ中产生一个完成事件
        // 为了性能，可以每N个操作才产生一次完成事件
        SendFlags: ibv.SEND_SIGNALED,
    }

    // 3. 提交工作请求给硬件，此调用立即返回
    err := p.rdmaConn.queuePair.PostSend(wr)
    
    // 提交后，主节点可以立即继续处理下一笔订单
    // 它稍后会从自己的CQ中检查这次写入是否成功
    p.logSequence += uint64(len(logData))

    return err
}

备用节点如何知道日志更新了？它可以定期检查日志缓冲区的某个“长度”或“序列号”字段（主节点在写完数据后再更新这个字段），或者主节点在写入一批日志后，再通过一次小的RDMA Send/Receive操作发送一个“通知”消息。

模块三：CPU独占与忙等待轮询

为了榨干最后一滴性能，必须避免被操作系统调度器打扰。我们会把处理网络完成事件的线程绑定到专用的CPU核心上，这个核心不处理任何其他业务逻辑。


#define _GNU_SOURCE
#include <sched.h>
#include <infiniband/verbs.h>

// 一个专门轮询CQ的线程函数
void* cq_poller_thread(void* arg) {
    struct ibv_cq* cq = (struct ibv_cq*)arg;
    struct ibv_wc wc_batch[32];

    // 将当前线程绑定到CPU核心3上
    cpu_set_t cpuset;
    CPU_ZERO(&cpuset);
    CPU_SET(3, &cpuset);
    if (sched_setaffinity(0, sizeof(cpu_set_t), &cpuset) != 0) {
        perror("sched_setaffinity failed");
        // handle error
    }

    // 进入无限循环，不停地轮询硬件队列
    while (1) {
        int num_completions = ibv_poll_cq(cq, 32, wc_batch);
        if (num_completions > 0) {
            // 批量处理完成事件
            for (int i = 0; i < num_completions; ++i) {
                if (wc_batch[i].status == IBV_WC_SUCCESS) {
                    // 操作成功，根据wr_id（工作请求ID）通知业务逻辑
                    // 比如，释放一个buffer，或者更新一个原子计数器
                } else {
                    // 处理错误
                }
            }
        }
        // 这里没有sleep，CPU会100%占用，这就是所谓的“忙等待”
    }
    return NULL;
}

这种做法看似浪费CPU，但在微秒级的世界里，一次上下文切换或线程休眠唤醒的代价（可能是几微秒到几十微秒）远高于让一个CPU核心空转的成本。这是典型的用资源换时间的Trade-off。

对抗与权衡：RDMA不是银弹

引入RDMA带来了极致性能，但也带来了复杂性和新的挑战。架构师必须清醒地认识到其中的权衡：

  • 性能 vs. 复杂性 & 成本：RDMA的编程模型远比Socket复杂，需要对硬件有深入理解。同时，InfiniBand或支持RoCE的智能网卡和交换机价格不菲。这是一笔巨大的技术和资金投入，只适用于那些“延迟每减少一微秒就能带来真金白银”的场景。
  • RDMA可靠性 vs. 应用层可靠性：RDMA的可靠连接模式（Reliable Connected, RC）能保证数据可靠、有序到达，但它无法处理节点宕机、网络分区等系统级故障。连接一旦断开，所有状态都会丢失，需要应用层有复杂的重连和状态恢复机制。许多HFT公司甚至选择使用不可靠的数据报模式（Unreliable Datagram, UD），然后在应用层构建自己的、更轻量、更可控的可靠性协议。
  • 单向操作 vs. 双向操作：单向的RDMA Write/Read延迟最低，因为它不消耗远端CPU。但它也缺乏流控机制，发送方可以无限制地“轰炸”接收方的内存。双向的Send/Receive操作需要远端CPU介入（提交接收请求），延迟稍高，但天生带有一对一的信用（credit）流控机制，更易于构建传统的请求-响应式应用。

    • – RoCE vs. InfiniBand: RoCE利用了现有的以太网基础设施，成本相对较低，但对网络的“无损”配置要求极高，一旦网络出现拥塞丢包，性能会断崖式下跌，排查问题也更复杂。InfiniBand是一个独立的、为HPC和低延迟设计的网络，行为更可预测，是金融交易领域的首选，但意味着需要一套完全独立的网络设备。

架构演进与落地路径

一口吃不成胖子，直接全盘切换到RDMA是不现实的。一个稳健的演进路径至关重要：

  1. 第一阶段：瓶颈定位与基准测试。 在现有TCP/IP架构上，使用perf、eBPF等工具精准分析性能瓶颈，确认网络栈的开销确实是主要矛盾。在实验环境中搭建小规模RDMA集群，使用qperf、ib_write_bw等工具充分测试其基准性能，建立团队对这项技术的体感和认知。
  2. 第二阶段：单点突破，主备复制先行。 选择撮合引擎的主备状态复制作为第一个改造点。这个场景是点对点通信，需求清晰，风险可控。成功落地后，可以立即获得高可用性的巨大提升，并为团队积累宝贵的RDMA开发和运维经验。系统的其他部分保持不变。
  3. 第三阶段：扩展至核心消息总线。 在定序器到撮合引擎的订单分发链路上，用RDMA替换原有的TCP或UDP通信。这可能需要开发一个轻量级的发布/订阅消息库，封装RDMA的Send/Receive操作。这会显著提升整个系统的吞吐量上限。
  4. 第四阶段：构建通用RDMA RPC框架。 当团队对RDMA的掌控能力达到一定水平后，可以将底层的Verbs API封装成一个通用的、对业务开发者友好的RPC或消息框架。目标是让业务开发者能像使用gRPC一样，方便地定义服务和消息，而底层则透明地运行在RDMA之上。这是最高阶段，也是工程量最大的阶段，但它能将RDMA的能力赋能给整个技术体系。

总而言之，RDMA是攻克超低延迟场景的终极武器之一。它要求我们从传统的软件思维，转向软硬件协同设计的思维，深入到操作系统和硬件的边界去挖掘性能。这条路充满挑战，但对于那些在微秒战场上竞争的系统而言，这是不得不走的、通往极致性能的必经之路。

延伸阅读与相关资源

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