Cassandra read_request_timeout_in_ms 为外部（客户端）请求设置

Question

根据文档和互联网上的知识。似乎下面给出的属性

- request_timeout_in_ms

- write_request_timeout_in_ms

- read_request_timeout_in_ms

仅适用于内部（服务器端）Cassandra 请求。当我将 cassandra.yaml 文件中的这些参数设置为 80000 时，我什至确信这一事实，但仍然通过以下两种方式将针对我的 Select 查询的超时错误变为更大的记录：

1) 当我尝试通过 cqlsh 连接到 Cassandra 时没有附加参数 --request-timeout=80000。通过添加此参数，我能够成功运行上次失败的 select 语句。

2) 当我尝试使用 Cassandra 驱动程序通过 java 客户端更新同一记录时，未在 Cluster.Builder 创建中设置 new SocketOptions().setReadTimeoutMillis(80000)。

问题：
有没有办法将这些 request_timeout 参数设置为 Cassandra 以用于外部（客户端）请求（所以我在通过 Cqlsh 或 javaclient 或 DataStax 的 DevCenter 连接时不必提及这些值）？

Answer 1

服务器也不能真正强制客户端超时，因为服务器外部会发生延迟。例如，Linux 内核在发送请求时引入了延迟，然后跨 DC 出现 300 毫秒的延迟峰值，您的客户端在应用发送请求后 500 毫秒收到请求。

更糟糕的是与 GC 一起使用，即 C* 发送响应，但随后有 2 秒的 STW gc 暂停。从服务器的角度来看，请求已“完成”，但客户端将有额外的 2 秒延迟。如果您的服务器配置不当，您很容易定期看到 8 秒的 GC。服务器端的超时是最好的，因为它可以处理超出其控制范围的给定不可知（或至少是禁止不可知）的因素。如果您有严格的超时，最好在客户端处理它。我建议在您的请求处理程序中执行此操作。

ListenableFuture result = Futures.withTimeout(session.executeAsync(/*statement*/),
                                              8, TimeUnit.SECONDS, executor)

setReadTimeoutMillis 有点微妙，它的每个请求但execute/executeAsync 最终可能是多个请求，因为它可能会尝试多个主机作为查询计划的一部分（重试/推测重试）。例如，对于 LOCAL_ONE 的 RF=3 请求，setReadTimeoutMillis 为 2 实际上可能需要 6 秒才能超时，具体取决于重试策略。