三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

从零实践RDMA：C++实现高性能网络通信与性能调优指南

发布时间：2026/8/12 19:46:33 三亩地 编程学习日记
从零实践RDMA：C++实现高性能网络通信与性能调优指南

1. 项目概述

如果你正在高性能计算、分布式存储或者大规模机器学习框架的领域里摸爬滚打，那么“RDMA”这个词对你来说，绝对不是一个陌生的概念。它就像性能优化道路上的一个终极圣杯，人人都听说过它的传说——零拷贝、内核旁路、超低延迟，但真正能把它玩转、写进自己代码里的人，却并不多。今天，我们就来彻底拆解这个听起来高大上的技术，并且，我会带你用C++，从零开始，亲手实践一个基于RDMA的简单通信程序。这不仅仅是原理的堆砌，更是我踩过无数坑、调过无数参数后，总结出的实战经验。无论你是想为你的分布式系统寻找性能突破口，还是单纯对底层网络编程感到好奇，这篇文章都将为你提供一个清晰、可落地的路线图。

RDMA，全称Remote Direct Memory Access，翻译过来是“远程直接内存访问”。它的核心思想非常直接：让一台计算机的网卡（NIC）能够绕过操作系统内核，直接访问另一台计算机的内存。想象一下，传统的网络通信就像你要给隔壁办公室的同事送一份文件，你需要先打印出来（数据从用户空间拷贝到内核缓冲区），交给公司的前台（内核协议栈处理），前台再叫快递（网卡发包），快递送到对方前台（对方网卡收包、内核处理），对方同事再去前台取（数据从内核缓冲区拷贝到用户空间）。而RDMA呢？它相当于在你和同事的办公桌之间，打通了一条专属的传送带。你直接把文件放在传送带上，它“嗖”一下就出现在同事的桌面上，全程无需惊动前台，也无需二次搬运。这种“零拷贝”和“内核旁路”的特性，使得延迟可以降低到微秒级，CPU占用率也大幅下降，特别适合那些对延迟和吞吐量都极度敏感的场景，比如金融高频交易、超算中心的MPI通信、分布式数据库（如Google Spanner的底层通信）、以及AI训练中参数服务器与工作节点之间海量梯度的同步。

2. RDMA核心原理深度剖析

要玩转RDMA，仅仅知道它“快”是不够的。你必须理解它赖以运转的几大核心支柱，这决定了你如何设计程序、如何排查问题。

2.1 核心架构：Queue Pair (QP) 与 Completion Queue (CQ)

RDMA的编程模型是围绕“队列”展开的，这是一种典型的生产者-消费者模型，非常高效。

Queue Pair (QP，队列对)：这是RDMA通信的基石。每一个QP由两个队列组成：发送队列（SQ）和接收队列（RQ）。你可以把QP想象成一条双向的、有严格顺序的流水线。

  • 发送队列 (SQ)：你的应用程序（生产者）把想要执行的操作描述（叫做Work Request, WR）放到这里。这些操作包括：SEND（发送数据）、RECV（准备接收数据）、RDMA_WRITE（远程写入）、RDMA_READ（远程读取）等。
  • 接收队列 (RQ)：你同样需要提前在这里放置RECV WR，相当于告诉网卡：“我准备好了一个‘篮子’，用来接住即将从网络上传来的数据。” 如果没有提前放置RECV WR，即使对方发来了数据，你的网卡也无法处理，会导致错误。

一个QP连接的两端（比如客户端和服务器）各自拥有自己的QP。通信的本质，就是一方将WR放入自己的SQ，网卡硬件异步地执行这些WR，并将完成通知放入CQ。

Completion Queue (CQ，完成队列)：这是用来接收操作完成通知的队列。当网卡硬件处理完一个SQ或RQ中的WR后，就会生成一个完成事件（Work Completion, WC），并放入关联的CQ中。你的应用程序（消费者）需要定期去轮询（Poll）CQ，从中取出WC，从而知道某个操作是成功还是失败，并释放相应的资源。

关键理解：WR的提交（Post）是异步非阻塞的，你post_send后函数立即返回，不代表数据已经发出。真正的完成确认，需要通过轮询CQ来获取。这是RDMA高性能的关键之一，避免了进程/线程阻塞等待IO。

2.2 内存注册（Memory Registration）与零拷贝

