赵岩的博客

分布式删除的难题

考虑上面的情况，强一致性是必须的，让我们暂且忘掉墓碑这个东西，假设cassandra删除数据不使用墓碑。如果一次删除操作在一个节点上失败了（总共3个节点，副本为3， RF=3).整个删除操作仍然被认为成功的（因为有两个节点应答成功，使用CL.QUORUM一致性）。接下来如果读发生在该节点上就会变的不明确，因为结果返回是空，还是返回数据，没有办法确定哪一种是正确的。Cassandra总是任务返回数据是对的，那就会发生删除的数据又出现了的事情，这些数据可以叫”僵尸”或者”鬼”，并且他们的表现是不可预见的

注意：这个问题没有完全解决，即便使用了墓碑，所以假设你的集群有删除操作的话我们还要有如下操作: Cassandra运维人员必须在每个gc_grace_seconds周期内对整个集群进行repair操作。

从一个Cassandra节点的视角看待删除

Cassandra使用一旦写入就不再改变的文件来存储数据，像前面描述，墓碑的目的就是为了解决从这样的系统中删除数据的困难的。

Cassanda的一个特种就是使用了一种日志结构合并树（LSM tree），然而大多数关系型数据库（RDBMS）是使用的B树（B-tree)。这样说你可能更容易理解:记住Cassandra写的时候总是往后追加数据，读的时候才会综合这些写入片段，选择每列的最大版本号去返回。

LSM Trees还有一个属性是数据写入文件中就不可以更改（这些文件在Cassandra中叫做SSTables）。正如最初讨论的那样，显然对于这样一个系统，删除只能通过一种特殊的写来实现。读的时候根据墓碑的时间戳，忽略小于这个时间戳之前插入的数据。