Cassandra节点磁盘读I/O过高问题：3节点集群读负载持续增长引发服务降级

根因定位 #

从提供的nodetool tpstats与nodetool cfstats输出可以判断，问题核心是墓碑累积导致的读放大持续升高，具体触发点如下：

• 表内未清理的过期/删除数据（墓碑）占比过高：messages表每次读请求平均会扫描到1.19个墓碑，说明近1/3的扫描内容为无效数据。Cassandra默认的gc_grace_seconds为10天，墓碑只有在压缩操作执行且超过保留周期时才会被清理，若压缩策略不匹配，墓碑会随运行时间持续累积，读操作需要过滤的无效数据越来越多，磁盘读负载就会持续上涨。清空keyspace会直接删除所有墓碑与旧SSTable，因此可以临时缓解问题。
• Bloom filter假阳性率偏高：当前Bloom filter假阳性率为0.00841，是默认值0.00075的11倍，会导致每次读请求额外访问不必要的SSTable，进一步放大磁盘IO开销。
• 压缩策略适配性不足：当前SSTable数量仅6个但读放大极高，大概率使用了默认的SizeTieredCompactionStrategy（STCS），该策略针对写多场景优化，对存在大量删除/过期数据的场景墓碑清理效率极低，进一步加剧了读负载累积问题。

长期解决方案（无需清空keyspace） #

• 参数优化 #

  1. 调整墓碑保留周期：结合业务一致性要求，调低messages表的gc_grace_seconds参数，若业务不需要10天的数据修复窗口，可调整为1天（86400秒），加快墓碑清理速度。
  2. 优化Bloom filter精度：将bloom_filter_fp_chance参数调整为默认值0.00075，降低假阳性率，减少不必要的SSTable读取，当前表Bloom filter内存占用仅6.56MiB，精度提升带来的内存开销完全可控。
  3. 调整单分区墓碑清理阈值：将tombstone_threshold参数调低到0.1~0.2，当单个分区内墓碑占比超过阈值时，会触发单独的压缩操作清理该分区的无效数据。

• 压缩策略调整 #

  将messages表的压缩策略从STCS更换为LeveledCompactionStrategy（LCS），LCS针对读多场景优化，压缩效率更高，读放大更低，且墓碑清理更及时，完全匹配当前业务的负载特征。

• 运维优化 #

  1. 按业务周期定期执行nodetool repair，避免数据不一致导致墓碑无法正常清理。
  2. 若业务数据有明确的生命周期，为对应字段设置TTL，让数据自动过期，减少手动删除产生的墓碑。
  3. 新增读放大、墓碑占比等核心指标监控，提前预警负载上涨风险。

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