一、一个让我熬夜到凌晨三点的bug去年做分布式存储项目，集群规模从4节点扩展到16节点，原本跑得稳稳的RDMA代码突然开始间歇性丢包。现象很诡异：业务层报写延迟抖动，从正常的5微秒跳到200微秒，偶尔还出现连接断开。抓了三天日志，最后发现是QP（Queue Pair）和CQ（Completion Queue）的绑定关系出了问题——所有QP都挂在同一个CQ上，当并发请求量上来后，CQ的轮询线程成了瓶颈，处理不过来就丢完成事件。这个坑让我意识到：RDMA高性能编程，多QP多CQ的负载均衡不是锦上添花，而是必须跨过去的坎。二、先搞清楚QP和CQ的“婚姻关系”很多新手把QP和CQ的关系理解成“一对一”，这是错的。一个CQ可以服务多个QP，但一个QP只能绑定到一个CQ（发送CQ和接收CQ可以不同，但通常我们配成同一个）。这个“一对多”的模型是性能的关键，也是问题的根源。想象一下：你开了100个QP，每个QP都在疯狂发消息，但所有完成事件都往一个CQ里塞。你的轮询线程就像春运期间的火车站检票口，一个人要处理100个窗口的旅客，不卡死才怪。更糟糕的是，CQ内部是个环形缓冲区，当事件堆积到一定程度，新的事件会被丢弃——这就是我遇到的那个间歇性丢包的真相。三、负载均衡的核心：把QP均匀分散到多个CQ上3.1 确定CQ的数量CQ的数量不是越多越好。我见过有人给每个QP配一个CQ，结果CPU被轮询线程吃满，性能反而下降。经验公式：CQ数量 = m
