1

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

Cassandra 一致性级别：写所有，读一个 replication_factor：3

对于一条记录，rowkey:001, column:status

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

所以客户端的更新顺序是True to False，虽然更新请求来自不同的节点，但是顺序是有逻辑顺序的。

但结果是 rowkey:001, column:status, value: True

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

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

如果由于某种原因，它需要强依赖于操作的时间戳，那么查询操作也需要时间戳，那么客户端 2 将看不到值 True，这将在“未来”发生。

所以无论是使用服务器时间戳还是查询也需要时间戳（这意味着，第二步查询不会看到结果，因为数据在“未来”中），它会更加一致。

否则，Cassandra 的一致性太弱了，甚至 R + W > N。

4

2 回答 2

4

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

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

于 2013-10-09T21:23:15.350 回答
0

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

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

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

于 2013-10-08T10:02:18.927 回答