为什么即使满足一致性级别，cassandra 写入也会失败？答案

【问题标题】：Why cassandra write fails even when consistency level is met?为什么即使满足一致性级别，cassandra 写入也会失败？
【发布时间】：2019-02-16 16:13:46
【问题描述】：

我有以下配置的 cassandra 集群设置：-

节点：- 3
数据中心：- dc1
复制因子：-3
一致性：- LOCAL_QUORUM

我创建了一个示例 spring boot api，它递归地插入到 keyspace(test) 中的 table(testing1) 中。

在执行写入操作之前，我使用 tc 命令在其中一个节点中引入了延迟（2100ms）作为响应，因此当执行写入操作时，我们会得到 writetimeoutexception，因为在 cassandra.yaml 中 write_request_timeout 设置为 2000ms。 Cassandra 仍应成功执行写入操作，因为需要确认满足一致性级别 (2) 的节点正在正常工作，但我收到以下异常：-

com.datastax.driver.core.exceptions.WriteTimeoutException：在一致性 LOCAL_QUORUM 写入查询期间 Cassandra 超时（需要 2 个副本，但只有 1 个确认写入）。

为什么即使需要 ack(2) 的节点已启动并运行，写入也会失败？

【问题讨论】：

标签： spring-boot cassandra datastax spring-data-cassandra

【解决方案1】：

写入必须在超时内完成才能不出现超时异常。不管节点是否启动。

Cassandra 仍应成功执行写入操作，因为需要节点确认满足一致性级别 (2)

不，它不应该也不会。如果超时已超过节点可能会丢弃突变并依靠提示、读取修复和反熵修复来解决它。突变的状态是未知的，并作为错误返回，因此可以重试或至少不假定在仲裁中应用它，以免破坏一致性合同。

【讨论】：

只有 1 个节点引入了延迟，其他 2 个节点及时响应。那么为什么它只得到一个节点的确认呢？
要么 1 个延迟的节点是协调器，要么是读取修复，要么是告密者最初为 DATA 请求选择了该主机，并且未设置推测重试以按照您想要的方式处理它。
如果您不想让这成为问题，请在您的驱动程序上配置client side speculative retry。此外，我建议表服务器端投机重试为 100ms 或在 4.0 之前保持不变，此时您可以进行混合重试。
我怀疑推测重试会有所帮助吗？因为如果之前有其他节点可以响应，推测重试将很有用。但是总共有 3 个节点，1 个节点被故意标记为响应延迟。所以只有其他剩余的2个节点必须及时响应才能满足一致性。
协调节点是否必须启动并运行？因为我只有在选择协调器作为延迟节点时才会收到此错误，否则写入会成功。