3. RDMA操作类型：Send/Recv操作、Read/Write操作、原子操作
RDMA的核心价值，说白了就是让数据在网卡和内存之间直接流动，绕过CPU。但具体怎么流动？这就涉及到它的几种操作类型了。我刚开始接触RDMA时，也被这些操作搞得有点晕，后来在项目中一个个调过，才真正理解它们的适用场景。
嗯，咱们今天就把这三种操作类型掰开揉碎讲清楚：Send/Recv、Read/Write、以及原子操作。
3.1 Send/Recv操作：最基础的通信模式
Send/Recv，你可以把它理解成传统的“发消息”模式。发送方主动把数据推出去，接收方必须提前准备好接收缓冲区。这有点像寄快递——你得先告诉对方“我要寄东西了”，对方得准备好收件地址。
核心特点：双向握手，接收方必须预先注册内存区域。
在代码层面，Send/Recv的典型流程是这样的：
// 发送端
struct ibv_send_wr send_wr;
struct ibv_sge sge;
sge.addr = (uint64_t)send_buffer;
sge.length = 1024;
sge.lkey = mr->lkey;
send_wr.wr_id = 1;
send_wr.opcode = IBV_WR_SEND;
send_wr.sg_list = &sge;
send_wr.num_sge = 1;
ibv_post_send(qp, &send_wr, &bad_wr);
// 接收端
struct ibv_recv_wr recv_wr;
struct ibv_sge sge;
sge.addr = (uint64_t)recv_buffer;
sge.length = 2048;
sge.lkey = mr->lkey;
recv_wr.wr_id = 1;
recv_wr.sg_list = &sge;
recv_wr.num_sge = 1;
ibv_post_recv(qp, &recv_wr, &bad_wr);我个人习惯在控制面通信中使用Send/Recv。比如集群节点之间的心跳检测、小规模的控制指令交换。为什么？因为它的语义简单，出错容易排查。我曾经在一个项目中，用Send/Recv做节点间的状态同步，调试起来非常直观——发没发出去，收没收回来，一目了然。
小提示：Send/Recv的接收缓冲区必须提前post，否则发送端的数据会直接被丢弃。我在项目中见过不少新手踩这个坑——接收端还没准备好，发送端就猛发，结果数据丢了还一脸懵。
3.2 Read/Write操作：真正的零拷贝
Read/Write操作，这才是RDMA的精髓。它允许一台机器直接读写另一台机器的内存，完全不需要对方CPU参与。你想想看，这有多恐怖——你的应用可以直接把数据塞到远端的内存里，就像操作本地内存一样。
我举个例子：假设你有两台服务器，A和B。A想读取B的一块数据。如果用传统TCP，流程是：A发请求 → B的CPU处理 → B拷贝数据到socket → A接收。但用RDMA Read，A直接发一个Read请求，B的网卡就把数据从内存里捞出来，通过网络送到A的内存里。B的CPU全程不用管。
核心特点：单边操作，远端CPU零参与，真正的内存语义访问。
Write操作类似，只是方向反过来。A直接往B的内存里写数据。这在分布式存储、数据库场景中特别有用。
代码示例：
// RDMA Read操作
struct ibv_send_wr read_wr;
struct ibv_sge sge;
// 本地缓冲区（数据读到这里）
sge.addr = (uint64_t)local_buffer;
sge.length = 4096;
sge.lkey = local_mr->lkey;
read_wr.wr_id = 2;
read_wr.opcode = IBV_WR_RDMA_READ;
read_wr.sg_list = &sge;
read_wr.num_sge = 1;
// 远端地址和rkey
read_wr.wr.rdma.remote_addr = remote_addr;
read_wr.wr.rdma.rkey = remote_mr->rkey;
ibv_post_send(qp, &read_wr, &bad_wr);这里有个关键点：rkey。远端内存区域必须提前注册，并且把rkey告诉发送方。没有rkey，你读不了也写不了。这是RDMA的安全机制。
注意：Read/Write操作需要远端内存提前注册并暴露rkey。我曾经见过一个生产事故，有人把rkey写死在配置文件里，结果内存泄漏排查了三天。rkey的生命周期管理一定要小心。
3.3 原子操作：无锁并发的基础
原子操作，这是RDMA里最“硬核”的部分。它允许你在远端内存上执行原子的比较并交换（CAS）或取并加（Fetch-and-Add）。
为什么要这个？你想想看，分布式场景下，多个节点同时访问同一个变量，怎么保证一致性？传统做法是用锁，但锁的开销很大。RDMA原子操作直接在网卡硬件层面完成，不需要任何软件锁。
| 操作类型 | 描述 | 典型应用 |
|---|---|---|
| Fetch-and-Add | 读取远端值，加上一个增量，写回 | 分布式计数器、统计 |
| Compare-and-Swap | 比较远端值，如果相等则交换 | 分布式锁、共识算法 |
代码示例（CAS操作）：
struct ibv_send_wr cas_wr;
struct ibv_sge sge;
// 本地存放比较值和交换值
uint64_t compare_value = 100;
uint64_t swap_value = 200;
sge.addr = (uint64_t)&compare_value;
sge.length = 8;
sge.lkey = local_mr->lkey;
cas_wr.wr_id = 3;
cas_wr.opcode = IBV_WR_ATOMIC_CMP_AND_SWP;
cas_wr.sg_list = &sge;
cas_wr.num_sge = 1;
cas_wr.wr.atomic.remote_addr = remote_addr;
cas_wr.wr.atomic.rkey = remote_mr->rkey;
cas_wr.wr.atomic.compare_add = compare_value;
cas_wr.wr.atomic.swap = swap_value;
ibv_post_send(qp, &cas_wr, &bad_wr);我记得在做一个分布式锁服务时，就用RDMA CAS实现了无锁的锁获取。性能比基于TCP的ZooKeeper高了两个数量级。当然，原子操作也有局限——它只能操作8字节的数据，而且不是所有网卡都支持。
经验之谈：原子操作虽然强大，但别滥用。它适合做轻量级的同步原语，比如计数器、标志位。如果你要传输大量数据，还是用Read/Write更合适。
3.4 三种操作的对比与选择
说了这么多，到底什么时候用哪种？我画了一张图，帮你理清思路：
总结一下我的个人经验：
- 小数据、需要确认的场景 → Send/Recv。比如集群节点间的握手、状态同步。
- 大数据、追求极致性能 → Read/Write。比如分布式数据库的日志复制、键值存储。
- 需要无锁并发控制 → 原子操作。比如分布式计数器、锁服务。
避坑指南：我曾经在一个项目中，用RDMA Write做数据复制，但没处理好写完成的确认机制。结果数据写了一半，远端就认为完成了，导致数据不一致。记住：Write操作是“发后不管”的，如果你需要确认，要么用Send/Recv，要么配合完成事件（Completion Event）来确认。
好了，这三种操作类型就讲到这里。每种都有它的脾气，选对了事半功倍，选错了调试到怀疑人生。嗯，多动手写代码，多跑测试，慢慢就能找到感觉了。