pgrac 的集群通信层抽象为三个 Interconnect Tier，在同一套 API 下覆盖从裸机 InfiniBand 到 CI 环境 TCP 环回的全部部署场景。Tier 选择在启动时由运行时探测自动决定，上层子系统（Cache Fusion、GES、SCN 广播、心跳）不感知底层网络类型——它们始终调用同一组 cluster_msg_* / cluster_rpc_* API，vtable 在内部将调用路由到对应 Tier 的实装。
三层的核心差异不是"功能有无"，而是延迟量级：Tier 1 RDMA verbs 在 Mellanox mlx5 硬件上实现 5 μs 以内的单 block 传输，Cache Fusion 的性能直接决定于此；Tier 2 RoCE 在以太网硬件上取得折中，适合预算有限但仍需 RDMA 编程模型的场景；Tier 3 TCP 将延迟推高到约 50 μs，但在 CI 环境和无 RDMA 硬件的开发机上 100% 可用。已提交事务的正确性在三个 Tier 下完全相同——Tier 影响的是吞吐与延迟，不是语义。
本章建立理解三层 Tier 策略所需的概念框架：为什么需要三个 Tier 而不是两个、Tier 1 的零拷贝数据路径如何绕开内核、Tier 2 的 RoCE 拥塞控制机制、Tier 3 自动降级的触发条件与部署前检查，以及集群运维中常见的 NIC 调优与监控实践。协议细节（vtable 数据结构、wire format、QP 池管理算法）留给深度页；本章只建立概念词汇表与运维直觉。
生产 RDMA 硬件能将 Cache Fusion 单 block 传输延迟压到 5 μs 以内，这是 pgrac 针对 Oracle RAC 对标的核心性能目标之一。但并非所有环境都有 RDMA 网卡：CI 流水线通常跑在无 InfiniBand 的虚拟机上，开发者本机几乎没有 RDMA HCA。如果直接用"有就 RDMA、没有就不支持"的二元策略，CI 测试覆盖率会急剧下降——跨节点代码路径只能在生产硬件上验证，这与 pgrac 的可测试性原则相悖。
三层 Tier 的设计解法是将硬件差异封装在 vtable 内，而不是散布到调用点：
Tier 1（RDMA verbs） — 生产首选，Mellanox mlx5 一等公民，5 μs 单 block 目标。 Tier 2（RoCE） — 以太网 RDMA 折中，通用 verbs 路径，DCQCN 拥塞控制，延迟约 5–8 μs。 Tier 3（TCP fallback） — 无 RDMA 硬件时自动选择，~50 μs，CI 与开发环境默认路径。三层共享同一套调用 API；切换由启动时探测完成，运行时不可变（PGC_POSTMASTER 等级）。
| Tier | 网络类型 | 典型延迟（CF 单 block） | 适用场景 |
|---|---|---|---|
| 1 | RDMA verbs（InfiniBand / mlx5） | < 5 μs | 生产集群，Mellanox 硬件 |
| 2 | RoCE（RDMA over Converged Ethernet） | ~5–8 μs | 以太网 RDMA，通用 HCA |
| 3 | TCP socket | ~50 μs | 无 RDMA 硬件，CI，开发机 |
这个分层也对应了 Oracle RAC 的演进路径——Oracle Exadata 初代以以太网 Private Interconnect 为主（类 Tier 2），后续引入 InfiniBand（类 Tier 1）；本项目从设计阶段就提供三层，避免后续大规模改造调用点。
cluster.interconnect_tier GUC 控制 Tier 选择，类型为 enum（stub / tier1 / tier2 / tier3）；生产环境显式配置，CI 不配置时默认走 stub（无网络桩）或 tier3（自动探测降级）。
Tier 1 实现面向 Mellanox ConnectX-5/6/7 系列 HCA，以 libibverbs 为基础 API，在其上叠加三项关键优化：MR 预注册缓存、zero-copy DMA 路径和 hugepage 对齐。这三者共同作用，将热路径的 per-message 延迟从"几十微秒"收敛到 5 μs 目标。
RDMA 发送前，发送方必须将内存缓冲区向 HCA 注册（ibv_reg_mr()），获得对应的 Memory Region 句柄（MR handle）。单次 ibv_reg_mr() 调用耗时约 2–5 μs，若每次消息都注册一次，Cache Fusion 的延迟预算会立即超支。
pgrac 的 MR 预注册缓存（mr_cache）以 {addr, size} 为 key，维护一个 LRU 哈希表：第一次向某个缓冲区发送时注册并缓存 MR handle；后续发送直接从缓存命中，不触发 ibv_reg_mr()。生产负载下 MR cache 命中率目标 > 98%。
标准 TCP send 路径：应用层 buffer → 内核 socket buffer → DMA 到 NIC，涉及至少两次内存拷贝。RDMA 的核心优势在于可以绕开内核：HCA 直接从用户态内存通过 DMA 读取数据，写入对端的用户态 buffer，全程不经过内核 socket 栈。
pgrac Tier 1 使用 RDMA Read / Write 操作走这条零拷贝路径。Cache Fusion 将 block 数据放在已注册 MR 的用户态缓冲区，发起 RDMA Write 后 HCA 自主完成传输——CPU 在传输过程中可以处理其他工作，只在 CQ（Completion Queue）收到完成事件后确认发送结束。
Sender (Node A) Receiver (Node B)
┌─────────────────┐ ┌─────────────────┐
│ userspace │ │ userspace │
│ ┌───────────┐ │ │ ┌───────────┐ │
│ │ MR / QP │ ─── RDMA Read ────▶│ │ buffer │ │
│ └───────────┘ │ │ └───────────┘ │
│ ↓ │ │ ↑ │
└───────|─────────┘ └───────|─────────┘
| |
| ╳ kernel (bypassed) |
| |
↓ ↑
NIC ───────── physical network ──────── NIC
MR 注册的效率与 TLB 命中率正相关：普通 4 KB page 下，大缓冲区的 TLB miss 率偏高；2 MB hugepage 将 TLB 覆盖范围扩大 512 倍，使 ibv_reg_mr() 的 pin 操作更高效，同时降低 DMA 期间的 TLB miss 开销。Tier 1 的 MR 分配器默认从 2 MB hugepage 池中取缓冲区，配置项为 cluster_rdma_hugepage_size（默认 2MB，可升至 1GB）。
Queue Pair（QP）是 RDMA 的通信端点，朴素方案下每个 session 对每个目标节点需要一个 QP，在 10 节点 × 1000 session 的规模下 QP 数量爆炸。Tier 1 使用 SRQ（Shared Receive Queue） 将接收端 QP 数压到 O(N × S) 量级；在 Mellanox 硬件上进一步使用 XRC（Extended Reliable Connection） 降到 O(N) 量级，保持固定 QP 数无论 session 数量如何增长。
RoCE（RDMA over Converged Ethernet）是将 RDMA verbs 协议层运行在标准以太网上的技术，不需要 InfiniBand 交换机，只要交换机支持 PFC（Priority-based Flow Control）+ ECN（Explicit Congestion Notification）即可。Tier 2 的编程模型与 Tier 1 相同——同样使用 ibv_reg_mr() / ibv_post_send() / CQ 轮询，vtable 实装只在底层 transport 层有所不同。
RoCE 在以太网上运行时，以太网本身没有 InfiniBand 的无损 flow control——若交换机缓冲溢出，数据包会被丢弃，而 RDMA RC QP 的重传机制处理丢包的开销远高于 TCP。DCQCN（Data Center Quantized Congestion Notification）是 Mellanox 提出的拥塞控制算法，在 Mellanox 硬件上由 NIC 固件原生实现：
DCQCN_ALPHA 参数控制降幅）K_MIN / K_MAX 缓冲阈值）DCQCN 运行在 NIC 固件层，对 pgrac 应用层透明。管理员需要在 RoCE 场景下确认交换机的 PFC/ECN 配置（详见 §7.5），pgrac_ctl verify rdma 会检查交换机配置状态并报告。
通用 verbs 路径（非 Mellanox 专属 XRC/DCQCN）的性能上限受以太网硬件约束：单 block CF transfer 约 5–8 μs，p99 大流量约 50 μs，带宽约 40–60 Gbps。这个量级已经比 Tier 3 TCP 快 6–10 倍，对多数预算约束下的生产集群足够。若需要 Tier 1 的极致延迟，需要换用 InfiniBand 硬件或带完整 RoCE 支持的 Mellanox NIC。
Tier 3 是 pgrac 的功能兜底层：在没有任何 RDMA 硬件的环境下，集群通信降级为标准 TCP socket，延迟约 50 μs，带宽受限于以太网，但所有跨节点语义（Cache Fusion、GES 锁协议、SCN 广播）完全正确。
启动时，rdma_feature_detect() 按以下顺序探测：
interconnect_tier 设为 TIER_3，跳过所有 RDMA 初始化路径，记录 log_warn("No RDMA HCA detected; running at Tier 3 (TCP)")。在生产部署前，建议使用 pgrac_ctl verify rdma 运行完整的硬件就绪检查：
pgrac_ctl verify rdma
├─ HCA 存在性
├─ 厂商识别（mlx5 / 其他）
├─ 驱动版本（MLNX_OFED 5.x+ 或 rdma-core 30+）
├─ Hugepage 配置（2MB / 1GB）
├─ NUMA 拓扑合理性
├─ 交换机 PFC/ECN 配置（RoCE 场景）
├─ loopback 延迟 / 带宽测试
└─ 报告最终 Tier 级别（1 / 2 / 3）
检查失败不阻塞实例启动，但未通过的检查项会以 WARNING 记录在日志中，并在 pg_cluster_rdma_status 视图的 verify_issues 字段中列出。生产部署前应当确保所有检查项通过，或理解每个未通过项的性能含义。
Tier 3 TCP 的延迟约为 Tier 1 的 10–20 倍：单 block CF transfer ~50 μs（Tier 1 目标 < 5 μs），p99 大流量约 500 μs（Tier 1 < 10 μs），CPU 占用约 40%（Tier 1 < 5%）。在生产 OLTP 负载下，Tier 3 的 Cache Fusion 吞吐通常比 Tier 1 低 5–10 倍。
对于需要 OLTP 性能但暂时没有 RDMA 硬件的场景，可以考虑先以 Tier 3 上线验证功能，同时采购 Mellanox NIC；切换到 Tier 1 只需修改 cluster.interconnect_tier = 'tier1' 并重启实例，应用层无需任何改动。
RDMA HCA 通常绑定在单一 NUMA node 上。若 IRQ 响应 CPU 和 HCA 跨 NUMA，每次中断都需要跨 NUMA 访问，延迟恶化 2–3 倍。正确的配置是将 HCA IRQ 绑定到 HCA 所在 NUMA node 的 CPU 核：
# 查询 HCA 的 NUMA node
cat /sys/class/infiniband/mlx5_0/device/numa_node
# 将 mlx5 IRQ 绑定到对应 NUMA 的 CPU set（示例：NUMA 0 对应 CPU 0-15）
for irq in $(cat /proc/interrupts | grep mlx5 | awk '{print $1}' | tr -d ':'); do
echo 0-15 > /proc/irq/$irq/smp_affinity_list
done
pgrac_ctl verify rdma 中的 NUMA 拓扑检查会自动检测并报告当前的 IRQ 绑定状态；cluster_rdma_numa_auto_bind = on（默认）开启后，pgrac 在启动时自动执行上述绑定，无需手动配置。
Hugepage 需要在 OS 层提前配置，pgrac 不会在运行时动态申请。推荐在 /etc/sysctl.conf 中设置：
vm.nr_hugepages = 1024 # 2MB × 1024 = 2GB，适合中规模集群
# 或
vm.nr_hugepages_2mb = 512
vm.nr_hugepages_1gb = 2 # 大内存服务器使用 1GB 大页
配置后重启或执行 sysctl -p 生效。cluster_rdma_hugepage_size = '2MB'（GUC 默认值）控制 pgrac 的 MR 缓冲区分配策略；若 hugepage 不可用，pgrac 降级为普通 page 并在日志记录 WARNING。
每个 RDMA QP 绑定一个 Completion Queue（CQ）。若应用层消费 CQ 的速度跟不上 NIC 产生完成事件的速度，CQ 溢出——后续的 RDMA 操作会返回错误，连接需要重建。CQ 溢出是 Tier 1 场景下少见但影响严重的故障模式。
监控方法：pg_cluster_rdma_counters 视图的 cq_overflow_count 字段，若值持续增长，通常意味着 cluster_rdma_cq_depth（默认 4096）需要调大，或应用层消费 CQ 的频率需要调整（IC Listener 进程的 poll 间隔）。
Tier 1 默认使用 SRQ（Shared Receive Queue）模式；在 Mellanox 硬件上额外启用 XRC，通过 cluster_rdma_use_xrc = auto（默认）控制。XRC 将 QP 数量从 O(N × S) 压到 O(N)，是 1000+ session 场景下维持固定 QP 资源占用的关键。若 HCA 不支持 XRC（Intel / Broadcom 部分型号），pgrac 自动退回 SRQ 模式，QP 数量随 session 数线性增长，需要在 HCA 固件配置中预留足够的 QP 资源（ibv_devinfo 中的 max_qp 字段）。
| 视图 | 关键字段 | 用途 |
|---|---|---|
pg_cluster_rdma_status | tier, hca_vendor, xrc, dcqcn | 当前 Tier 和硬件特性状态 |
pg_cluster_rdma_counters | mr_cache_hit_rate, p99_latency_us, cq_overflow_count | 性能指标与溢出告警 |
pg_cluster_rdma_errors | type, severity, description | 硬件错误事件流水 |
p99_latency_us 持续超过 10 μs（Tier 1）或 50 μs（Tier 2）是性能退化的早期信号，通常指向 CQ 溢出、NUMA 错绑或交换机 DCQCN 参数配置问题。
深度协议细节请参阅以下资源：
pg_cluster_rdma_* 视图字段定义cluster-ic-design.md — cluster_ic 框架完整设计：vtable 数据结构（ClusterICOps）、wire format（24 字节固定 header）、Stage 演进路径（Stage 0 stub → Stage 2 TCP → Stage 6+ RDMA）、双层 API（cluster_msg_* 高层 / cluster_ic_* 低层）Chapter 8 — LMS Workers 介绍 Lock Manager Service worker 进程如何通过 IC 框架发送和接收 GES 锁消息：LMS 的消息主循环、cluster_msg_recv 调用点、以及在 Tier 1 RDMA 下 LMS per-message 延迟对全局锁协议吞吐量的影响。