这是RDMA实现“零拷贝”的魔法所在。在传统Socket编程中，数据需要从用户缓冲区拷贝到内核的Socket缓冲区。RDMA为了绕过内核，必须让网卡能够直接访问用户指定的内存区域。

内存注册就是将一个用户空间的虚拟内存区间“钉”在物理内存上（防止被操作系统换出），并将该区域的相关信息（地址、长度、访问权限）直接告知网卡硬件，同时生成一个唯一的内存密钥（Memory Key）。这个密钥由两部分组成：

  • L_Key (Local Key)：本地进程使用，当本地网卡要访问这块内存时使用。
  • R_Key (Remote Key)：远程进程使用，当远程网卡想要通过RDMA操作（READ/WRITE）访问这块内存时，必须提供这个R_Key作为“密码”。

只有注册过的内存区域（Memory Region, MR），才能被用于RDMA操作。注册过程本身有一定开销，所以最佳实践是：在通信初始化阶段，批量注册好所有可能需要用到的、较大的、长期存在的缓冲区，而不是在每次通信时都进行注册和注销。

2.3 通信模式：单边与双边操作

这是RDMA最灵活也最需要理解的地方，它决定了你的通信语义和性能特征。

双边操作（Two-Sided Verbs）： 即传统的SEND/RECV语义。

  • 过程：发送方post_send一个SEND WR，接收方必须提前post_recv一个RECV WR来“等待”这个发送。接收方的应用层能感知到这次消息接收事件。
  • 类比：就像TCP，接收方需要调用recv。它提供了消息边界。
  • 优点：编程模型与传统Socket类似，更直观。接收方能明确知道消息的到来。
  • 缺点：需要接收方CPU参与（提交RECV WR），且涉及两端队列的协同，延迟略高于单边操作。
  • 适用场景：控制消息、小规模数据交换、需要明确接收确认的场合。

单边操作（One-Sided Verbs）： 即RDMA_WRITE和RDMA_READ。

  • 过程：发起方（Initiator）直接指定远程目标内存地址和R_Key，进行写入或读取。远程节点的CPU完全不知情，操作由发起方网卡和远程网卡直接协作完成。
  • 类比：就像直接读写共享内存，但内存是在另一台机器上。
  • 优点：极致性能。只需要一端CPU发起，远程CPU零参与，延迟最低。
  • 缺点：编程复杂，需要精确同步内存状态，避免数据竞争。需要预先交换内存地址和R_Key。
  • 适用场景：大规模数据搬运（如矩阵分块）、参数聚合、分布式共享内存系统。

2.4 核心组件关系图与数据流

理解了以上概念，我们可以勾勒出一次RDMA WRITE操作的数据流全景：

  1. 准备阶段：

    • 进程A注册一块内存区域MR_A，获取其R_Key_A。
    • 进程A通过带外方式（例如传统的TCP Socket）将MR_A的虚拟地址、长度和R_Key_A发送给进程B。
    • 进程B注册自己的内存区域MR_B。

  2. 操作阶段：

    • 进程B准备数据到本地缓冲区（MR_B的一部分）。
    • 进程B构造一个RDMA_WRITE WR，其中包含：
      • 本地数据源地址（MR_B内的地址）。
      • 远程目标地址（从进程A获得的地址）。
      • 远程R_Key_A。
      • 数据长度。
    • 进程B将这个WR提交（Post）到它的QP的发送队列（SQ_B）。
    • 进程B的网卡（NIC_B）硬件感知到SQ_B中的新WR，通过InfiniBand或RoCE网络，直接与进程A的网卡（NIC_A）通信。
    • NIC_A验证R_Key_A和权限，然后直接将数据写入进程A的内存MR_A中。整个过程不经过进程A的CPU和操作系统。

  3. 完成阶段：

    • 操作完成后，NIC_B会在进程B的完成队列（CQ_B）中生成一个WC。
    • 进程B通过轮询CQ_B得知写入完成。
    • 进程A如何知道数据已就绪？这需要额外的同步机制（例如，进程B在写入数据后，再通过一个SEND操作发送一个“数据已准备好”的通知给进程A）。

3. 环境搭建与InfiniBand基础软件栈

理论之后，我们来点实际的。没有环境，一切都是空谈。RDMA通常依赖于特定的硬件和驱动。

3.1 硬件与驱动选择

