在introduction course of Cassandra DataStax 中，他们说 Cassandra 集群节点的所有时钟都必须同步，以防止对“旧”数据进行 READ 查询。
如果一个或多个节点出现故障，它们将无法获得更新，但一旦它们再次备份 - 它们就会更新并且没有问题...
那么，为什么 Cassandra 集群需要在节点之间同步时钟？
【问题讨论】：
标签： cassandra
一般来说，保持服务器时钟同步总是一个好主意，但节点之间需要时钟同步的一个主要原因是因为 Cassandra 使用一个名为“Last Write Wins”的概念来解决冲突并确定哪个突变代表最正确的最新数据状态。这在Why cassandra doesn't need vector clocks 中有解释。
每当您在 cassandra 中“改变”（写入或删除）列时，处理您的请求的协调器都会分配一个时间戳。该时间戳与单元格中的列值一起写入。
当发生读取请求时，cassandra 会构建您的结果以查找查询条件的突变，当它看到代表同一列的多个单元格时，它将选择具有最新时间戳的单元格（读取路径比这更复杂，但是这就是您在这种情况下需要知道的全部内容）。
当您的节点时钟不同步时，事情就会开始出现问题。正如我所提到的，处理您的请求的协调节点会分配时间戳。如果您对同一列进行多次更改并分配了不同的协调器，则可以创建一些情况，其中返回过去发生的写入而不是最近发生的写入。
这是一个基本场景，描述了这一点：
假设我们有一个包含节点 A 和 B 的 2 节点集群。让我们假设 A 在时间 t10 和 B 在时间 t5 的初始状态。
DELETE C FROM tbl WHERE key=5。节点 A 协调请求并为其分配时间戳t10。UPDATE tbl SET C='data' where key=5。节点 B 协调请求并为其分配时间戳t6。SELECT C from tbl where key=5。由于第 1 步中的 DELETE 具有更新的时间戳 (t10 > t6)，因此不会返回任何结果。请注意，较新版本的 datastax 驱动程序将开始默认使用客户端时间戳来让您的客户端应用程序生成时间戳并将其分配给请求，而不是依赖 C* 节点来分配它们。从 3.0 开始的 datastax java-driver 现在默认为客户端时间戳（在'Client-side generation' 中了解更多信息）。如果所有请求都来自同一个客户端，这非常好，但是如果您有多个应用程序写入 cassandra，您现在必须担心保持客户端时钟同步。
【讨论】：