LevelCompactionStrategy下Nodetool Tablestats中SSTable计数不一致咨询

嘿，这个问题我之前排查Cassandra集群的时候也碰到过，其实本质是Leveled Compaction Strategy（LCS）的压缩工作机制导致的，主要有这几个核心原因：

• 存在正在压缩的临时SSTable
  当LCS执行层级间的压缩操作（比如把L0里的SSTable合并到L1）时，会先生成一个临时的SSTable来存储合并后的数据。这个临时表会被计入tablestats返回的总SSTable count里，但因为压缩还没完成，它还没被正式分配到任何层级中，所以你把各层级的SSTable数量相加时就会少一个。等压缩完成后，这个临时表会替换掉参与压缩的旧SSTable，同时从总计数里移除临时项，此时层级相加的数值就会和总count一致了。

• 处于过渡状态的SSTable
  还有一种情况是刚完成flush的SSTable，或者刚被标记为待压缩但还没正式进入压缩流程的表。这类SSTable已经被统计到总count里，但还没被归类到具体的层级中，所以也会出现总计数比层级相加多的情况。不过这种情况持续时间很短，通常flush或压缩调度完成后就会归位。

你可以通过nodetool compactionstats命令查看当前是否有正在进行的压缩任务，或者用nodetool cfstats keyspace.table_name获取更详细的表状态信息，来验证是不是上述原因导致的差异。

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