为什么即使驱动程序不断抛出 OperationTimedOutException，Cassandra 节点也会被选为协调器？答案

【问题标题】：Why does a Cassandra node get picked as coordinator even when the driver keeps throwing OperationTimedOutException?为什么即使驱动程序不断抛出 OperationTimedOutException，Cassandra 节点也会被选为协调器？
【发布时间】：2022-07-31 18:26:39
【问题描述】：

我建立了一个带有多个协调节点的 Cassandra 集群。

有时其中一个协调器节点变得不可用...我的代码使用重试策略处理此问题，该策略移动到下一个节点并解决了问题。

但是，即使驱动程序不断抛出 OperationTimedOutException，问题节点似乎仍然会收到流量......这是一个耗时，因为该节点无用。

更多详情：卡桑德拉司机 - 我正在使用 Cassandra 驱动程序版本 3.11.0 (cassandra-driver-core-3.11.0.jar) 负载均衡策略—— 我没有设置任何负载平衡策略 - 因此，使用默认值。重试策略 - 我实施了自己的重试策略 - 如果出现读/写超时或重试不可用的原因 - 我正在使用重试，同时将一致性级别降低到 1。如果出现请求错误 - 我正在尝试不同的主机。

是否有配置，如果驱动程序在向特定协调节点发送查询时不断抛出 OperationTimedOutException，则该节点将在一段时间内不被调用？

【问题讨论】：

我有多个后续问题：（1）您使用的是哪个驱动程序，以及（2）哪个版本？另外，您配置了哪个 (3) 负载平衡策略和 (4) 重试策略？干杯！

标签： cassandra

【解决方案1】：

Cassandra 客户端连接执行 Cassandra 协调器节点缓存。因此，它将继续将查询发送到同一节点。使用客户端连接超时调整您的应用层套接字配置。

SocketOptions options = new SocketOptions();
options.setConnectTimeoutMillis(30000);
options.setReadTimeoutMillis(30000);
options.setTcpNoDelay(true);

【讨论】：

我很好奇您想通过您的建议实现什么，因为增加超时不会阻止驱动程序将请求路由到节点。干杯!

【解决方案2】：

您的问题中有一些误解，所以让我从纠正它们开始。

误解#1

<1234565>

我建立了一个带有多个协调节点的 Cassandra 集群。

Cassandra 集群中的所有节点都是相同的。这是让 Cassandra 很棒的属性之一。集群中的任何节点都可以被选为协调器。您不能将节点配置/提名/设置为协调者，而其他节点则不是。

误解#2

<1234565>

... 如果协调节点不断抛出 OperationTimedOutException ...

Cassandra 节点无法抛出 OperationTimedOutException。 OperationTimedOutException 是一个客户端异常，当它在配置的客户端超时期限内没有从协调器获得响应时，它会被驱动程序抛出。

这是与读取或写入超时异常不同的异常，后者是在服务器端读取或写入请求超时时协调器向驱动程序发送回响应时引发的。

挑选节点

您没有指定您使用的是哪个驱动程序 + 版本。 OperationTimedOutException is in Java driver v3.x 但不在 v4.x 中（它是 replaced with DriverTimeoutException，这更清楚地表明异常是客户端的）所以为了我的回复，我假设您使用的是 Java 驱动程序 v3。 11（v3 系列的最新版本）。

您也没有指定您配置了哪个load balancing policies (LBP) 以及哪个retry policies。如果您使用the latency-aware LBP LatencyAwarePolicy,，可能的情况是有问题的节点具有最低延迟，因此它被策略列为“首选节点”。

处理行为不端的节点对于驱动程序来说是一件非常困难的事情，尤其是在节点没有响应的情况下，因为如果节点根本没有响应，驱动程序将不知道真正发生了什么。驱动程序在将节点标记为“关闭”时不能过于激进，因为如果节点只是暂时不可用（例如，由于 GC 暂停），它在一段时间内不会再次被选为协调器。

有时，来自有问题节点的延迟“信号”需要一段时间才能让驱动程序有效地绕过它，因为驱动程序使用的算法在一两分钟内平均报告的延迟，按比例缩放旧延迟的权重低于新延迟。在节点无响应的情况下，驱动程序只能基于节点上次报告其延迟的时间来计算平均值/缩放。

出于这个原因，LatencyAwarePolicy 在 Java 驱动程序 v4 中被删除，而不是 the new DefaultLoadBalancingPolicy，后者对慢速副本有更好的检测算法。

您使用tryNextHost() 的解决方法有点笨拙，因为您必须有效地等待重试策略启动。您真正需要关注的是您的节点变得无响应的事实。如果您的集群过载，您应该考虑通过添加更多节点来增加容量。

从长远来看，试图为基础设施容量问题提供软件解决方案永远不会成功。干杯!

【讨论】：