1. 为什么业务规模一上来第一个想到的就是加一层代理先说一个我亲身踩过的场景。某业务早期只有一个数据库实例应用直连简单粗暴。等用户量上来单实例扛不住于是扩成了主从集群——一主两从主库写从库读。听起来很常规对吧但麻烦就从这里开始了。首先应用程序的连接串怎么办以前是一台数据库的地址现在是一主两从三个地址。有的团队把所有地址写进配置应用自己做读写分离有的团队用负载均衡器挡在数据库前面。但这两种方案都有问题应用自己做读写分离等于把数据库的拓扑细节泄漏给了业务层哪天加了一个从库或者切换了主库所有应用都要改配置重发用普通负载均衡又太“笨”它分不清你这条 SQL 是 SELECT 还是 UPDATE也没法保证同一个事务里的所有语句都发到同一个后端节点。更痛苦的是主从切换主库宕机了从库要提升为新主应用层要么改配置、要么等 DNS 刷新、要么依赖运维手工操作中间的业务中断时间非常不可控。有一次我们做容灾演练切换主库用了大概三分钟那三分钟应用全部报连接失败领导在旁边盯着场面极度尴尬。最后我们引入了一层数据库代理所有应用一律连代理代理再转发到后端的真实数据库节点。应用侧完全不需要知道后端拓扑变成了什么样主从切换、加从库、缩容全部在代理层消化掉。那之后我再回头看分布式数据库代理根本不是为了“分布”而分布的漂亮概念它解决的是直连模式下几乎所有让人睡不好觉的工程问题连接管理、流量调度、故障转移、可观测性。这篇文章我打算从为什么、是什么、怎么选、怎么部署、怎么避坑五个角度把数据库代理这件事讲透。不管你是业务开发、DBA 还是基础架构团队的成员只要系统里有超过一台数据库节点这篇文章应该能帮你少走很多弯路。2. 数据库代理到底在链路里充当什么角色很多人对数据库代理的第一印象是“不就是个反向代理吗”。这个理解方向不错但数据库代理比普通反向代理在应用层做得更深。2.1 代理的本质一个懂 SQL 的流量调度器普通反代比如 Nginx 做 TCP 四层转发拿到的是一个字节流它不关心字节流里的具体内容只管把连接原封不动地转给后端。数据库代理不一样它工作在 MySQL/PostgreSQL 这类数据库的协议层能够解析客户端发过来的 SQL 语句理解这条语句是要读还是要写、要访问哪张表、走哪个分片然后才决定转发给哪个后端节点。这个“能读懂 SQL”的能力是一切高级功能的基础。比如读写分离策略本质上就是一条规则SELECT走从库INSERT/UPDATE/DELETE走主库。代理拿到语句后做一次轻量级词法分析判断语句类型再根据后端节点的健康状态和负载情况决定路由目标。你可以把代理想象成一个快递分拣中心快递到了先扫码解析 SQL判断是普通件还是生鲜件读写类型然后决定送到哪条运输线后端节点。没有分拣中心每一辆快递车都要自己跑遍所有目的地效率低且容易乱。2.2 核心功能一连接池与连接复用应用侧直连数据库时每个应用实例都会维护一批数据库连接。假设你有 50 个应用实例每个实例默认保持 30 个连接一共就是 1500 个连接。数据库服务端对连接数有上限比如默认 max_connections151 或者调大后 3000一旦应用扩缩容、发版重启连接数剧烈波动很容易把数据库的连接数打满。接入代理后应用只连代理比如每实例只维持 20 个连接代理再和后端数据库维持一个比较稳定的连接池。因为代理连接的客户端少了连接总量大幅下降数据库端的最大连接数压力也就缓解了。更重要的是代理可以把短连接场景下的连接建立开销消化掉。有些老业务代码写得糙每次执行一条 SQL 都新建连接用完就关这在直连模式下对数据库的 accept 压力极大。代理介入后应用和代理之间的连接可以被代理复用后端连接也被池化整体建连成本大幅降低。2.3 核心功能二读写分离与事务路由这是代理最直观的收益。读写分离路由需要保证一个前提同一个事务里的所有语句必须路由到同一个后端节点。否则一个事务先写主库再读从库从库数据还没同步过来就会读到脏数据比如刚插入的主键在从库查不到。所以代理内部必须维护“会话状态”一旦某个客户端连接开启事务后续语句全部强制路由到写节点直到事务提交或回滚。这个逻辑说起来简单实际实现里有个大坑autocommit0的隐式事务模式。客户端明明没有显式BEGIN但把自动提交关掉了后续的一批 SQL 实际上构成了一个事务。如果代理只识别BEGIN关键字就会误判。成熟的代理实现会同时关注autocommit参数的变化和执行状态这是判断一个代理产品是否“靠谱”很重要的细节。此外还有SELECT ... FOR UPDATE这类语句虽然它是查询但它带了行锁或表锁必须走主节点否则锁的意义就没了。判断 SQL 类型不能只看第一个关键字还要看有没有FOR UPDATE、LOCK IN SHARE MODE等后缀。这些都是工程层面的经验网上很多简单教程不会告诉你。2.4 核心功能三故障转移与高可用直连模式下的主从切换靠 DNS 等待应用重连的时间通常以分钟计。代理模式下代理会持续做后端节点的健康检查一旦发现主节点不可用会按照预设的规则比如选一个数据最新的从库提升新主然后把这个新主地址暴露给客户端连接。对应用来说它始终连的是代理的地址代理这边不停切换应用完全无感。顶多是切换瞬间在途的事务失败需要应用重试。如果业务层已经做了重试机制整个切换过程对用户而言可能是“零感知”的。不过要注意代理的高可用并不等于后端数据库的高可用代理自身也需要多实例部署 负载均衡 故障探活否则代理变成新的单点那才是啼笑皆非。2.5 核心功能四限流、熔断与安全管理数据库代理卡在应用和后端之间天然适合做安全管控。可以在这里做账号体系后端数据库账号统一由代理管理业务账号绑定路由规则避免直接把数据库账号暴露给应用。白名单/黑名单某些高风险的 SQL比如不带WHERE的DELETE在代理层直接拦掉。限流熔断当后端某个节点响应变慢代理可以自动摘除该节点的读写权重把流量切换到其他健康节点。这种保护能力在直连模式下要靠应用层自己实现多数团队根本没有这个精力。我个人见过不少数据库被慢查询打挂的事故有些慢查询其实就是某条刚上线的统计 SQL 漏了索引。如果用代理做了一层“超时熔断”即使 SQL 没走索引也会被提前掐断不至于把整个库拖垮。3. 几类主流的代理落地路线怎么选才不踩雷聊完了代理的角色接下来是很多人关心的落地问题——市面上有开源方案有商业方案也有人选择自研到底怎么挑3.1 两条技术路线协议级代理 vs SDK 中间件先看两条大的技术路线。协议级代理单独部署一套代理服务工作在数据库协议层对应用完全透明。应用不需要改代码只需要改数据库连接地址。典型代表就是 ProxySQL、MaxScale、Vitess 的路由组件这类产品。SDK 中间件以一段驱动包/库的形式嵌入业务代码应用在代码层调用路由逻辑。典型如 ShardingSphere-JDBC 这种模式。应用需要依赖特定语言的 SDK改造量相对大但部署架构简单不需要额外维护代理集群。这两条路线各有拥趸我的观点很明确如果历史包袱重、应用代码量大、多语言并存优先协议级代理。因为你不希望每个语言的团队都去配一遍 SDK、调一遍参数协议级代理是让所有人只改一个地址简单粗暴但有效。如果是全新项目、技术栈统一并且对性能极敏感可以双轨并行甚至直接用 SDK 方式。3.2 不同方案的定位差异不是选最火的是选最匹配的就好比干活有人用螺丝刀起钉子虽然费劲但也能起出来可换了专业撬棍体验就完全不一样。数据库代理也一样不同产品解决的核心问题各有侧重。我整理了一张选型时要重点对比的维度表建议你拿着这张表去对照具体产品维度考察重点常见误区协议兼容度对预处理语句、存储过程、多语句批量执行的支持程度只测普通查询上线才发现存储过程全走主库读写分离能力事务绑定、FOR UPDATE识别、延迟阈值控制以为是读负载均衡结果事务全打到一个节点分片能力是否支持水平分库、分片键路由方式高估代理分片能力实际只适合固定分片键可观测性慢查询日志、节点状态、连接跟踪没有观测就上线故障时两眼一抹黑自身高可用是否支持多节点部署、共识协调单节点代理当网关宕机即全站不可用性能损耗纯转发延迟、并发qps上限、SQL解析耗时只看环境压测不看长连接下的资源占用具体到产品上如果你主要是想解决 MySQL 主从架构的读写分离和高可用几款活跃的开源路由代理已经非常成熟配置简单、文档齐全如果业务已经发展到分库分表规模需要支持数据分片、分布式事务那要考察具备完整分片能力的分布式中间件如果公司技术栈以自研为主对定制化要求极高也可以考虑基于协议解析框架自建轻量代理——但前提是你们确实有足够的人力和场景支撑。3.3 什么阶段必须引入代理我见过一些小团队数据库只有一台实例非要在前面套三层代理美其名曰“预留扩展”。这个真的没必要代理再轻也有性能开销架构复杂度的提升也值得警惕。我的判断标准很简单第一应用实例数较多、数据库连接数已经成了瓶颈这时候引入代理做连接复用极其划算。第二数据库开始做高可用有主从切换需求不想频繁改应用配置。第三读写流量不平衡需要依托代理做读写分离、慢查询熔断。第四想做灰度发布把一部分读流量切到新版本节点观察效果再决定全量切换。如果你现在只是一主一从并且流量不大直接让应用层配置主从两个数据源也能凑合。但考虑到后续扩展性和稳定性早一点引入代理并不亏——关键是代理层本身要设计好、配置好而不是简单装个服务就不管了。4. 上线部署与配置最容易翻车的几个细节我见过太多团队在代理上线的时候因为几个看起来不起眼的配置项导致事故。这里系统性梳理一遍。4.1 网络拓扑与代理自身的高可用代理层一定不能是单点。常见的部署拓扑是客户端 - 负载均衡四层 - 代理节点A/代理节点B主备或对等 - 数据库主从集群代理节点之间需要保证路由规则和会话信息的一致性所以多数代理产品会引入一个集群协调机制保证两个节点之间配置同步、故障感知。这里有个部署细节客户端最好通过一个虚拟 IPVIP访问代理集群而不是直连某个代理节点 IP。这样即使代理节点发生切换VIP 可以平滑漂移。如果不方便用 VIP那就要求客户端侧做连接重试。我们曾经跳过 VIP 直连代理节点后来一次代理节点发版重启所有应用同时报连接异常那次事故给我留下了深刻教训。4.2 连接池参数不是越大越好代理端连接池的配置大有学问。以最常见的 MySQL 代理举例几个关键参数后端最大连接数应该接近数据库max_connections的 80%~90%留 10%~20% 给管理端、备份任务等预留连接。后端最小连接数设置太小会导致频繁建连、关连设置太大又会在业务低峰期浪费数据库资源。连接空闲超时必须和数据库端的wait_timeout配置对齐。数据库默认 8 小时代理空闲超时必须小于数据库的回收时间。否则代理以为连接还活着数据库已经把连接关了下一次请求踩到死连接上应用会收到奇怪的连接重置错误。注意踩活连接问题非常隐蔽。应用侧报“Lost connection”但代理日志看起来一切正常这种现象十有八九是代理的空闲超时设置得比数据库的wait_timeout还长导致的。4.3 路由规则的边界不要当正则引擎用代理的读写路由规则通常支持按库表、用户、语句特征来匹配。新手容易把规则写得极其复杂比如给一个用户配置十几个正则表达式。这种高复杂度配置不仅难维护而且在负责人离职之后基本成了“黑盒”——没人敢改没人说得清为什么这么配。一个相对稳妥的做法是先按库级别做粗粒度路由写库/读库分组再针对个别重要接口到表级别做细粒度路由不要一开始就从表级别配起。表级别的规则很容易被新上线的业务突破——新表不在路由规则里所有流量压到主库主库压力悄然上涨表面上却看不出来直到某天容量告警。4.4 事务绑定与连接复用一对天然的敌人代理要实现高吞吐就必须尽量复用后端连接但要保证事务一致性又必须在事务期间把客户端和后端连接绑定在一起。这两者天然冲突如果一个连接一直在事务中代理就不能把这条后端连接分配给其他客户端复用。实际配置里有一个细节很多人忽略事务空闲超时。客户端开了事务然后停顿个几秒不提交如果代理等不及直接把连接收回了事务后半段再发 SQL 就会失败。但事务超时设太长又意味着后端连接被长时间占用池子容易被耗干。我个人的经验值是事务空闲超时建议设置在 30~60 秒区间。超过 60 秒的事务大概率是业务代码异常导致的悬挂事务早断早好正常的在线业务事务几十秒早该结束了。当然批处理类任务除外那类任务建议单独走一个专用的连接池。4.5 一个最小可用配置示例下面是一个简化版的代理路由配置骨架实际产品里字段名可能不同但思路一致proxy: listen: 0.0.0.0:6033 admin: enabled: true port: 6032 backend_clusters: - name: olap_cluster mode: read_only nodes: - host: 10.0.0.12, weight: 3 - host: 10.0.0.13, weight: 2 - name: primary_cluster mode: read_write nodes: - host: 10.0.0.11, weight: 10 users: - username: app_user password_hash: xxxx default_route: primary_cluster rules: - pattern: SELECT .* FROM report_.* route: olap_cluster这里有几个关键点默认路由是 primary_cluster所有未匹配的 SQL 都走主库。SELECT且表名以report_开头的查询走只读集群。weight用于控制节点间的流量比例注意权重和真实处理能力的匹配。配置好了之后必须做一件事最小化验证。验证清单包括普通SELECT是否走到了从库BEGIN; SELECT ...; COMMIT;是否全部走主库SELECT ... FOR UPDATE是否落在了主库断开一个后端从库节点新查询是否自动绕过它代理节点重启客户端连接是否自动恢复重试机制是否生效很多东西看着不起眼线上出了问题代价却极大。建议这个清单打印出来贴在工位上。5. 跑过生产才会懂的坑真实案例分析这一部分是我最想写的。压测环境跑得再漂亮很多问题也只有真实流量打过来才暴露。分享几个我印象极深的案例。5.1 预处理语句在代理层“迷路”先说预处理语句Prepared Statement路由问题。某天团队反馈他们看到读写分离根本没生效大量读流量压到了主库。从代理日志看SQL 是SELECT按规则应该走从库但实际后端节点显示流量全在主库。定位过程花了点时间。最终发现客户端使用的是COM_STMT_PREPARE协议发预处理语句真正的 SQL 是在 prepare 阶段提交的execute 阶段传的只有参数。代理在 prepare 时已经完成了路由判断但因为默认规则只解析 execute 阶段的指令而 prepare 阶段带了 SQL 文本但代理没有做识别于是默认走了主库。这个问题的根源是代理对 MySQL 协议COM_STMT_PREPARE / COM_STMT_EXECUTE两阶段交互的处理不完整。后来我们升级了代理版本并配置了“prepare 阶段即做路由判定”的开关才解决。经验上线代理之后一定要专门针对预处理语句再测一遍读写分离。如果用 ORM 框架尤其是 Java 的 MyBatis/ Hibernate 这类重度依赖 PreparedStatement 的这个问题尤其要重视。5.2 慢查询熔断把“重试风暴”放大另一个案例更隐蔽。我们给代理配置了慢查询熔断某条 SQL 执行超过 5 秒代理直接断开客户端连接并把后端节点标记为“亚健康”自动摘除权重。结果某天大促流量上来数据库出现了一次抖动部分慢 SQL 触发了熔断。应用侧的重试机制立刻补刀——被断掉的请求马上重发重发的请求又触发熔断雪球越滚越大。最终大量代理线程被重试请求占满代理自身 CPU 飙到 100%整个数据库链路被“重试风暴”放大成了全站故障。复盘之后的优化方案熔断触发后对同一类请求增加短时间窗口内的快速失败fail-fast不直接转发到后端。应用侧重试策略增加随机退避避免所有实例在同一时间点重试。代理层针对重试请求通常是一些特征参数增加限流。这个坑教育了我代理的熔断功能不是“一断了之”要配置好与上下游配合的完整策略。5.3 主从延迟造成的路由误判读写分离最怕的是主从延迟。SQL 刚写入主库立即从从库读如果从库还没来得及同步就会读到旧数据。我们曾经上线一个业务写入后立即根据主键查询详情逻辑上非常常见。主从延迟正常情况下只有几十毫秒业务无感。但某次大促主库压力变大从库同步延迟一度冲到 2 秒。结果大量写后即读的请求查不到刚写入的数据用户端表现为“提交成功但列表看不到”。排查链路是这样的第一时间看代理日志发现读请求确实路由到了从库接着查从库的同步延迟指标发现seconds_behind_master确实超过 1 秒再查业务 SQL确认存在写后立即读的模式。解决思路有几个层次业务侧对强一致要求极高的请求允许其在事务里附带master路由提示强制走主库。代理侧配置延迟阈值——从库延迟超过设定值如 500ms代理自动将其摘除出读路由池等延迟恢复后再加回来。架构侧对真正不能接受延迟的模块直接放弃读写分离走独立主库访问通道。最终我们三种方式都做了核心买卖链路强制主库次要查询走带延迟阈值的从库非核心报表访问可以接受慢一点的无所谓。没有完美方案只有场景匹配的方案。5.4 代理自身内存溢出的排查链某次凌晨监控发现代理节点内存持续上涨三天后 OOM 重启。当时很诡异数据量没涨、连接数没涨、QPS 也很平稳。完整的排查过程是这样的第一轮怀疑是后端连接泄漏检查代理后端连接池配置发现没有异常。第二轮看代理内存快照发现占用大头是一批 TCP 缓冲区对象。第三轮结合网络包分析发现某个客户端的驱动的连接 keepalive 机制比较激进导致代理缓存了大量未消费的响应数据。最终定位到是客户端连接池 max lifetime 配置和代理的回收机制不匹配客户端侧认为连接可以长期存活代理侧等不到客户端断开连接一直挂在旧节点上缓冲的旧响应越来越多。修复方式统一客户端连接的生命周期和代理的空闲回收策略并且给代理节点加上了内存监控和预警。这个问题让我意识到代理的很多“莫名其妙”的问题根源往往在客户端的连接行为上排查时不要只盯着代理本身。5.5 多实例下的“双写”迁移事故还有一次和代理相关的迁移事故严格说不是代理产品的问题是代理上的连接编排问题。我们将一个业务从单库迁移到分片集群计划通过代理层的路由规则做灰度10% 的新读写流量切到分片集群90% 留在老库。由于双写期间需要保证两边数据一致我们在代理上做了一段时间的双写转发——写请求同时发给老库和新库。结果某天应用发版新增了一个字段双写转发逻辑没有同步适配导致新库写成功、老库写失败。代理的双写是异步的老库写失败之后没有报错给应用而是打进了代理的日志结果数据分叉了。等到发现的时候对比校验工具扫出了上千条不一致数据花了整整两周才修完。教训很直白任何通过代理做的复杂流量编排都要有配套的校验、对账、回滚方案不能指望代理一配完事。代理只负责转发它不保证业务语义的完整性。6. 代理层做灰度发布与流量治理的一些进阶玩法数据库代理稳定跑起来之后你会发现它的价值远不止读写分离和高可用。它本质上是一个“数据库流量治理面”很多以前不敢做的操作现在都变得可控了。6.1 核心库表变更的灰度发布我们后来做了一次核心表结构变更从单表改为分片存储。如果直接改应用底层风险极大一个查询没适配好就会影响全站。借助代理层做了分批灰度第一步保留老表和分片表并行写入代理把写流量同时发到两边读流量仍走老表。第二步启动数据校验任务逐表对比老表和新分片表的数据一致性修复不一致项。第三步把读流量按比例切到新表先 5% 观察错误率和延迟再逐步提升到 50%、100%。第四步校验稳定后下线老表的读写只保留只读备份一段时间。整个过程业务无感出问题时随时可以一键把流量切回老表。这在直连模式下几乎是不可想象的操作数据库代理让“带备胎跑高速”成为可能。6.2 故障演练与混沌工程代理的健康检查机制可以很方便地做故障注入。比如测试从库节点宕机时读写分离表现不需要真的关数据库只要在代理层把该节点标记为不可用观察应用侧是否有异常。我们做过一次演练通过代理配置把一个从库摘除再观察全部读流量是否平滑转移、连接是否重建、有没有报错日志。整个过程只有几分钟但对团队信心提升巨大。后来真正遇到从库服务器硬件告警大家已经习惯了“摘节点、观察、修复、加回”的处理流程。6.3 流量重放与性能评估代理层记录了真实的访问日志后可以基于这些日志做离线流量回放。在数据库版本升级、参数调整、索引变更之前先在一个临时环境里重放真实流量观察慢查询和资源消耗的变化再决定要不要上线。这个玩法不需要额外开发一套流量录制系统代理的访问日志本身就是很好的流量样本。我们后来做数据库参数调优几乎都遵循“代理捞流量 - 环境回放 - 前后对比”的标准流程比拍脑袋改参数稳得多。7. 写在最后的几点个人体会聊了不少最后分享一点个人体会。第一个体会数据库代理不是银弹。它引入之后系统的故障域多了一层排查链路变长了对团队运维能力的要求也更高。如果数据库节点只有三五个、业务量不大代理带来的复杂度可能比它解决的问题还多。所以还是要回到自己的实际场景去判断。第二个体会代理层的核心价值不仅在于“转发”更在于“治理”。连接治理、流量治理、故障治理有了一层统一的流量入口很多事情从“不可控”变成“可控”。这种可控性是在高并发环境下睡个好觉的底气。第三个体会无论选哪款代理产品一定要先把监控做好再上流量。代理节点自身的 QPS、连接数、内存、GC、网络重传、后端节点健康状态全部要先接到监控大屏上。没有这些数据支撑代理就是黑盒出了故障只能靠猜代价很大。我记得第一年把数据库代理引入生产环境的时候最焦虑的不是代理本身的功能而是“本来直连一切透明现在中间多了一个东西它到底靠不靠谱”。半年之后团队从“担心的同时受益”变成了“完全依赖”。这就是数据库代理的价值——它值得敬畏也值得信任前提是你要真的懂它、用好它。