一、一个让我熬夜到凌晨三点的多播问题去年做分布式存储集群的节点间心跳同步，我选了RDMA UD多播来广播状态信息。测试环境跑得飞起，一上生产就出幺蛾子——部分节点收不到心跳包，而且不是固定的节点，是随机丢。更诡异的是，用ibv_devinfo看端口状态全绿，用ibv_rc_pingpong测点对点通信也正常。当时我盯着抓包日志看了两个小时，发现一个规律：丢包总是发生在多播组成员动态变化之后。新节点加入组，老节点就开始丢包。后来翻InfiniBand规范到凌晨三点，才意识到问题出在多播组的加入/离开操作与QP状态机之间的时序竞态。这个坑让我明白：RDMA多播不是简单的“发个包到组地址”，底层涉及SM（子网管理器）的路径计算、QP的attach/detach操作、以及硬件转发表的刷新延迟。今天这篇笔记，就把这些实战中踩过的坑和解决方案掰开揉碎讲清楚。二、UD多播的底层逻辑：别被“广播”两个字骗了很多人以为RDMA多播和以太网广播一样，往一个特殊地址发数据，交换机自动复制。大错特错。RDMA多播依赖的是InfiniBand子网管理器（SM）维护的多播转发表，每个HCA端口需要显式加入多播组，SM才会在交换机的路由表中插入对应的转发条目。UD（不可靠数据报）模式下，多播通信的核心数据结构是i