java - 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但通过以下两种方式仍然对我的选择查询更大的记录出现超时错误:

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

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

问题:
有没有办法为外部(客户端)请求将这些 request_timeout 参数设置为 Cassandra (这样我在通过 Cqlsh 或 javaclient 或 DevCenter by DataStax 连接时不必提及这些值)？

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 秒才会超时，具体取决于重试策略。