Cassandra"写暂停"的本质是什么？

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"来保持会话进行(已经在ONE会话级别的一致性级别上使用DowngradingConsistencyRetryPolicy)
• 更改缓存大小,堆大小等 - 从未尝试过这些b/c有充分的理由将它们作为根本原因进行折扣.

在我的研究过程中,有一件事令我感到困惑的是,我从一个完全复制的集群中收到此错误,其中包含很少的ClientRequest.timeout.write事件:

• 我有一个完全复制的24节点集群跨越5个aws区域.每个区域至少有2个数据副本
• 我的程序在会话级别运行一致性级别ONE(带有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。在发生错误时检查服务器端（节点）日志，看看是否有错误/警告/GC 暂停（如上面提到的评论之一）之类的事件，这些事件可能会导致节点无响应，因此超时或其他类型的错误。

如果您的更新是幂等的（理想情况下），那么您可以构建某种重试机制。