想象一下 Cassandra 集群需要由客户端应用程序访问。在Java api中，我们创建一个集群实例并通过会话发送读取或写入请求。如果我们使用读/写一致性 ONE，API 如何选择实际节点（协调节点）来转发请求。是随机选择的吗？请帮忙解决这个问题。
Cassandra 驱动程序使用“gossip”协议（以及称为节点发现的过程）来获取有关集群的信息。如果某个节点不可用，客户端驱动程序会自动尝试其他节点并安排与失效节点的重新连接时间。根据到 DataStax 文档:
Gossip 是一种点对点通信协议，其中节点
定期交换有关自己和有关的状态信息
他们知道的其他节点。八卦进程每秒运行一次并且
与集群中最多三个其他节点交换状态消息。
节点交换有关自身和其他节点的信息
他们已经闲聊过的节点，因此所有节点都可以快速了解
集群中的所有其他节点。
本质上，您提供给客户端连接的节点列表是获取整个集群信息的初始接触点。这就是为什么您的客户端可以与集群中的所有节点进行通信（如果需要），即使您可能只在连接字符串中提供一小部分节点。
一旦您的驱动程序获得了集群上的八卦信息，它就可以明智地决定在哪个节点上运行查询。节点选择不是投票或随机选择的过程。根据返回的八卦信息，客户端驱动程序应用其负载均衡策略。虽然它确实考虑了几个因素，但基本上它会尝试选择距客户端网络“距离”最近的节点。
编辑20200322
让我扩展一下有关负载平衡策略的观点。我鼓励高性能应用程序的开发人员使用TokenAware策略。此策略将分区键值哈希为“令牌”，并使用此哈希来确定哪个节点负责生成的令牌范围。这具有跳过选择“协调器”节点的中间步骤并发送查询的效果directly到包含所请求数据的节点。
但是，如果您使用非令牌感知负载平衡策略，或运行不按分区键进行筛选的查询，则适用上述原始过程。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
