为什么 Cassandra 集群需要节点间同步时钟? [英] Why Cassandra cluster need synchronized clocks between nodes?

问题描述

在Cassandra DataStax介绍课程中，他们说Cassandra集群节点的所有时钟，必须同步，以防止对旧"数据的 READ 查询.

In the introduction course of Cassandra DataStax they say that all of the clocks of a Cassandra cluster nodes, have to be synchronized, in order to prevent READ queries to 'old' data.

如果一个或多个节点宕机，它们将无法获得更新，但是一旦它们再次备份——它们就会更新并且没有问题......

If one or more nodes are down they can not get updates, but as soon as they back up again - they would update and there is no problem...

那么，为什么 Cassandra 集群需要节点之间的时钟同步?

So, why Cassandra cluster need synchronized clocks between nodes?

推荐答案

总的来说，保持服务器时钟同步总是一个好主意，但节点之间需要时钟同步的主要原因是因为 Cassandra 使用了一个概念称为Last Write Wins"以解决冲突并确定哪个突变代表最正确的最新数据状态.为什么 cassandra 不需要矢量时钟.

In general it is always a good idea to keep your server clocks in sync, but a primary reason why clock sync is needed between nodes is because Cassandra uses a concept called 'Last Write Wins' to resolve conflicts and determine which mutation represents the most correct up-to date state of data. This is explained in Why cassandra doesn't need vector clocks.

每当您在 cassandra 中改变"(写入或删除)列时，处理您的请求的协调器都会分配一个时间戳.该时间戳与单元格中的列值一起写入.

Whenever you 'mutate' (write or delete) column(s) in cassandra a timestamp is assigned by the coordinator handling your request. That timestamp is written with the column value in a cell.

当发生读取请求时，cassandra 会构建您的结果以查找查询条件的突变，当它看到多个代表同一列的单元格时，它将选择具有最新时间戳的单元格(读取路径比这更复杂，但是这就是您在此上下文中需要知道的全部内容).

When a read request occurs, cassandra builds your results finding the mutations for your query criteria and when it sees multiple cells representing the same column it will pick the one with the most recent timestamp (The read path is more involved than this but that is all you need to know in this context).

当您节点的时钟不同步时，事情就会开始出现问题.正如我所提到的，处理您的请求的协调器节点会分配时间戳.如果对同一列进行多次更改并分配了不同的协调器，则可能会产生一些情况，即返回过去发生的写入而不是最近的写入.

Things start to become problematic when your nodes' clocks become out of sync. As I mentioned, the coordinator node handling your request assigns the timestamp. If you do multiple mutations to the same column and different coordinators are assigned, you can create some situations where writes that happened in the past are returned instead of the most recent one.

这是一个基本场景，描述了:

Here is a basic scenario that describes that:

假设我们有一个包含节点 A 和 B 的 2 节点集群.让我们假设初始状态，其中 A 在时间 t10，B 在时间 t5.

Assume we have a 2 node cluster with nodes A and B. Lets assume an initial state where A is at time t10 and B is at time t5.

1. 用户执行DELETE C FROM tbl WHERE key=5.节点 A 协调请求并为其分配时间戳 t10.
2. 一秒钟后，用户执行 UPDATE tbl SET C='data' where key=5.节点 B 协调请求并为其分配时间戳 t6.
3. 用户执行查询 SELECT C from tbl where key=5.由于步骤 1 中的 DELETE 具有更新的时间戳 (t10 > t6)，因此不会返回任何结果.

1. User executes DELETE C FROM tbl WHERE key=5. Node A coordinates the request and it is assigned timestamp t10.
2. A second passes and a User executes UPDATE tbl SET C='data' where key=5. Node B coordinates the request and it is assigned timestamp t6.
3. User executes the query SELECT C from tbl where key=5. Because the DELETE from Step 1 has a more recent timestamp (t10 > t6), no results are returned.

请注意，较新版本的 datastax 驱动程序将开始默认使用客户端时间戳来让您的客户端应用程序生成并为请求分配时间戳，而不是依赖 C* 节点来分配它们.datastax java-driver 从 3.0 开始默认为客户端时间戳(在 '客户端生成').如果所有请求都来自同一个客户端，这非常好，但是如果您有多个应用程序写入 cassandra，您现在必须担心保持客户端时钟同步.

Note that newer versions of the datastax drivers will start defaulting to use Client Timestamps to have your client application generate and assign timestamps to requests instead of relying on the C* nodes to assign them. datastax java-driver as of 3.0 now defaults to client timestamps (read more about there in 'Client-side generation'). This is very nice if all requests come from the same client, however if you have multiple applications writing to cassandra you now have to worry about keeping your client clocks in sync.

这篇关于为什么 Cassandra 集群需要节点间同步时钟?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！