cassandra - Cassandra "write timeout"的性质是什么？

Question

我正在 AWS EC2 上的 24 节点 Cassandra 3.5 集群上运行一个写入繁重的程序(10 个线程的峰值为 25K/秒写入)(每个主机都是 c4.2xlarge 类型:8 vcore 和 15G ram)

每隔一段时间，我的 Java 客户端使用 DataStax 驱动程序 3.0.2 就会出现写入超时问题:

com.datastax.driver.core.exceptions.WriteTimeoutException: Cassandra timeout during write query at consistency TWO (2 replica were required but only 1 acknowledged the write)
    at com.datastax.driver.core.exceptions.WriteTimeoutException.copy(WriteTimeoutException.java:73)
    at com.datastax.driver.core.exceptions.WriteTimeoutException.copy(WriteTimeoutException.java:26)
    at com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
    at com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:245)
    at com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:64)

该错误很少发生并且以非常不可预测的方式发生。到目前为止，我无法将故障与任何特定的东西联系起来(例如程序运行时间、磁盘上的数据大小、一天中的时间、系统负载指标，如 CPU、内存、网络指标) 尽管如此，它确实扰乱了我们的操作。

我试图找到问题的根本原因。在网上寻找选项，我对那里的所有线索感到有些不知所措，例如

更改“cassandra.yaml”中的“write_request_timeout_in_ms”(已更改为5秒)

使用适当的“RetryPolicy”来保持 session 继续进行(已经在一个 session 级别一致性级别上使用 DowngradingConsistencyRetryPolicy)

更改缓存大小、堆大小等 - 从未尝试过那些 b/c 有充分的理由将它们视为根本原因。

在我的研究过程中，有一件事情真的很令人困惑，我从一个完全复制的集群中得到这个错误，只有很少的 ClientRequest.timeout.write 事件:

我有一个完全复制的 24 节点集群，跨越 5 个 aws 区域。每个区域至少有 2 个数据副本

我的程序在 session 级别运行一致性级别 1(带有 QueryOption 的集群构建器)

发生错误时，我们的 Graphite 图表记录的主机故障不超过三 (3) 个，即具有 Cassandra.ClientRequest.Write.Timeouts.Count 值

我已经将 write_timeout 设置为 5 秒。网络相当快(使用iperf3验证)且稳定

从理论上讲，这种情况应该在 Cassandra 的故障安全范围内。但是为什么我的程序还是失败了？数字不是看起来的那样吗？

Answer 1

看到超时或错误并不总是一件坏事，尤其是如果您以更高的一致性级别进行写入，则写入可能仍会通过。

我看到你提到CL=ONE你仍然可以在这里超时，但写(突变)仍然通过。我发现这个博客真的很有用:https://www.datastax.com/dev/blog/cassandra-error-handling-done-right .在错误发生时检查您的服务器端(节点)日志，看看您是否有诸如 ERROR/WARN/GC 暂停之类的事情(如上面提到的评论之一)，这些类型的事件可能导致节点无响应，因此超时或其他类型的错误。

如果您的更新是幂等的(理想情况下)，那么您可以构建一些重试机制。