Cassandra集群跨节点是否应返回一致结果？count(*)结果差异排查

问题1：该情况是否属于预期行为 #

这是符合Cassandra底层查询逻辑的可复现现象，不属于集群故障，但不符合业务层面全局计数的预期结果。
默认情况下，你直接在单个节点执行select count(*) from my_table时，若没有显式指定全局一致性级别，查询默认仅统计当前节点本地存储的该表分片副本对应的行数，不会主动拉取其他节点的分片数据做全局汇总。如果你的表副本数配置小于集群节点数、副本分配不均、数据同步未完成，每个节点本地持有的数据量本身就存在差异，自然会返回完全不同的计数结果。

问题2：排查影响因素参考 #

• 检查keyspace副本配置：执行desc keyspace <你的keyspace名称>;查看replication策略配置，若单数据中心3节点集群的副本数设置为1，每个数据分片仅会存储在1个节点上，三个节点本地数据之和才是全量数据，单独查询每个节点的计数必然不同。
• 验证一致性级别影响：执行count查询前先执行CONSISTENCY ALL;，再执行count语句看返回结果是否一致。如果返回正确的2997，说明问题是默认一致性级别过低，查询仅读取了当前节点本地数据。注意CONSISTENCY ALL会强制所有持有对应分片副本的节点返回结果后再做汇总，性能较差，仅适合小表测试使用。
• 排查数据同步状态：执行nodetool repair <你的keyspace名称> my_table对该表做一次全量修复，之后再逐个节点查询本地计数，若差异消失，说明之前存在写入部分成功、副本同步滞后的问题。
• 检查墓碑清理状态：如果之前对该表做过大量删除操作，部分节点的删除标记（墓碑）还未达到gc_grace_seconds的清理时间，count统计时会自动过滤墓碑，也会导致计数差异。可执行nodetool gcstats查看各节点的垃圾回收状态，确认是否有未清理的墓碑影响计数。
• 核对写入一致性配置：如果写入数据时使用的是低于QUORUM的一致性级别（比如ANY、ONE），可能存在写入请求仅成功写入部分节点就返回成功，剩余副本未完成同步的情况，也会导致不同节点本地数据量存在差异。

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