Cassandra 3.0.14执行select count(*)超时：3节点中2个超时原因咨询

这个问题我之前在生产环境碰到过类似的情况，结合你的集群配置和环境，咱们来拆解一下为什么相同配置的节点会出现截然不同的查询结果：

首先得明确：Cassandra的select count(*) from table不是像关系型数据库那样的快速统计，它需要全表扫描节点负责的所有token范围数据，对CPU、磁盘IO和内存的压力极大，节点间任何细微的资源差异或配置细节，都会导致请求是否超时。

可能的原因及排查方向 #

• 节点负载与硬件资源差异
  虽然配置文件一致，但实际运行中节点的资源占用可能差很多：dc1的2个节点因为副本数多，大概率承担了更多日常读写请求，磁盘IO或CPU长期处于高负载状态，执行全表扫描时根本挤不出足够资源在超时时间内完成；而dc2的节点只有1个副本，日常负载低，有冗余资源处理count(*)。
  你可以登录超时节点，用top看CPU占用、iostat看磁盘IO使用率、vmstat看swap交换情况，对比成功节点的指标就能看出差异。

• 服务端超时参数限制
  你的cqlshrc只设置了客户端的request_timeout，但Cassandra服务端还有针对范围查询的硬超时限制：range_request_timeout_in_ms（默认10000ms，也就是10秒）。如果服务端在这个时间内没完成扫描，不管客户端设置多久超时，都会直接返回"operation timed out"。
  检查下所有节点的cassandra.yaml中这个参数是否一致（虽然你说配置相同，但不排除手动修改漏了的情况），可以临时调大这个值到30000ms测试下是否还会超时。

• Token范围数据分布不均
  Cassandra是按token范围分配数据的，如果某个节点负责的token范围包含的数据量远大于其他节点，那它执行count(*)时需要扫描的数据量就多得多，耗时自然更长。
  用nodetool status查看每个节点的Owns占比，再用nodetool tablestats <你的keyspace>.<你的table>查看每个节点上该表的实际数据量，就能确认是否存在数据分布失衡的情况。如果是，可能需要做集群token重平衡或者扩容调整。

• RHEL6系统层面的限制
  RHEL6默认的系统配置不太适配Cassandra的运行需求：

  • 文件描述符限制：Cassandra需要大量文件描述符，如果节点的ulimit -n设置过低，会导致文件打开失败，拖慢数据读取速度。检查超时节点的ulimit配置是否和成功节点一致。
  • Swap滥用：如果节点启用了swap且频繁触发内存交换，会严重拖慢磁盘IO。Cassandra推荐禁用swap，或者设置vm.swappiness=1，检查超时节点的swap使用情况。
  • 磁盘故障：个别节点的磁盘存在坏道或者IO性能下降，会导致读取数据变慢，无法在超时时间内完成扫描。可以用smartctl工具检查磁盘健康状态。

• 一致性级别的隐性影响
  默认SELECT的一致性级别是ONE，但执行count(*)时，协调者节点可能需要从其他副本读取数据来保证一致性。如果超时节点作为协调者时，需要从负载高的副本取数据，而这些副本响应慢，就会导致整个请求超时；而成功节点可能刚好能从本地副本获取所有数据，速度自然更快。
  你可以尝试在cqlsh中执行CONSISTENCY LOCAL_ONE后再跑count(*)，看看是否能避免超时。

临时替代方案 #

如果只是需要获取行数，不建议用count(*)，可以用nodetool tablestats <keyspace>.<table>中的Number of keys (estimate)字段，这个是Cassandra统计的近似行数，速度极快；如果需要精确值，建议用Spark等离线工具来统计，避免影响在线集群的性能。

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