【 TiDB 使用环境】生产
【 TiDB 版本】 6.5.0
【复现路径】无
【遇到的问题：
经过一段时间的3节点TiDB集群的测试之后，为了不改动原来基于MySQL的客户端代码，按照Haproxy+keepalive 方式的TiDB高可用实践，也测试文章中的Haproxy+keepalive+TiDB的高可用方案。
想确认一下，将Haproxy+keepalive+TiDB应用到生产环境，是TiDB的最佳高可用方案吗？
在生产环境中，如果使用这个方案，需要特别注意什么吗？
谢谢！
资源有限的情况下，这属于最佳，如果资源充足，线上最好使用F5类型的硬件或者云厂商的alb，slb这些实力。根据自己的业务重要性而选择不同故障冗余方案。
巧了，我们就是用的这种模式，目前还没发现什么问题。
谢谢！
可否分享一下，你们的生产环境中，用了多少个节点来部署这三个系统？
我这都是 3节点的。 tidb还没有使用任何负载均衡。 长期空闲，准备使用SLB做负载均衡
我们都是用的标准部署，每个组件3个节点
好像跑偏了，我的目的是达到高可用，因为mysql客户端，不做修改，只能连接到TiDB的某个节点，如果这个节点出了故障，应用就瘫痪了，使用Haproxy + keepalive，可以让我只连接到它的虚拟ip，故障切换由他们帮我解决，当然也达到了负载均衡的目的。
那Haproxy和keepalive部署在独立于TiDB集群的三台服务器上吗？
Haproxy和keepalive部署在独立于TiDB集群的服务器上，主备两个几点即可
可以设置每个组件3个节点，Prometheus监控单独一台设备
不是，我们资源比较紧张，是和节点在一起的。
有钱就f5，slb，没钱就 haproxy + keepalive 主备两个节点足够了
应用程序一侧 本地全都部署一个 ProxySQL （很轻量的）
应用程序通过本地的 ProxySQL 访问 tidb-server, 例如 127.0.0.1 或者 socket，优点是网络路径比较短
ProxySQL的实例有点多，但是可以用配置管理工具(例如ansible) 去管理这些ProxySQL的配置
HAProxy 和 Keepalived 相关的实践，还可以参考这篇 
博客
我们单独要了两台机子搞得Haproxy+keepalive
有利有弊，用keepalive来负载haproxy，也同时会增加运维的负担，也需要网络去统一管理rpc端口，如果VIP不切换，也会对业务产生影响
可以考虑直接用haproxy，去掉keepalive
我就是单个haproxy，这样 tidb server 内存过高reload ，前端还能重连
单个haproxy那haproxy本身就变成单点了吧，我们也是Haproxy+keepalive
建议四层吧，直接用lb或者使用lvs来做连接层的负载均衡和高可用，目前看起来很好用，很稳定，haproxy方案处于性用层会带来更大的网络消耗