为什么Cassandra如此依赖客户端本地时间戳？

Question

对于Cassandra来说，以下情况可能是合乎逻辑的，但对于用户来说很难。 让我们说：

Cassandra一致性级别：全部写，读一个 replication_factor：3

对于一条记录，rowkey：001，column：status

1. 客户端1，插入rowkey 001的值，状态：True，时间戳 11时00分05秒
2. 客户端2切片查询，获取rowkey 001的值True，@ 11：00：00
3. 客户端2，更新rowkey 001的值，状态：False，timestamp 11:00:02

因此，客户端更新序列为True到False，尽管更新请求来自不同的节点，但序列是逻辑排序的。

但结果是rowkey：001，column：status，value： True

那么为什么Cassandra如此依赖客户当地时间？为什么不使用服务器本地时间而不是客户端本地时间？

因为我使用的是一致性级别write all和replication_factor：3，所以对于所有3个节点，更新顺序是正确的（True - > False），它们可以给出正确的最终结果。

如果由于某种原因，它需要强大取决于操作的时间戳，那么查询操作也需要一个时间戳，那么客户端2将不会看到值True，这将发生在“future”中。

因此，无论是使用服务器时间戳还是需要时间戳进行查询（这意味着，第二步查询将看不到结果，因为数据处于“未来”），它将更加一致。

否则，Cassandra的一致性太弱，甚至R + W＆gt; Ñ

Answer 1

简短的回答是CQL实际上默认为服务器提供的时间戳。

作为一个较长的答案，我写了一篇关于时间戳在http://www.datastax.com/dev/blog/why-cassandra-doesnt-need-vector-clocks解决冲突中的作用的帖子。

Answer 2

CQL使用服务器端时间戳，但旧版Thrift接口使用客户端时间戳。

注意您所描述的不是一致性问题，因为写入后所有响应都将彼此一致。但这违反了因果关系。即使使用服务器端时间戳，您也可能会遇到同时写入相同列的问题。

这里讨论了一些问题：http://aphyr.com/posts/294-call-me-maybe-cassandra