主流硬件：目前商用RDMA网卡主要来自NVIDIA（收购了Mellanox）的ConnectX系列，例如ConnectX-5, ConnectX-6, ConnectX-7。它们支持InfiniBand和以太网RDMA（RoCE）两种模式。

软件栈：Linux下标准的RDMA用户态接口是libibverbs。这是所有RDMA应用的基础。

  • 安装：在Ubuntu/Debian上，通常是sudo apt install libibverbs-dev ibverbs-utils。RHEL/CentOS则是sudo yum install libibverbs-devel libibverbs-utils。
  • 验证：安装后，使用ibv_devices和ibv_devinfo命令可以列出和查看系统中的RDMA设备信息。这是检查硬件是否被系统正确识别的第一步。

网络模式：

  • InfiniBand (IB)：原生模式，需要专用的IB交换机和线缆。性能最好，但部署成本高，常见于超算中心。
  • RoCE (RDMA over Converged Ethernet)：在标准以太网上运行RDMA。分为v1（依赖无损以太网DCB/PFC）和v2（在UDP上运行，更通用）。对于大多数从零开始的开发者，在同一个局域网内的两台服务器上部署RoCE v2是更可行的方案。你需要确保交换机支持或配置了流控（PFC），或者在一个无丢包的简单环境（如两台机器直连）中测试。

3.2 一个极简的C++ RDMA程序骨架

我们不依赖任何高级封装库（如之前提到的Infinity），直接用libibverbs从头开始，这样才能理解每一个细节。下面是一个客户端向服务器执行RDMA_WRITE的极简骨架。

服务器端 (server.cpp) 核心步骤：

  1. 获取设备列表，打开第一个设备。
  2. 创建上下文（Context）和保护域（Protection Domain）。
  3. 注册一块内存区域（MR）用于接收数据。
  4. 创建完成队列（CQ）和队列对（QP）。
  5. 将QP状态初始化为INIT，然后修改为RTR（Ready to Receive），最后是RTS（Ready to Send）。这是一个标准的状态机。
  6. 将本地MR的地址和R_Key通过带外通信（这里我们用简单的TCP）发送给客户端。
  7. 等待操作完成（在这个例子中，服务器被动等待客户端写入）。

客户端端 (client.cpp) 核心步骤：

  1. 同样初始化verbs环境。
  2. 注册自己的本地MR（用于存放要发送的数据）。
  3. 创建CQ和QP。
  4. 从服务器获取远程MR的地址和R_Key（通过TCP）。
  5. 将QP状态机初始化为INIT->RTR->RTS。
  6. 构造RDMA_WRITE WR，提交到QP的发送队列。
  7. 轮询CQ，等待写入完成。
  8. 通知服务器操作完成。

以下是关键的代码片段，展示了核心API的调用：

// 示例：客户端准备并提交一个RDMA WRITE WR #include <infiniband/verbs.h> // ... 之前已创建 context, pd, mr_local, qp, cq ... // 1. 准备要发送的数据 char *local_buffer = (char*)mr_local->addr; strcpy(local_buffer, "Hello from RDMA!"); // 2. 构造SGE (Scatter/Gather Element)，描述本地数据位置 struct ibv_sge sge; sge.addr = (uintptr_t)local_buffer; sge.length = strlen(local_buffer) + 1; // 包含字符串结束符 sge.lkey = mr_local->lkey; // 本地内存密钥 // 3. 构造WR (Work Request) struct ibv_send_wr wr, *bad_wr = nullptr; memset(&wr, 0, sizeof(wr)); wr.wr_id = 0; // 自定义标识，可用于匹配完成事件 wr.opcode = IBV_WR_RDMA_WRITE; // 操作类型：RDMA写入 wr.sg_list = &sge; wr.num_sge = 1; wr.send_flags = IBV_SEND_SIGNALED; // 此WR完成后需要在CQ中生成一个完成事件 // 4. 设置远程目标信息（这些信息应从服务器获取） wr.wr.rdma.remote_addr = server_remote_addr; // 服务器MR的远程虚拟地址 wr.wr.rdma.rkey = server_rkey; // 服务器MR的远程密钥(R_Key) // 5. 提交WR到发送队列 int ret = ibv_post_send(qp, &wr, &bad_wr); if (ret) { fprintf(stderr, "Failed to post SR, errno: %d\n", ret); return -1; } // 6. 轮询完成队列 (CQ) struct ibv_wc wc; int num_completed = 0; do { num_completed = ibv_poll_cq(cq, 1, &wc); } while (num_completed == 0); if (wc.status != IBV_WC_SUCCESS) { fprintf(stderr, "RDMA Write failed with status: %s\n", ibv_wc_status_str(wc.status)); return -1; } printf("RDMA Write completed successfully!\n");

