Cassandra读取一致性一，受其他节点影响？

Question

我正在使用 NetworkTopologyStrategy 和 PropertyFileSnitch 在 4 个 DC 上测试 Cassandra 2.0 的部署。 Replication quota 为每个 DC 1，意味着每个 DC 都有完整的数据库。我的 key 空间配置为一致性“一次”读取。这意味着(据我所知)客户端可以在本地获取数据(如果可用)而无需执行任何仲裁等。

不幸的是，我的测试结果表明并非如此。如果我人为地(使用 MiniNet)增加其中一个 DC 的延迟，我可以看到我在其他 DC 上的读取速度明显变慢(与延迟成比例，超过 dynamic_snitch_badness_threshold)。

在这个测试中我没有写入任何数据，我只是在执行读取。请注意，如果我完全断开其中一个节点的连接，我的性能就会恢复到 100%。

因此我有 2 个问题，1. 为什么当我执行一致性读取时，一个 DC 会降低整个系统的性能。以及 2. 为什么 Dynamic snytch 不会将通信从性能不佳的节点重新路由(默认设置，测试超过 20 分钟)。

问候。

编辑:所以这是我到目前为止的一系列行动。当我创建表时，我添加了这个:with read_repair_chance = 0 and speculative_retry= 'NONE';

问题:当我使用 cqlsh 控制台时，我可以读取当前的一致性级别，并且可以根据文档设置 LOCAL_ONE。但是新的设置不是持久化的，当我退出cqlsh并再次进入时，我又可以看到默认的一致性ONE。好像设置是per session？

我在慢速节点上运行 nodetool netstat，我发现没有修复尝试但有一些响应？？

Mode: NORMAL
Not sending any streams.
Read Repair Statistics:
Attempted: 0<<-----------
Mismatch (Blocking): 0
Mismatch (Background): 0
Pool Name                    Active   Pending      Completed
Commands                        n/a         0              0
Responses                       n/a         0           3807<<------------

Answer 1

1) 根据您的读取负载，即使您使用 LOCAL_ONE 或 LOCAL_QUORUM，您也可能因读取修复而在其他数据中心的节点上造成一些负载。尝试观察 nodetool tpstats 的输出，看看节点是否正在进行大量读取修复。如果是这样，请尝试通过将其设置为零来关闭 CF 的 read_repair_chance。

要观察上述行为，请启用 DEBUG 日志记录并查找如下行:

ReadCallback.java(第 79 行)Blockfor 是....

它应该告诉您请求是否通过向其他 DC 中的节点发送请求而被阻止，可能是由于 read_repair。

2) Dynamic snitch 有一个重置间隔。这意味着无论过去的历史如何，它都会重置它为每个节点的延迟捕获的分数。在告密者重置后，您可能会观察到查询路由到慢速节点。