如何解决cassandra中的写入超时异常？

Question

我正在尝试将 50000 条记录插入到一​​个五节点的 cassandra 集群中。我正在使用executeAsync以提高性能（减少从应用程序端的插入时间）。我尝试了多个批量大小的 Batchstatement，但每次我都遇到以下异常。

Exception in thread "main" com.datastax.driver.core.exceptions.WriteTimeoutException: Cassandra timeout during write query at consistency ONE (1 replica were required but only 0 acknowledged the write)
at com.datastax.driver.core.exceptions.WriteTimeoutException.copy(WriteTimeoutException.java:54)
at com.datastax.driver.core.DefaultResultSetFuture.extractCauseFromExecutionException(DefaultResultSetFuture.java:259)
at com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:175)
at 

我插入了数据，即 10000,20000 到 40000 条记录，没有任何问题。下面是我写的java代码。

for (batchNumber = 1; batchNumber <= batches; batchNumber++) {
    BatchStatement batch = new BatchStatement();
    for (record = 1; record <= batchSize; record++) {
        batch.add(ps.bind(query));
    }
    futures.add(session.executeAsync(batch));           
}
for (ResultSetFuture future : futures) {
    resultSet = future.getUninterruptibly();
}

其中 ps 是准备好的语句，batches 是批次数，batchSize 是批次中的记录数。

我无法理解问题的根本原因。我以为某些节点已关闭，当我检查所有节点时都正常运行。

我应该如何调试异常？

Answer 1

我看到几个错误：

1. 您似乎正在尝试弄清楚可以一起批处理的最大查询数是多少。
2. 您似乎认为批处理多个语句会给您带来某种性能提升。
3. 您错误地在循环中重用了相同的准备好的语句。
4. 您没有以某种摄取率限制您的应用程序。
5. 您没有执行任何异常处理，例如在某些批处理失败时重试。

让我们重新开始。

1. 批处理中的最大语句数应小于 10。越少越好。顺便说一下，批处理的总大小必须小于 YAML 配置文件中的任何值。通常，如果您的批次大于 5kb，那么您的日志中会出现警告。如果您的批次大于 50kb，则批次将失败。您可以调整这些值，但您应该记住，a 会BATCH重载协调器节点。批处理越大（就 kb 或语句数而言），协调器的过载就越大。
2. 将不相关的语句组合在一起不会有任何好处。相反，您实际上会失去性能。这是由于BATCH工作方式造成的。选择一个节点来协调所有的语句，该节点将负责所有的语句。通常协调器是根据第一条语句选择的，如果你的语句碰到多个节点，你的协调器也需要协调属于不同节点的东西。相反，如果您触发多个单独的异步查询，则每个节点将只负责它们的语句。您将在所有集群节点上分散过载，而不是在一个节点上进行锤击。
3. 您以错误的方式使用准备好的语句。你应该添加一个new BoundStatement(ps).bind(xxxx)声明。无论如何，这很容易解决。
4. 如果您要运行大量查询，那么您将一直运行它们。您将耗尽应用程序内存，因为它会不断向future列表中添加s，并且最终会因为 OOM 错误而被杀死。此外，您并没有让您的集群有可能实际摄取您正在向其发送的所有数据，因为您可以比集群摄取数据的速度快得多。您需要做的是限制列表中的期货数量。最多将其保持为某个值（例如，例如 1000）。要执行此类任务，您需要使用inside移动最终循环.getUninterruptibly 循环。这样，您可以降低摄取率，并且会看到超时异常计数减少。并且取决于应用程序，减少的超时异常意味着更少的重试，因此更少的查询，更少的开销，更好的响应时间等......
5. .getUninterruptibly在Future's 列表中有一个循环很好，但是你应该记住，当你的集群过载时，你会超时。在这一点上，您应该捕获异常并处理它，无论是重试，还是重新抛出，无论是其他什么。我建议您围绕幂等查询设计模型，这样我就可以重试失败的查询，直到它们成功为止，而不必担心重试后果（这也可能发生在驱动程序级别！）。

希望有帮助。