作者： djshow832-PingCAP
大家好，我是 TiProxy 团队的研发，非常开心看到大家喜欢 TiProxy。我们读了每一条对 TiProxy 的评价，决定在这里解答大家的疑问。
TiProxy 刚 GA，有人用吗？稳定吗？
- TiProxy 从 2023.1 开始上线 TiDB Serverless，你在 TiDB Serverless 上运行的每一条 SQL，都经过了 TiProxy 的处理；TiDB Serverless 的每一次 TiDB Pod 调度、扩缩容、升级，都用了 TiProxy 的连接迁移。参考博客 Maintaining Database Connectivity in Serverless Infrastructure with TiProxy.
- TiProxy 在 2023.4 开始上线 TiDB Dedicated，经历了商业客户在生产环境的考验，连接保持和负载均衡都有很多成功案例。
- TiProxy 的初衷是适应云上 TiDB 的弹性伸缩、快速迭代，但后来我们看到了云下用户有同样的诉求，才开始集成生态工具，而 TiProxy 的基本功能与云上相同。
TiProxy 在 TiDB DMR 版本里声明 GA，那能用于生产环境吗？
- TiProxy 是独立发布的，TiProxy v1.0.0 是 GA 版本，可用于生产环境。
- TiProxy 不一定要与 TiDB v8.0.0 配合使用，可以与 TiDB v6.5.0 及以上的任意 LTS 版本配合使用。
TiProxy 能替换 HAProxy 吗？
- 需要权衡功能与性能，如果你认为 TiProxy 的功能更重要，那就替换 HAProxy。一个参考：TiDB Cloud 上 TiProxy 不能替换 NLB，相当于在链路上额外增加一个组件，会增加延迟、实例成本、跨可用区流量成本，但也有客户愿意使用。相比而言，替换 HAProxy 的代价低很多，所以我们相信肯定有场景。
- 如果你用 VIP 的方式实现 TiProxy 的高可用，仍然需要手动部署 keepalived，TiUP 没有集成 keepalived。
为什么 TiProxy 的性能低于 HAProxy？
- HAProxy 是 L4 层代理，不用解析 MySQL 包；TiProxy 是 L7 层代理，连接迁移需要解析 MySQL 包。L4 层代理已经有很多产品，而 L7 层代理可以做更多事。
- TiProxy 的网络架构还是简单的 goroutine-per-connection 模型，goroutine 的切换有较多开销。
TiProxy 未来有什么规划？
TiProxy 的想象空间巨大，下面是我们当前的规划（规划随时可能调整，以下时间只是预估，不是承诺）：
- 高可用 & 业务连续性
- （半年内）更全面的 TiDB 健康检查，例如当 TiDB 连不上 PD 或 TiKV 时，也能迁移走连接，快速恢复业务
- （半年内）当 TiDB 有 OOM 风险时，迅速迁移走连接，降低对业务的影响；大 SQL 通常执行到 OOM，迁移不走
- （远期）当 TiDB 意外下线（而非规划内的运维操作）时，也能保持连接
- （远期）TiUP 集成 keepalived，在小规模集群上轻松实现 TiProxy 的高可用
- （远期）TiProxy 的功能插件化，可随时在线扩展或更新功能
- 性能 & 成本
- （半年内）TiProxy 路由到本地 TiDB，主要用于降低云上的跨可用区流量费，也可用于跨机房部署、TiProxy 与 TiDB 混合部署时降低网络延迟
- （半年内）基于 TiDB CPU 使用率（而非连接数）的负载均衡，当不同连接上的工作负载差异较大时也能充分利用 TiDB 资源
- （远期）优化网络模型，提升吞吐量
- 稳定性
- （一年内）配置各租户的 TiDB 实例配额，实现计算层实例级别的资源隔离，与存储层的资源隔离（Resource Control 或 Placement Rules）组成一套完整的多租户方案
- （远期）记录流量，把流量回放到新 TiDB 集群，验证新 TiDB 版本的兼容性，升级无忧
- （远期）在 TiDB 高负载时限流，避免打挂 TiDB 或造成服务级别下降
- 安全性
- （一年内）支持基于证书的认证，与 TiDB 兼容
如果你有什么建议或脑洞，也欢迎留言或在 https://github.com/pingcap/tiproxy 提 issue！
最后，请保持耐心，保持期待！
