Cassandra 最佳实践：在 Cassandra 前面添加 Ha Proxy 是个好主意吗？
Cassandra best practices : it is a good idea to add Ha Proxy in front of Cassandra?
据我了解，Datastax 驱动程序是 TokenAware :
Token-aware policy is used to reduce network hops whenever possible by sending requests directly to the node that owns the data.
驱动程序还有一些 DCAwareRoundRobinPolicy，以便在需要时查询其他数据中心，并重新分配负载：
This policy provides round-robin queries over the node of the local data center. It also includes in the query plans returned a configurable number of hosts in the remote data centers
问题：
似乎通过客户端驱动程序配置，已经可以实现 HighAvailability、LoadBalancing 和 TokenAware。
关于这些元素，您认为在 Cassandra 之上添加 HaProxy 仍然是一个好习惯吗？
如果第一个问题是，我可以松开 TokenAware 属性 吗？
如果第一个问题是，联络点会继续向 java 驱动程序发送正确的拓扑结构（ip/host 节点列表）吗？
谢谢
通常不建议在 Cassandra 之前使用代理 - TokenAware 负载平衡策略开箱即用（如果您使用的是准备好的语句）。除了选择正确的副本外，还会考虑节点的状态等
代理的问题是在第一次联系之后，驱动程序会收到集群中所有节点的列表，所以驱动程序无论如何都会尝试使用这些节点，而不是代理节点（直到你使用白名单代码负载均衡策略，或者您实现了地址转换功能）。
在 Cassandra 前面放置硬件或软件负载平衡器不是一个好主意。虚拟 IP 也是如此。
正如您已经指出的那样，Cassandra 驱动程序使用内置的负载平衡策略，并且了解集群拓扑，包括节点的健康状况。当您在驱动程序和集群之间放置负载均衡器或 VIP 时，驱动程序将失去智能路由请求的能力。
例如，如果您使用 Java 驱动程序，默认情况下驱动程序使用负载平衡策略将查询路由到本地数据中心，并使用令牌感知策略将请求路由到副本拥有被查询数据的（节点）。
驱动程序知道集群中的节点，因为它连接到接触点（节点 IP 地址列表）以在启动时建立控制连接。驱动程序使用控制连接来执行任务，包括查询系统表以了解集群拓扑。使用控制连接，驱动程序还自动侦听集群的变化，因此它实时了解节点添加、节点中断、新数据中心和退役等事情。
出于这些原因，不建议使用外部负载平衡器或 DNS 虚拟 IP，因为它会影响驱动程序以最佳方式运行的能力。干杯！
据我了解，Datastax 驱动程序是 TokenAware :
Token-aware policy is used to reduce network hops whenever possible by sending requests directly to the node that owns the data.
驱动程序还有一些 DCAwareRoundRobinPolicy，以便在需要时查询其他数据中心，并重新分配负载：
This policy provides round-robin queries over the node of the local data center. It also includes in the query plans returned a configurable number of hosts in the remote data centers
问题：
似乎通过客户端驱动程序配置，已经可以实现 HighAvailability、LoadBalancing 和 TokenAware。
关于这些元素，您认为在 Cassandra 之上添加
HaProxy仍然是一个好习惯吗？如果第一个问题是，我可以松开
TokenAware属性 吗？如果第一个问题是，联络点会继续向 java 驱动程序发送正确的拓扑结构（ip/host 节点列表）吗？
谢谢
通常不建议在 Cassandra 之前使用代理 - TokenAware 负载平衡策略开箱即用（如果您使用的是准备好的语句）。除了选择正确的副本外，还会考虑节点的状态等
代理的问题是在第一次联系之后，驱动程序会收到集群中所有节点的列表，所以驱动程序无论如何都会尝试使用这些节点，而不是代理节点（直到你使用白名单代码负载均衡策略，或者您实现了地址转换功能）。
在 Cassandra 前面放置硬件或软件负载平衡器不是一个好主意。虚拟 IP 也是如此。
正如您已经指出的那样，Cassandra 驱动程序使用内置的负载平衡策略，并且了解集群拓扑，包括节点的健康状况。当您在驱动程序和集群之间放置负载均衡器或 VIP 时，驱动程序将失去智能路由请求的能力。
例如，如果您使用 Java 驱动程序，默认情况下驱动程序使用负载平衡策略将查询路由到本地数据中心，并使用令牌感知策略将请求路由到副本拥有被查询数据的（节点）。
驱动程序知道集群中的节点，因为它连接到接触点（节点 IP 地址列表）以在启动时建立控制连接。驱动程序使用控制连接来执行任务，包括查询系统表以了解集群拓扑。使用控制连接，驱动程序还自动侦听集群的变化，因此它实时了解节点添加、节点中断、新数据中心和退役等事情。
出于这些原因，不建议使用外部负载平衡器或 DNS 虚拟 IP，因为它会影响驱动程序以最佳方式运行的能力。干杯！