Cassandra 删除工作不一致

Question

我正在运行 Cassandra 2.2.1，3 节点集群，RF=3。如果我在 quorum 上对一堆条目执行简单删除，通过 select at quorum 验证结果会发现一些应该被删除的条目仍然存在于表中。通过 Java 驱动程序发出的删除查询无一例外地成功完成。我还使用重试策略来处理失败的删除/写入，但这些失败的策略永远不会被调用，因为它们“成功”了。我可以 100% 地重现问题，它通常在我向表中发出大约 100 次删除后开始发生。我了解墓碑和 gc 宽限期的工作原理，这不是恢复删除的情况。在某处读到这可能是一个 ntp 问题，但所有 3 个节点都同步到同一个时钟，而且我可以说没有漂移。我可以共享日志或根本原因所需的任何其他内容。谢谢！

更新： 我解决了这个问题，这似乎是一个奇怪的竞争条件，似乎与时间相关或与顺序相关。如果从标记时间戳的角度来看，如果在插入之前发出删除，则节点之间有一些时间漂移可能会被忽略。

例如 -insert 由节点 1 在 T1 发出（节点 1 的时间戳） -delete 通过节点 3 进入系统，但带有时间戳 T0 -system 推断插入发生在稍后，因此忽略删除

这给人一种错觉，即删除在插入之前执行，具体取决于各个节点发送的时间戳。

在插入和删除之间留出足够的时间解决了我的问题，尽管我不太确定真正的根本原因是什么。

Answer 1

另一个选项是启用客户端时间戳（而不是您当前拥有的服务器端）。

如果同一个客户端发出插入/更新/删除，它确保时间戳将与操作调用内联。

使用客户端时间戳将无需在插入/更新和删除之间有“足够的时间”。

请注意，在两次连续写入更新相同“密钥”的情况下，也需要正确的时间戳（并且此错误更难检测：（）。客户端时间戳也可以解决此类问题（假设相同的客户端发出请求）

Answer 2

删除和选择之间有多少时间？由于 Cassandra 具有“最终一致”的行为，因此在删除和选择之间添加延迟可能会解决问题