cassandra列数据在长时间延迟和不正确的时间戳后出现

Question

我正在使用带有标准列类型和复合类型键的cassandra列族。 cassandra集群有3个节点，复制因子为3.数据从列族中插入，更新和删除。

例如，假设列族的当前状态为

Row X  
column=1:a, value=v1, timestamp=1000  
column=1:b, value=v2, timestamp=1010  
column=2:a, value=v3, timestamp=1020  

在Row X列可以更新，有时会插入或删除新行的一段时间内会发生许多更新。

我观察到的问题是假设将带有键2的列：a在timestamp=1030更新为值v4。当我使用cassandra-cli来观察数据时，它甚至在几个小时之后也没有显示关键字2：a。之后，键1：a，1：b被删除并最终 - 几小时后，键2：a出现，但时间戳早于1030 - 比如说990.

我读到如果节点之间存在时钟差异，那么具有最新时间戳的写入器会写入其他时间戳。如果它们是相同的，则较高的值优先于字典值较低的值。但是，在我的情况下，只有一个编写器进程更新列系列，编写器只更新密钥2：a后来删除1：a和1：b。因此，同一个密钥没有多个编写器。编写器是多线程的，因此线程触摸各种键，但不是相同的键。

所以我的问题是：

1. 在什么情况下，即使在写作发生后的很长一段时间内，我们还有钥匙无法显示？
2. 什么会导致密钥的时间戳搞乱？在上面的例子中，2：a应该有1030的时间戳，但最终看到它时显示990。

有人可以分享一些可能出错的指示，或者如何解决问题，或者有任何有用的文章来分析问题？

Answer 1

Cassandra不会立即删除数据。列标记为墓碑，稍后将通过压缩删除，这解释了几个小时的滞后。无论是否标记为墓碑，始终将具有最高时间戳的环中的数据选择为正确的值。虽然我无法确定，节点时间不同步很可能是您的情况发生的情况。我强烈建议您在所有机器上安装ntp，等到所有时间都同步并再次尝试测试。