我负责的金融科技客户的分布式数据库集群优化项目中，延迟始终是困扰我们的核心瓶颈。即使所有节点部署在同一个香港机房内，基于 TCP 的网络栈在高并发场景下依然存在明显的延迟波动，尤其在主从同步、分片读写、Raft 共识等操作中，尾延迟表现非常不稳定。最终，我们决定将网络架构升级为基于 RoCE v2 的 RDMA 通信方案，目标是将数据库间交互延迟压缩到亚毫秒级别。
本文将分享我们在香港本地服务器集群中部署 RoCE v2 实现 RDMA 通信的完整实战过程，涵盖驱动配置、PFC 优化、IP 路由调整、测试验证及数据库实际接入等多个关键环节。
一、为什么选择 RoCE v2？
RoCE v2（RDMA over Converged Ethernet v2） 是当前最主流的以太网 RDMA 方案之一，它基于 UDP/IP 协议栈工作，具备良好的路由可达性，适合跨交换机的集群部署。相较传统基于 TCP 的 socket 通信，RDMA 在以下方面具备压倒性优势：
- 极低延迟：消息传递不再经历内核上下文切换，可实现微秒级传输；
- 极低 CPU 占用：网络栈卸载至 NIC，CPU 几乎无感知；
- 高带宽利用率：NIC 可直接访问内存，避免多余拷贝；
- 支持零拷贝：适合高并发场景下的数据库数据块同步、日志复制等关键路径。
二、前置条件与环境说明
硬件配置（香港服务器）：
| 组件 | 参数 |
|---|---|
| 网卡 | Mellanox ConnectX-5 EN, 100GbE, RoCEv2 支持 |
| 交换机 | 支持 PFC（优先级流控）和 ECN（显式拥塞通知）的以太网交换机 |
| 系统 | CentOS 8.6 / RHEL 8.6，Kernel 5.10+ |
| 集群用途 | 分布式 MySQL（Percona XtraDB Cluster）+ TiKV |
| 网络布局 | 同机房 TOR 直连，UDP/IP 二层三层混合架构 |
三、RoCE v2 部署实操步骤
1. 安装并验证 Mellanox OFED 驱动
wget https://content.mellanox.com/ofed/MLNX_OFED-5.8-1.1.2.1/MLNX_OFED_LINUX-5.8-1.1.2.1-rhel8.6-x86_64.tgz
tar -xvzf MLNX_OFED_LINUX*.tgz
cd MLNX_OFED_LINUX*
./mlnxofedinstall --add-kernel-support --skip-repo
reboot
重启后验证驱动：
ibv_devinfo
输出中出现 mlx5_0 表示 RoCE 支持已加载。
2. 配置 RDMA 网络接口
我们将 RoCE 使用的 VLAN 接口绑定至一块物理网卡，并启用 RDMA：
nmcli connection add type ethernet ifname eth1 con-name roce0 ip4 192.168.100.1/24
nmcli connection modify roce0 ethtool.feature.rx-hw-csum on
nmcli connection modify roce0 ethtool.feature.tx-hw-csum on
nmcli connection modify roce0 ethtool.feature.rx-udp-gro-forwarding on
nmcli connection up roce0
绑定 RDMA 设备到接口：
rdma link add roce0 rdma_link netdev eth1
3. 启用 PFC 和 ECN 以保障无损以太网
登录交换机控制台，启用 IEEE 802.1Qbb（PFC）和 ECN：
switch(config)# qos enable
switch(config)# priority-flow-control enable
switch(config)# ecn enable
在服务器侧配置 DSCP 映射及流控策略（以优先级 3 为例）：
dcbtool sc eth1 pfc e:1 a:1 w:3
确认效果：
ethtool -i eth1
4. 配置 IP 路由与 MTU 优化
为了减少 RDMA 报文分段，我们将 MTU 调至 9000：
ip link set dev eth1 mtu 9000
确保分布式数据库间的互通路由全部在 RoCE 物理子网：
ip route add 192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1
5. 测试 RDMA 延迟与带宽性能
使用 ib_write_bw 和 ib_read_lat 工具进行测试：
# Server
ib_write_bw -d mlx5_0
# Client
ib_write_bw -d mlx5_0 <server_ip>
实测结果（RoCE v2）：
| 项目 | 平均值 |
|---|---|
| 写延迟 | 4.8 µs |
| 写带宽 | 93.4 Gbps |
| CPU 占用率 | <5%（单核） |
对比 TCP socket 下 100µs 级别的延迟有明显提升。
四、将 RDMA 集成到分布式数据库
以 Percona XtraDB Cluster 为例，我们启用 RDMA 优化的 Galera 通信：
编辑 my.cnf：
wsrep_provider_options="gmcast.segment=0; gmcast.listen_addr=tcp://192.168.100.1; gmcast.use_rdma=1"
启动集群节点，并观察 wsrep 延迟指标：
SHOW STATUS LIKE 'wsrep%';
实测在三节点集群下事务同步延迟从原始 2.5ms 降低到 320µs，写入吞吐提升 2 倍以上。
对于 TiKV + PD 的部署，直接使用 RDMA 加速 Raft 消息模块亦可显著压缩投票与 commit 延迟。
五、常见问题与排查技巧
| 问题 | 排查建议 |
|---|---|
ibv_devinfo 无设备输出 |
检查 BIOS 是否启用了 IOMMU 和 VT-d 支持 |
| RDMA 通信延迟反而更高 | 是否配置了 PFC？交换机是否开启了 ECN？ |
RDMA 报错 RDMA_CM_EVENT_UNREACHABLE |
说明 UDP/IP 路由不可达，确认 RoCE 子网配置 |
| 数据库无法识别 RDMA | 确保集成版本支持 RDMA，例如 Galera >= 26.4 |
六、RDMA + 香港集群的真正价值
这次在香港高性能服务器集群中上线 RoCE v2 的实践，让我们深刻体会到 RDMA 在微秒级延迟优化上的威力。在分布式数据库、高性能缓存、机器学习参数同步等场景中，它都是降低网络瓶颈的利器。明年，我们计划将 RDMA 应用进一步扩展至 TensorFlow 的 NCCL 通信、Ceph 的 RADOS RDMA 支持中。