实操心得1：IBV_SEND_SIGNALED标志位：这个标志至关重要。它告诉硬件，当这个WR处理完毕后，需要在CQ中生成一个完成事件（WC）。如果你连续提交多个WR，通常只需要给最后一个WR设置这个标志（IBV_SEND_SIGNALED），然后轮询一次CQ即可确认一批操作完成，这可以降低完成事件的开销，称为“请求聚合”。但如果你是新手，或者每个WR都需要独立确认，那就每个都加上。

4. 使用高级C++封装库：以Infinity为例

直接使用libibverbs的C API虽然控制力强，但代码冗长，容易出错。社区涌现了一些优秀的C++封装库，它们提供了更现代、更安全的抽象。我们之前提到的Infinity就是一个很好的选择。它用RAII（资源获取即初始化）机制管理资源，用对象封装了QP、Buffer等概念，让代码清晰很多。

4.1 Infinity核心概念映射

让我们把Infinity的概念和我们之前讲的基础原理对应起来：

  • infinity::core::Context-> 对应struct ibv_context，是设备的抽象。
  • infinity::memory::Buffer-> 封装了注册内存区域（MR）的操作。创建Buffer对象时，内部会自动进行内存注册。
  • infinity::queues::QueuePair-> 封装了QP的创建、状态管理和连接建立。
  • infinity::requests::RequestToken-> 封装了WC的等待逻辑，简化了完成事件的等待。

4.2 使用Infinity重写RDMA WRITE示例

使用Infinity，上面的客户端代码可以简化为：

#include <infinity/core/Context.h> #include <infinity/queues/QueuePairFactory.h> #include <infinity/queues/QueuePair.h> #include <infinity/memory/Buffer.h> #include <infinity/requests/RequestToken.h> int main() { // 1. 创建上下文 infinity::core::Context *context = new infinity::core::Context(); // 2. 创建队列对工厂并连接到服务器 infinity::queues::QueuePairFactory *qpFactory = new infinity::queues::QueuePairFactory(context); infinity::queues::QueuePair *qp = qpFactory->connectToRemoteHost(SERVER_IP, PORT_NUMBER); // 内部完成了QP状态机转换和参数交换 // 3. 创建并注册本地缓冲区（数据源） const uint64_t BUFFER_SIZE = 1024; infinity::memory::Buffer *localBuffer = new infinity::memory::Buffer(context, BUFFER_SIZE); strcpy((char*)localBuffer->getData(), "Hello from Infinity RDMA!"); // 4. 获取远程缓冲区令牌（此令牌应通过QueuePair连接过程或其他方式从服务器获得） // 假设我们已经从连接建立后的元数据交换中获得了 remoteToken infinity::memory::RegionToken *remoteBufferToken = ...; // 5. 创建请求令牌用于等待完成 infinity::requests::RequestToken requestToken(context); // 6. 执行RDMA写入！一行代码搞定。 qp->write(localBuffer, remoteBufferToken, &requestToken); // 7. 等待写入完成 requestToken.waitUntilCompleted(); std::cout << "RDMA Write via Infinity completed!" << std::endl; // 8. 清理资源（Infinity的析构函数会处理） delete remoteBufferToken; delete localBuffer; delete qp; delete qpFactory; delete context; return 0; }

可以看到，Infinity将建立连接、内存注册、操作提交和完成等待都封装成了简洁的方法调用，大大提升了开发效率，降低了入门门槛。

实操心得2：连接建立与元数据交换：无论是用原生API还是Infinity，一个关键且容易被忽略的步骤是元数据交换。在RDMA连接（QP进入RTS状态）前后，通信双方必须通过一个可靠的带外通道（通常是TCP Socket）交换各自MR的地址、长度和R_Key。Infinity的connectToRemoteHost方法内部就封装了这个过程。如果你自己实现，务必设计好这个握手协议，确保信息准确无误地传递。

5. 性能调优与常见陷阱

RDMA程序能跑通只是第一步，要发挥其极致性能，需要精细调优。

