我在RF = 3时运行Cassandra 2.2.1,3节点集群。如果我在一系列条目的仲裁中执行简单删除，则通过在仲裁中选择来验证结果会显示应该已删除的某些条目在表中保留。通过Java驱动程序发出的删除查询成功完成。我还使用重试策略来处理失败的删除/写入，但是这些失败的策略永远不会被调用，因为它们“成功”。我可以在100％的时间内重现问题，它通常在我向表中发出大约100个删除后开始发生。我理解墓碑和gc宽限期是如何工作的，这不是重新删除的情况。在某个地方读取它可能是一个ntp问题，但是所有3个节点都同步到同一个时钟，并且我没有任何漂移。我可以共享日志或根本原因所需的任何其他内容。谢谢！
更新： 我解决了这个问题，这似乎是一种奇怪的竞争条件，似乎与时间相关或与序列相关。如果在标记的时间戳透视图之前从插入之前发出删除，则可以在节点之间存在时间漂移，以便忽略删除。
E.G。 -insert由节点1在T1（节点1的时间戳）发出 -delete通过节点3进入系统，但标记有时间戳T0 -system断定插入后发生，因此忽略删除
这给出了一种错觉，即删除在插入之前执行，这取决于各个节点发送的时间戳。
在插入和删除之间留出足够的时间解决了我的问题，虽然我不太确定真正的根本原因是什么。
答案 0 :(得分：1)
删除和选择之间有多少时间？由于卡桑德拉有一个＆＃34;最终一致＆＃34;行为，在删除和选择之间添加延迟可以解决问题
答案 1 :(得分：1)
另一种选择是启用客户端时间戳（而不是您当前拥有的服务器端）。
如果同一客户端发出insert / update / delete，它会确保时间戳与操作调用内联。
使用客户端时间戳将无需在插入/更新和删除之间有足够的时间。
请注意，对于两个连续写入更新相同“密钥”的情况也需要正确的时间戳（并且这个错误更难检测:(）。客户端时间戳也解决了这些问题（假设同一个客户端）发出请求）