Cassandra读查询一致性异常：设QUORUM却用ALL超时

问题概述 #

明明在QueryOptions和BoundStatement中设置了读请求一致性级别为QUORUM，但部分读查询因超时失败，日志显示实际要求ALL级别（需要3个副本响应，仅收到2个）。该问题仅出现在读请求，写请求完全正常。

环境配置：

• Cassandra版本：3.11.5
• Java Driver版本：3.6.0
• 集群副本策略：RF=3，3个数据中心各部署1个节点
• 读修复设置：dclocal_read_repair_chance=0.0，read_repair_chance=0.0

已确认排除CASSANDRA-7947（该问题已在对应版本修复），现需定位并解决此异常。

排查方向与解决方案 #

1. 排查副本数据分歧导致的隐式一致性升级 #

当Cassandra检测到副本间数据不一致时，即使关闭了读修复，也可能自动将读请求的一致性级别提升到ALL，以确保返回正确的数据。这种内部容错逻辑容易被忽略。

操作步骤：

• 执行nodetool repair手动修复全集群数据，消除副本间的分歧。修复完成后观察读请求是否恢复正常。
• 检查Cassandra系统日志，查找是否有Mismatch found during read repair或类似数据不一致的报错，确认是否存在数据分歧。

2. 验证Driver端一致性级别配置的优先级 #

Driver的一致性级别配置存在优先级顺序，可能出现局部配置被全局配置覆盖的情况：

• 检查Cluster.Builder中是否设置了默认读一致性级别为ALL，覆盖了QueryOptions和BoundStatement的设置。
• 排查所有查询逻辑，确认没有在特定代码路径中意外将一致性级别设置为ALL。

操作步骤：

• 在查询执行前添加日志，打印当前BoundStatement的一致性级别，确认实际生效的级别是否为QUORUM。
• 梳理所有设置一致性级别的代码位置，确保没有冲突配置。

3. 查看Cassandra节点收到的实际一致性级别 #

启用Cassandra的调试日志，确认节点收到的读请求一致性级别是否正确：

• 修改节点的logback.xml配置，将org.apache.cassandra.service.StorageProxy的日志级别调整为DEBUG。
• 触发异常读请求后，查看日志中Processing read of ... with consistency level的条目，确认Cassandra收到的一致性级别是否为QUORUM。

如果日志显示收到的是ALL，说明问题出在Driver端的配置或代码；如果收到的是QUORUM但仍触发ALL级别的检查，需进一步排查Cassandra节点的内部逻辑。

4. 升级Java Driver版本 #

当前使用的Driver版本3.6.0较旧，与Cassandra 3.11.5的兼容性可能存在已知bug。Cassandra 3.11.x系列对应的推荐Driver版本是3.11.x，版本差异可能导致一致性级别配置不生效。

操作步骤：

• 将Java Driver升级到3.11.x最新稳定版本（如3.11.10），重新部署后测试读请求是否恢复正常。

5. 确认集群节点状态与网络连通性 #

如果存在节点宕机或网络分区，可能导致Cassandra的一致性逻辑异常：

• 执行nodetool status检查所有节点状态，确保无宕机、UN状态的节点。
• 测试节点间的网络连通性，确认副本间可以正常通信，无丢包或延迟过高的情况。

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