5.1 关键性能参数

  1. QP的SRQ (Shared Receive Queue)：默认每个QP有自己的RQ。当有成千上万个QP时，每个QP都预置大量的RECV WR会消耗大量内存。SRQ允许多个QP共享同一个接收队列，大幅节省内存资源，是构建高连接数应用（如存储服务器）的必备特性。
  2. 内联数据 (Inline Data)：对于非常小的消息（通常小于等于网卡支持的内联大小，如256字节），可以在发送WR时设置IBV_SEND_INLINE标志。这样数据内容会直接包含在WR描述符中，而不是通过SGE指向内存地址。这可以减少一次PCIe读取，进一步降低小消息延迟。
  3. 中断与轮询：默认情况下，CQ完成事件可以配置为产生中断通知应用。但在高性能场景下，中断的上下文切换开销是不可接受的。因此，高性能RDMA程序几乎总是使用忙等待轮询（Busy Polling）CQ。这就是为什么我们在示例代码中用do-while循环去poll_cq。你需要将轮询线程绑定到特定的CPU核心，以避免缓存抖动。
  4. 内存对齐与页面大小：注册内存时，起始地址和长度最好与系统页面大小（通常是4KB）对齐。非对齐的内存注册可能被允许，但某些硬件或驱动下可能会有性能损失或兼容性问题。
  5. MTU (Maximum Transmission Unit)：RDMA操作会被分割成多个数据包发送。设置合适的MTU（如1024， 2048， 4096字节）可以减少协议头开销和中断次数。通常在与网卡和交换机匹配的前提下，使用允许的最大MTU。

5.2 典型问题与排查指南

即使理解了原理，实际开发中依然会遇到各种“坑”。下面是一个常见问题速查表：

