Apache Cassandra作为分布式宽列存储，在大规模写入场景下表现稳定，但随业务增长，单表性能退化常常难以察觉。cfstats是nodetool提供的子命令，用于输出指定keyspace下各表的详细统计信息，涵盖存储占用、内存表大小、读写延迟、SSTable文件数以及缓存状态。理解这些字段，是做容量规划和性能调优的前提。很多故障并不是突然发生，而是表统计中的某些数值早已偏离常态。
cfstats输出结构与各字段含义
执行nodetool cfstats命令后，系统会按keyspace和表名分段打印统计块。每一段中以键值对形式展示，例如Space Used Total表示磁盘上该表占用的总空间，Memtable Data Size反映当前驻留内存的待刷写数据量。这两个值若出现Memtable持续偏高而Space Used增长缓慢，通常说明刷写线程阻塞或写入突发。另一组关键指标是SSTable Count与Read Latency，SSTable文件过多会直接拉长读路径，因为一次读取可能要扫描多个文件。
在统计块中还能看到Bloom Filter False Positives与Bloom Filter False Ratio，它们揭示布隆过滤器的误判情况。当误判率超过零点零一时，说明过滤器效率下降，大量读请求会穿透到不存在数据的SSTable上，浪费IO。此外Compression Ratio显示压缩比，如果比值接近一，代表压缩几乎无效，可能是数据本身随机或压缩算法不匹配。通过这些字段的交叉比对，可以初步判断表是否健康。
对于缓存相关指标，Key Cache Hit Rate与Row Cache Hit Rate直接体现缓存收益。若命中率低于百分之二十且读延迟高，应考虑调整缓存大小或关闭行缓存。以下命令可只输出单个表，减少干扰信息：
nodetool cfstats my_keyspace.my_table
该命令在排查特定表时非常实用，避免在全量输出中遗漏细节。结合watch命令还能做定时采样，观察指标随时间的变化趋势。
利用统计信息定位SSTable膨胀与压缩滞后
SSTable膨胀是Cassandra常见痛点。cfstats中的SSTable Count若达到数百甚至上千，基本可以确定compaction策略未能及时合并。默认SizeTieredCompaction会因写入模式产生大量重叠文件，此时Space Used By SSTables与Space Used Total差值过小，说明几乎没有冗余空间可回收。我们需要对比不同时间点的计数，若每小时新增十以上且未下降，必须介入。
另一个隐藏信号是Number of Partitions与Local Read Count的比例。当分区数远大于活跃读次数，意味着大量冷分区占用文件，却很少被访问。此时可考虑改用TimeWindowCompactionStrategy，让旧时间窗数据整块淘汰。下面的Java片段模拟了如何解析cfstats文本提取SSTable数量：
import java.io.BufferedReader;
import java.io.InputStreamReader;
public class CfstatsParser {
public static void main(String[] args) throws Exception {
Process p = Runtime.getRuntime().exec("nodetool cfstats my_keyspace.my_table");
BufferedReader reader = new BufferedReader(new InputStreamReader(p.getInputStream()));
String line;
while ((line = reader.readLine()) != null) {
if (line.contains("SSTable Count")) {
String value = line.split(":")[1].trim();
System.out.println("当前SSTable数: " + value);
}
}
}
}
上述代码通过运行时调用nodetool并读取输出，适合集成到监控脚本。要注意的是，直接在生产节点频繁执行cfstats会造成轻微负担，建议采样间隔不小于一分钟。当确认膨胀后，可手动触发nodetool compact强制合并，但需在低峰期操作以免IO打满。
基于读写延迟与缓存指标优化表设计
读延迟字段Read Latency和Local Read Latency常以微秒或毫秒显示，若其值较历史基线翻倍，首先看Rock Cache Hit Rate类指标。如果命中率低，说明重复查询未命中缓存，可能主键设计不合理导致无法利用缓存局部性。此时应审查分区键粒度，避免过宽分区使单行读取拉动整块数据。
写延迟Write Latency突增则多与Memtable Data Size及Pending Flushes有关。当内存表超过阈值却来不及刷盘，写线程会阻塞。cfstats虽不直接显示pending，但可结合Memtable Columns Count估算。若发现某表频繁刷写，应调大memtable_flush_writers或拆分高频写表。如下CQL展示了建表时指定压缩与compaction策略，从根源缓解统计恶化：
CREATE TABLE my_keyspace.metrics (
id uuid PRIMARY KEY,
value text
) WITH compaction = {
'class': 'TimeWindowCompactionStrategy',
'compaction_window_unit': 'HOURS',
'compaction_window_size': 1
} AND compression = {
'sstable_compression': 'LZ4Compressor'
};
通过cfstats持续观察上述表的Compression Ratio与SSTable Count，能验证策略有效性。若压缩比提升至零点三以下且文件数稳定，说明调优成功。总之，cfstats不是孤立快照，而是动态运维的仪表盘，只有将字段放入业务上下文中解读，才能准确捕捉性能瓶颈。