Cassandra最佳实践：集群前置部署HAProxy是否属于合理方案？

问题1：现有驱动能力下，Cassandra上层额外部署HAProxy是否仍属于最佳实践？ #

绝大多数场景下不属于。Datastax官方驱动内置的TokenAware+DCAwareRoundRobinPolicy已经完全覆盖了负载均衡、故障转移、就近访问的需求，额外引入HAProxy反而会增加网络链路延迟、提升架构复杂度，还额外引入了HAProxy层的故障风险。

仅在少数特定场景下适合部署HAProxy，比如：

• 客户端无法直接访问所有Cassandra节点（存在网络隔离、网段限制），需要统一入口代理
• 需要在接入层统一做访问控制、流量审计、TLS统一终结，且不想修改每一个客户端的驱动配置
• 接入的客户端不支持Cassandra原生驱动的负载均衡策略（比如部分小众语言的低级驱动、非程序类的客户端接入）

问题2：若部署HAProxy，是否会丢失TokenAware特性？ #

默认配置下会完全丢失。
TokenAware的核心逻辑是客户端驱动本地计算请求对应的令牌，直接把请求发送到持有对应数据的副本节点，避免节点间转发。而普通的HAProxy仅做四层或通用七层流量转发，无法解析CQL协议的内容计算对应令牌，只会按照配置的负载策略把请求随机转发到后端Cassandra节点，最终请求还是需要节点内部二次转发，完全失去了TokenAware减少网络跳转的优势。

除非你对HAProxy做自定义的CQL协议解析开发，否则无法保留该特性。

问题3：若部署HAProxy，联系点是否仍可向Java驱动返回正确的集群拓扑？ #

如果HAProxy是四层透明转发，将连接请求转发到任意存活的Cassandra节点，那么该节点会向驱动返回真实的集群节点IP/主机列表，这个环节不会有问题。
但要注意：Datastax Java驱动默认拿到完整集群拓扑后，会直接和所有真实节点建立连接，后续请求会绕开HAProxy直接发送到Cassandra节点，HAProxy仅会在驱动初始化建立连接时被用到一次。如果你期望所有流量都经过HAProxy，需要额外配置驱动的地址转换规则，或者修改Cassandra节点的广播地址为HAProxy地址，配置复杂度很高，很容易出现连通性故障。

内容的提问来源于stack exchange，提问作者Klun