问题现象可能原因排查思路与解决方案
ibv_post_send返回EINVAL(无效参数)1. WR结构体字段填写错误（如未初始化的指针）。
2. SGE的lkey与对应的MR不匹配。
3. 远程地址或rkey无效。
4. QP状态不正确（未处于RTS状态）。		1. 使用调试器或打印检查WR和SGE每个字段的值。
2. 确认lkey来自正确的MR对象。
3. 确认从对端获取的远程地址和rkey在传输过程中没有损坏，且对端的MR依然有效（未注销）。
4. 使用ibv_query_qp检查QP的当前状态。确保按INIT->RTR->RTS顺序正确修改状态。
轮询CQ永远等不到完成事件1. 发送WR时未设置IBV_SEND_SIGNALED标志。
2. CQ创建时深度太小，事件被覆盖。
3. 网络链路不通或对端未准备RECV WR（针对SEND操作）。
4. 程序逻辑错误，轮询了错误的CQ。		1.最常犯的错误！检查wr.send_flags是否包含IBV_SEND_SIGNALED。
2. 确保CQ深度足够。一个未完成的 signaled WR 会占用一个CQ条目。
3. 用ibstat,iblinkinfo等工具检查端口状态。对于SEND，确认对端已提前post_recv。
4. 确认QP关联的CQ是你在轮询的那个。
RDMA_READ/WRITE操作成功，但对端数据未更新/错误1. 内存一致性（Memory Ordering）问题。
2. 缓存未同步。		1. RDMA操作不保证顺序。如果先后发出WRITE A和WRITE B，B可能先于A到达。需要时使用IBV_SEND_FENCE标志来建立栅栏保证顺序。
2.关键陷阱！在x86等架构上，CPU有缓存。网卡将数据直接写入物理内存，但CPU可能仍读取着自己缓存里的旧数据。解决方案：在对端CPU读取数据前，使用内存屏障（如asm volatile(“mfence” ::: “memory”)）或使用非缓存内存（在注册MR时使用`IBV_ACCESS_REMOTE_WRITE
程序运行一段时间后崩溃或出现内存错误1. 访问了已注销的MR内存。
2. 在WR完成前就释放了其关联的数据缓冲区。
3. 资源泄露（未销毁QP、CQ、MR、Context等）。		1. 确保MR的生命周期覆盖所有对其的访问（包括异步的RDMA操作）。
2.生命期管理是难点！必须保证数据缓冲区在对应的WC返回成功之前保持有效。可以使用wr_id将缓冲区指针或标识与WR关联，在轮询到WC时再安全释放。
3. 使用Valgrind等工具检查内存泄露。确保所有ibv_*_destroy或Infinity的delete调用都被正确执行。
带宽或延迟远低于预期1. PCIe带宽瓶颈（如使用PCIe 3.0 x8的网卡跑100Gbps网络）。
2. 内存带宽瓶颈（单条内存通道）。
3. 轮询线程的CPU核心与网卡NUMA节点不亲和。
4. 消息大小太小，未能打满管道。
5. 使用了非最优的传输服务类型（RC, UC, UD）。		1. 计算理论带宽：100Gbps ≈ 12.5 GB/s。PCIe 3.0 x8双向带宽约8 GB/s，已是瓶颈。考虑升级到PCIe 4.0或使用多端口分流。
2. 使用numactl将进程和内存绑定到与网卡相同的NUMA节点。
3. 使用taskset或pthread_setaffinity_np将轮询线程绑定到与网卡中断绑定的同一个CPU核心。
4. 进行流测试时，使用足够大的消息（如1MB以上）来测量峰值带宽。
5. 可靠连接（RC）开销最大但功能最全。如果应用能容忍丢包，可考虑不可靠数据报（UD）以获得更低延迟。

5.3 进阶话题：GPUDirect RDMA

在AI训练和科学计算领域，一个更极致的优化是GPUDirect RDMA。它允许RDMA网卡直接与GPU显存进行数据交换，完全绕过CPU和系统内存。流程是：网卡通过PCIe Peer-to-Peer (P2P) 直接读写远程GPU的显存。这需要：

  1. 支持GPUDirect RDMA的NVIDIA GPU和Mellanox网卡。
  2. 使用CUDA API（如cudaIpcGetMemHandle）获取GPU内存的“句柄”，并将其转换为能被RDMA识别的地址和密钥。
  3. 在注册MR时使用特殊的标志（如IBV_ACCESS_REMOTE_WRITE | IBV_ACCESS_LOCAL_WRITE，并结合驱动支持）。

这能将GPU集群间的数据交换延迟降到极低，是超大规模分布式训练的关键技术。

6. 从Demo到生产：设计模式与最佳实践

当你掌握了基本操作后，要构建一个健壮的RDMA应用，需要考虑更多工程问题。

连接管理：对于需要与多个节点通信的应用，是预先建立所有QP连接（连接池），还是按需建立？QP本身是操作系统资源，有数量限制。通常，长连接池是更优选择。

流量控制与背压：RDMA是“尽力而为”的。如果发送方速度远超接收方处理速度，会导致接收方CQ溢出或资源耗尽。需要在应用层设计流量控制协议，例如接收方在准备好接收更多消息时，通过SEND操作发送一个“信用点”（credit）给发送方。

错误处理与重连：网络可能会闪断，对端进程可能会崩溃。你的RDMA程序需要能检测到QP进入错误状态（通过异步事件IBV_EVENT_QP_FATAL），并有一套重建QP、重新注册内存、重新交换元数据并恢复业务的机制。

与现有网络栈集成：一个现实的应用很少只用RDMA。控制通道、管理接口、客户端连接可能仍然使用TCP。如何优雅地将RDMA高性能通道与传统Socket管理通道结合，是架构设计需要考虑的。

使用更现代的框架：除了Infinity，业界还有如librdmacm（简化连接管理）、rsocket（提供类似Socket的RDMA接口）、以及各大云厂商和分布式系统（如Apache Spark的rdma模块、Ceph的msgr层）内部封装的RDMA组件。根据你的项目需求选择合适的抽象层级。

在我自己的实践中，将RDMA集成到一个分布式索引服务里，最大的收获不是峰值带宽提升了多少，而是尾延迟（P99 Latency）变得极其稳定。传统TCP在系统负载高时，延迟抖动可能达到毫秒级，而RDMA能将其牢牢控制在百微秒以内。这种确定性，对于构建高性能、可预测的系统来说，价值连城。当然，与之对应的是更复杂的调试过程——你需要熟悉perf、ibv_devinfo、ibv_asyncwatch等底层工具，甚至要会看硬件计数器的统计信息。

RDMA不是银弹，它引入了新的复杂度。但对于那些真正被网络IO性能所束缚的应用来说，深入理解并应用RDMA，无疑是打开性能新世界大门的钥匙。希望这篇从原理到C++实践的长文，能成为你手中的那把钥匙。

编程学习 学习日记 实战经验
← 返回列表