GoCQL驱动在Cassandra 4.1集群中无法均匀分发查询请求

环境信息 #

• Go版本：1.20
• GoCQL连接池配置：Round Robin Host Policy
• Cassandra版本：4.1.3（基于OpenJDK 11）

问题描述 #

我们将Cassandra集群从3.11.16升级至4.1.3后，性能测试中发现新版本集群性能远低于旧版本。两个集群均采用2个种子节点+4个工作节点的架构，当应用以超5000 TPS的高负载发起查询时，仅1-2个Cassandra节点接收请求，最终导致响应变慢、所有查询超时。监控数据显示：

• 近99%的出入站流量集中在受影响节点的EC2实例上（每个实例仅运行1个数据库进程）
• 受影响节点CPU利用率极高
• 受影响节点垃圾回收（GC）活动明显加剧

相同代码连接3.11.16集群时无此问题，GoCQL驱动能均匀分发请求至所有节点，且两个集群的Schema和数据完全一致。

可能的排查方向 #

1. GoCQL驱动与Cassandra 4.x兼容性问题
   Cassandra 4.x对原生协议做了更新（如新增协议v5），部分旧版本GoCQL驱动可能对新协议支持存在缺陷，导致节点发现、负载均衡逻辑异常。可尝试指定驱动使用原生协议v4，或升级GoCQL到最新稳定版本，验证请求分发是否恢复正常。

2. Cassandra 4.x负载均衡相关配置变更
   Cassandra 4.0+优化了节点负载感知、请求路由逻辑，新增了load_balancing_policy相关配置，默认token-aware策略行为也有调整。对比3.11.16的cassandra.yaml配置，检查4.1.3集群是否开启了新的负载均衡特性（如enable_multi_dc_round_robin），或调整了request_scheduler相关设置。

3. EC2实例网络/元数据配置问题
   若集群部署在EC2上，Cassandra节点可能通过实例元数据获取自身IP。检查4.1.3节点的listen_address、broadcast_address配置是否正确，是否存在部分节点的广播地址无法被GoCQL驱动识别的情况，导致驱动仅向可识别节点发送请求。

4. GC参数调优适配问题
   Cassandra 4.x基于OpenJDK 11，默认GC配置可能不匹配高负载场景。受影响节点GC活动加剧会导致CPU占用过高，进而影响请求处理能力形成恶性循环。可尝试调整GC参数（如使用G1GC并设置合理堆大小、停顿时间目标），缓解节点GC压力后再观察性能表现。

5. 集群节点状态同步问题
   检查4.1.3集群中未被请求的节点状态（通过nodetool status查看），确认这些节点是否处于正常服务状态。若system.peers表数据未及时同步，可能导致GoCQL驱动的节点列表不完整，进而无法向部分节点分发请求。

内容的提问来源于stack exchange，提问作者user26663330