Cassandra 动态告密者和dynamic_snitch_reset_interval_in_ms 参数

Question

我正在研究 Cassandra 动态告密者。假设特定密钥空间有 3 个副本节点（N1、N2 和 N3）。假设目前告密者只考虑分数计算的延迟。 让我们举一个特定的例子，

N1 = 1ms，

N2=2ms，

N3=3ms（由于某些网络错误）。

对于一个会话，如果读一致性 = 2，协调器将选择 N1 进行全数据请求，选择 N2 进行摘要请求。

1. 协调器会完全忽略此会话的 N3 或在后台（异步）对其执行摘要请求和读取修复吗？

我首先也无法理解 dynamic_snitch_reset_interval_in_ms 的需要。由于必须在每个dynamic_snitch_update_interval_in_ms间隔收集每个节点的延迟并计算分数。如果网络错误得到解决并且节点 N3 的延迟减少到 0.5 毫秒，则告密者会更改首选节点本身。是否只是为了满足 10% 的延迟改进（因为如果当前节点的性能比最高性能节点低 10%，则动态告密会更改首选节点）？

2. 为什么需要dynamic_snitch_reset_interval_in_ms？

我假设即使协调器忽略当前会话的 N3（我不确定），也会计算每个节点的分数，因为另一个会话的 RC 可能为 3，在这种情况下协调器也必须考虑节点 N3。

我错过了什么吗？这真的让我很困惑。

参考：https://www.datastax.com/blog/dynamic-snitching-cassandra-past-present-and-future#:~:text=First%20off%2C%20if%20we%20don%27t%20read %20来自%20a%20主机%20因为%20我们%20确定%20it%27s%20没有%20更长%20执行%20足够%2C%20%20可以%20我们%20知道%20那%20it%20已经%20恢复了%3F

Answer 1

对上述内容不太确定，但这些天我几乎总是利用

GossipingPropertyFileSnitch

而不是任何其他选择。

GossipingPropertyFileSnitch

代表了 Cassandra 处理网络拓扑方式的重大进步，提供了动态、高效且容错的数据放置和请求路由。它与 gossip 协议的集成以及对动态更新的支持（无需集群重新启动）使其成为生产 Cassandra 部署的首选，尤其是跨多个数据中心的部署。

要记住的要点：

• 按照设计，

  GossipingPropertyFileSnitch

  依赖于

  PropertyFileSnitch

  的 apache

  cassandra-topology.properties

  ，作为允许集群迁移到

  GossipingPropertyFileSnitch

  的一种方式。
• 如果集群已经在

  GossipingPropertyFileSnitch

  上，即使节点没有问题，也请确保 apache

  cassandra-topology.properties

  已被删除或不存在，以确保集群将来不会遇到问题。更多信息请参见CASSANDRA-11508
• 仅供参考，CASSANDRA-10745 是一项在未来版本中弃用并完全删除 PropertyFileSnitch 的提案。