当短时间内写入的数据太多，或者连续扩容多个节点，都有可能导致压缩任务堆积，压缩任务堆积会导致sstable太多，让该节点查询变慢，时延变大，一直累积下去，集群会变的很不稳定。解决方法如下：

加大压缩速度阈值

默认压缩阈值是16Mb/s，偏小，可以更改的大一点，这个参数是可以通过nodetool setcompactionthroughput xx进行修改，配置文件cassandra.yaml里的默认值(配置项是compaction_throughput_mb_per_sec)，也建议修改到一个合适的值，否则某一天重启节点，又恢复到了默认值。

增加压缩线程

修改配置文件cassandra.yaml里的配置项concurrent_compactors，这个不能动态调整，需要重启生效，默认是2-8之间的一个值，取自数据盘和cpu个数的最小值，这个值一般不需要动，除非你是ssd的盘，可以适当的增加。

临时关闭gossip

如果只是其中一个节点压缩堆积，负载特别高，可以考虑先临时关闭这个节点的gossip，使用nodetool disablegossip命令。这样这个节点对于客户端而言就是DOWN的状态，客户端就不会发请求到该节点，但是集群内部之间通信正常，不会丢失数据。只要你不使用All一致性，是不会影响业务正常请求的。然后你可以把节点的压缩速度阈值调为0，也就是不限制速度，让它早点压缩完毕恢复正常。最后记得用enablegossip恢复。

临时忽略墓碑

这个方法不在cassandra的官方文档里，也没有出现在官方的changelist里。因为这是一个很危险的操作，墓碑不及时清除，会带来读操作性能问题。如果你确认短时间内不清除墓碑不会对你的业务场景产生影响，你可以尝试临时使用该方式，在压缩完成后恢复，不能长期使用。

cassandra在压缩的时候为了安全清除墓碑，会查找多个sstable文件，当压缩堆积，sstable很多的时候，压缩会变的相当缓慢。所以官方增加了这么一个彩蛋形式的配置项。这个配置项是一个环境变量，在启动的时候指定

./cassandra -Dcassandra.never_purge_tombstones=true

注意这个配置项在2.1.15版本以后才有。