Cassandra如何选择节点发送请求？

Question

假设 Cassandra 集群需要由客户端应用程序访问。在 Java api 中，我们创建一个集群实例并通过 Session 发送读取或写入请求。如果我们使用读/写一致性ONE，api如何选择实际节点（协调节点）以转发请求。是随机选择吗？请帮助解决这个问题。

Answer 1

Cassandra 驱动程序使用“gossip”协议（以及称为节点发现的过程）来获取有关集群的信息。如果一个节点变得不可用，客户端驱动程序会自动尝试其他节点并安排与死节点的重新连接时间。根据to the DataStax docs：

Gossip 是一种点对点通信协议，其中节点 定期交换关于他们自己和关于 他们知道的其他节点。 gossip 进程每秒运行一次，并且 与集群中最多三个其他节点交换状态消息。 节点交换关于自己和对方的信息 他们八卦的节点，因此所有节点都可以快速了解 集群中的所有其他节点。

本质上，您提供给客户端连接的节点列表是获取整个集群信息的初始接触点。这就是为什么您的客户端可以与集群中的所有节点通信（如果需要），即使您可能只在连接字符串中提供一小部分节点。

一旦您的驱动程序获得集群上的八卦信息，它就可以就在哪个节点上运行查询做出明智的决策。节点选择不是投票或随机选择的过程。根据返回的八卦信息，客户端驱动程序应用其Load Balancing Policy。虽然它确实考虑了几个因素，但基本上它会尝试选择与客户端的网络“距离”最短的节点。

编辑 20200322

让我稍微扩展一下负载平衡策略。我鼓励高性能应用程序的开发人员使用 TokenAwarePolicy。此策略将分区键值散列为“令牌”，并使用此散列来确定哪个节点负责生成的令牌范围。这具有跳过选择“协调器”节点的中间步骤的效果，并将查询直接发送到包含请求数据的节点。

但是，如果您使用的是不支持令牌的负载平衡策略，或者运行的查询未按分区键进行过滤，则适用上述原始流程。