我在AWS EC2上的24节点Cassandra 3.5集群(每台主机为c4.2xlarge类型:8 vcore和15G ram)上运行一个写量很大的程序(10个线程的峰值为25K/sec)
每隔一段时间，我的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，内存，网络指标)，尽管如此，它确实扰乱了我们的操作。
我正试图找到问题的根本原因。在网上寻找选择时，我被所有的线索弄得不知所措，比如
- 更改"write_request_timeout_in_ms"在"cassandra. exe"。(已更改为5秒)
- 使用适当的"RetryPolicy"来保持会话继续(已经在一个会话级别一致性级别上使用了DowngradingConsistencyRetryPolicy)
- 改变缓存大小，堆大小等-从未尝试过这些b/c有很好的理由认为它们是根本原因。
在我的研究中，有一件事非常令人困惑，那就是我从一个完全复制的集群中得到这个错误，很少有ClientRequest.timeout.write事件:
- 我有一个完全复制的24节点集群，横跨5个aws区域。每个区域至少有2份数据副本
- 我的程序在会话级别运行一致性级别1(带有QueryOption的集群构建器)
- 当错误发生时，我们的石墨图记录了不超过三(3)个主机打嗝，即具有cassandra . clientrequest . write . timeout . count值 我已经将write_timeout设置为5秒。网络非常快(使用iperf3验证)并且稳定
理论上，情况应该在Cassandra的故障安全范围内。但是为什么我的程序还是失败了?这些数字不像表面上看起来的那样吗?
看到超时或错误并不总是一件坏事，特别是当您在更高的一致性级别上写时，写仍然可以通过。
我看到你提到CL=ONE，你仍然可以在这里得到超时，但写(突变)仍然通过。我发现这个博客真的很有用:https://www.datastax.com/dev/blog/cassandra-error-handling-done-right。在错误发生时检查服务器端(节点)日志，看看是否有error/WARN/GC暂停(如上面提到的注释之一)之类的事情，这些事件可能导致节点无响应，从而导致超时或其他类型的错误。
如果你的更新是幂等的(理想情况下)，那么你可以建立一些重试机制。