Cassandra - Cassandra timeout during write query at consistency LOCAL_ONE (1 replica were required b

com.datastax.driver.core.exceptions.WriteTimeoutException: Cassandra timeout during write query at consistency LOCAL_ONE (1 replica were required but only 0 acknowledged the write)

我们经常谈论Cassandra如何从头开始设计容错和可用性。今天我想讨论它在实践中是如何实际运行的，特别是Cassandra可以告诉客户机器何时停机时的请求状态。

首先，让我们从描述非分布式服务器的非常基本的图表开始：

客户提出请求并获得响应。简单！

但是，当服务器在回复之前发生故障时会发生什么？

客户不知道发生了什么。如果它正在尝试执行更新，则必须在服务器恢复时重试该请求。

我们将在这里介绍的其他所有内容只是对分布式系统的扩展。

首先，让我们看看一切按计划进行时的工作原理：

客户端可以与Cassandra集群中的任何节点通信，无论它是否是正在读取或更新的数据的副本。客户端与之通信的节点“协调器”负责将请求路由到适当的副本。

如果协调员在请求中途失败，我们处于与非分布式案例相似的情况：客户端处于黑暗状态，除了重试之外别无选择。唯一的区别是客户端可以立即重新连接到群集中的任何节点。

有趣的情况是副本失败但协调器没有。这里实际上有两个不同的场景。在第一个中，协调器的故障检测器在请求到达之前知道副本已关闭：

由于协调器知道副本已关闭，因此它甚至不会尝试将请求路由到它。相反，它immeditely响应与客户端用UnavailableException。这是Cassandra唯一一次失败。（即便如此，您也可以请求Cassandra允许使用ConsistencyLevel.ANY进行写入。）

让我再说一遍，因为这是我看到的最大的混乱点：Cassandra唯一一次写入失败的时候，当协调员收到请求时，很少有副本存活。

因此，如果副本不失败，直到发生了什么之后的协调员转发客户端的请求？

在这种情况下，协调器回复TimedOutException。 从Cassandra 1.2开始，它还将包含已确认的多少副本成功的计数。同样在1.2中，Cassandra 为读取，写入和其他操作（如truncate）提供了不同的超时。

在单服务器故障情况下，协调器处于客户端所处的相同情况：它不知道请求是成功还是失败，因此它可以告诉客户端请求超时。

请记住，对于写入，超时不是失败。（为了更清楚，我们考虑将 Cassandra 1.2的TimedOutException 重命名为InProgressException，但决定不遵守它以保持向后兼容性。）我们怎么能说因为我们不知道副本失败之前发生了什么？协调器可以强制结果进入更新前或更新后状态。这就是Cassandra用暗示切换做的事情：

我在上图中标注了“超时响应”步骤5。记录提示是缺少的步骤4：协调器在本地存储更新，并在恢复时将其重新发送到失败的副本，从而迫使它进入客户端最初想要的更新后状态。

文章转自：https://www.datastax.com/dev/blog/how-cassandra-deals-with-replica-failure