分布式数据库代理说白了一句话让业务层像访问单库一样访问一个分布式数据库集群。这句话听起来简单真正落地时才知道坑有多深——读写分离、分库分表、连接管理、分布式事务、跨节点查询全都要在这一层解决。我最早接触这个方向是因为一个订单系统从单库演进到分片后应用代码里到处都是路由逻辑换个分片键恨不得改半个项目后来才意识到与其让每个业务团队自己处理这些琐碎细节不如在数据库前面加一个统一的代理层。这篇文章把我这些年折腾分布式数据库代理的经验整理出来包括它到底解决什么问题、核心功能怎么设计、方案怎么选、以及最常见的坑怎么排查适合正在做分布式改造、或者准备引入中间件的团队参考。1. 为什么需要分布式数据库代理1.1 从单库到分布式问题到底出在哪很多团队刚做分布式改造时第一反应是直接改应用。先做主从分离读走从库、写走主库于是每个 DAO 里多了一个“读方法”和一个“写方法”然后做分库分表按用户 ID 拆 16 张表于是每个 SQL 都要拼表名、路由到指定数据源。这种方案在小规模下能跑但业务一多就失控了报表要跨库汇总后台要按订单号查运营要按时间范围扫每个查询都得自己写合并逻辑。我见过一个项目光 SQL 路由的工具类就有三千多行而且每个业务团队各写各的风格完全不一样。更麻烦的是一旦要做主从切换或者增减分片所有应用都要跟着改配置、发版本运维成本瞬间被顶到一个离谱的高度。1.2 代理层到底解决了什么问题分布式数据库代理的核心思路是把“如何访问多个数据库实例”这件事从业务应用里抽出来放到一个独立的中间层去处理。业务应用仍然只看到一个逻辑上的数据库发出去的 SQL 和以前一样是SELECT * FROM t_order WHERE order_id ?至于这个 SQL 应该去哪个物理库、哪张物理表由代理层解析并路由。这样做有三大收益第一业务代码保持简单团队不需要维护自己的路由工具第二数据节点变化对业务透明扩分片、切主库这类操作只改代理配置第三可以把连接管理、读写分离、分布式事务等通用能力沉淀到一层所有业务共享。代价则是多了一层网络跳转以及代理本身可能成为新的性能瓶颈和故障点所以选型和部署方式需要额外谨慎。1.3 客户端模式与代理模式怎么选严格来说市面上解决这个问题有两种路线。一种叫客户端模式比如 ShardingSphere-JDBC它把路由和分片逻辑封装成 JDBC 驱动应用直接依赖 Jar 包不需要独立部署进程。优点是无额外网络开销、性能好缺点是对应用侵入强每个应用都要引入依赖并配置语言栈也被绑定。另一种就是本文重点聊的代理模式比如 ShardingSphere-Proxy、MyCat、Vitess它们独立部署成一个服务应用通过 MySQL 或 PostgreSQL 协议连接它就像连一个普通数据库。代理模式对应用最友好切换成本低也更适合多语言团队但需要单独维护集群、考虑高可用和性能消耗。我的建议是如果是全新的 Java 项目而且团队掌控力强客户端模式确实快但绝大多数传统企业场景业务系统是异构的甚至还有第三方系统要连上来代理模式几乎是唯一能落地的答案。2. 核心功能拆解一个代理该做什么2.1 读写分离与流量调度读写分离是代理最基础也最常用的功能。代理拿到一条 SQL先判断它是SELECT还是写操作然后决定发到主库还是从库。但这里有个容易被忽略的细节——事务内的读必须走主库。比如你开启一个事务先UPDATE了一条记录再SELECT这条记录如果这个读被路由到从库而主从延迟还没追上你就读到旧数据了这在业务上是不可接受的。所以好的代理会跟踪连接的事务状态一旦客户端执行了BEGIN或者任何写操作后续所有 SQL 都强制走主库直到事务提交。另外负载均衡策略也不能只看轮询。我实测下来对延迟敏感的报表类查询用ROUND_ROBIN问题不大但遇到长事务或者大查询最好按从库的实时负载动态调度否则个别从库容易积压。还有一点代理的读写分离和数据库本身的主从同步是两件事代理只负责把流量分开数据同步还得靠 MySQL 主从复制或 binlog 同步工具别搞混。2.2 分库分表路由的几种方式分片是代理最核心的能力常见有两种路由策略哈希取模和范围分片。哈希取模就是拿分片键算一个 hash再对分片数量取模比如user_id % 16优点是数据分布均匀缺点是扩分片时要迁移数据范围分片则是按时间或 ID 区间划分比如按月分表写起来直观但容易产生热点月末的订单全压在一张表上。这里我想多说一句分片键的选择几乎决定了下半辈子的幸福程度。最理想的分片键是查询频率最高的等值条件比如订单表按user_id分片那么“查某个用户的订单”只需要路由到一张表性能最好。如果业务经常按order_id查那order_id也得能映射到user_id通常的做法是订单号里冗余用户标识或者建一张映射表。最怕的是那种“我两个字段都要高频查询”又不愿意改造表结构的团队——最后要么做全库广播要么只能引入额外的索引系统。代理生成 SQL 时对大表一般不会自动做全节点查询除非你明确知道自己在干什么。2.3 连接管理前端连接和后端连接是两回事很多人第一次看代理的连接模型会懵客户端连代理是一套连接代理连真实数据库又是另一套连接这两套连接是解耦的。举个例子如果后端有 16 张表分布在 4 个库一个查询可能同时涉及多个库代理就需要同时占用多个后端连接来并行执行子查询。假设客户端的并发连接数是 200代理池里的后端连接数不够SQL 就会排队等待表现就是应用侧连接池打满、接口变慢。所以设置代理的后端连接池时不能只看客户端连接数还要看单条 SQL 平均会扇出到几个节点。我一般按“后端连接数 预估并发数 × 平均扇出数”来估算然后留 30% 余量。除了数量连接的空闲回收和健康检查也关键MySQL 的wait_timeout默认 8 小时如果代理不主动保活空闲连接很容易被数据库断开第二天上班第一波流量就会出现大量连接错误。2.4 高可用与故障转移代理层承担了所有流量的入口它自己挂了业务就全挂了所以高可用不是可选项。至少要做到两点一是代理服务本身多实例部署前面用负载均衡或 VIP 接入实例间无状态二是代理能够感知后端数据库节点的健康状态自动摘除故障节点。这里有个细节故障转移的粒度要能控制到“读”和“写”分开。某台从库磁盘满了或复制延迟过大它应该只从读流量里摘除不影响写要是主库出问题那就得触发主从切换代理自动把写流量切到新的主库。我踩过的坑是早期用一个简单的 TCP 探活来判断后端节点状态结果数据库负载很高、还能 ping 通代理照样把流量发过去直接把数据库压死。后来改成执行轻量 SQL 探活比如SELECT 1并且连续失败 3 次才摘除才算稳定下来。3. 分布式事务与一致性处理3.1 跨库事务为什么这么难分库分表之后原来单库里的一个事务可能跨了两个物理库数据库的本地事务保证不了这种场景。比如一个下单操作订单数据在order_db_0库存数据在inventory_db_1扣库存成功了但订单插入失败数据就错了。很多人第一反应是上分布式事务框架但我想先说清楚分布式事务的本质是用“最终一致性”换取“跨库操作的可行性”它不可能像单库事务那样既严格原子又高性能。两阶段提交XA看起来最“硬”但它的同步阻塞和协调者单点问题在高并发场景下很容易变成性能灾难我见过一个团队用 XA 做下单接口压测时 TPS 直接掉了 80%后来还是拆了。3.2 XA、TCC、本地消息表怎么选我的经验是方案选型要看业务对一致性的容忍度和操作的实时性要求。XA 适合小事务、低并发的强一致场景比如跨库的账户扣款、配置更新实现也简单直接在代理层开启 XA 事务就行代价是性能。TCCTry-Confirm-Cancel适合需要实时保证、但业务逻辑能拆成预留和确认两个阶段的场景比如库存预占、优惠券锁定它对业务侵入比较大每个操作都要写三个方法而且 Confirm 和 Cancel 必须保证幂等。本地消息表则是最实用的“兜底”方案——业务在主库执行本地事务同时写一张消息表然后通过异步任务把消息投递到其他库去执行因为消息和业务在同一个本地事务里所以不会丢。纯异步其实最适合大多数订单、积分、通知类场景牺牲几十毫秒的可见性换来的是系统简单可靠。代理层一般会提供 XA 支持但 TCC 和本地消息表通常是业务自己实现代理能帮忙做的是事务上下文透传和全局事务 ID 管理。3.3 分布式锁不能替代分布式事务还有一个常见误区把分布式事务和分布式锁混为一谈。分布式锁保证的是“同一时间只有一个节点能操作某资源”它解决不了“两个库的数据一起成功或一起失败”的问题。订单支付的回调你用 Redis 分布式锁保证同一笔订单不被并发处理这没错但回调里要同时改订单表和扣减库存如果第二个操作失败锁也救不了你。所以分布式锁和分布式事务是互相配合的关系——锁用来防并发冲突事务用来保证多节点操作的最终一致。不要指望“我加了锁就万事大吉”锁释放时的一致性补偿机制才是更需要花力气设计的。4. 主流方案选型对比开源代理怎么挑4.1 ShardingSphere-Proxy目前最均衡的选择ShardingSphere 是国内用得最多的分库分表中间件演进到今天已经非常成熟。Proxy 模式基于 Netty 实现数据库协议支持 MySQL 和 PostgreSQL分片、读写分离、分布式事务、数据加密这些能力都内置了。我最看好它的一点是配置完全 YAML 化规则清晰团队上手快而且它和 ShardingSphere-JDBC 共用同一套内核以后想从 Proxy 迁移到客户端模式或者反过来成本都可控。缺点是性能相比直连数据库有一定损耗实测简单查询大概有个 5% 到 10% 的开销可接受但如果你对性能极其敏感就要多做几轮压测再拍板。4.2 MyCat/MyCat2老牌中间件但生态偏重MyCat 很早就火了它更像一个“数据库路由网关”配置上有 schema.xml、rule.xml 一套体系。MyCat 2 重构过架构支持了更多协议和分布式事务能力但社区活跃度和代码现代化程度已经不如 ShardingSphere。我个人的感受是MyCat 适合老团队、老项目因为资料多网上踩坑案例也多但新项目我通常不建议从它起步原因很简单——它的分片函数和 SQL 优化能力相对有限复杂查询支持不够好遇到问题更多要靠自己啃源码。4.3 Vitess 和云数据库自带的 ProxyVitess 是 YouTube 开源的数据库集群方案它不只是一个代理而是一整套“分片数据库平台”包含自动分片、动态重均衡、在线迁移等能力在 Kubernetes 环境里部署体验很好很多海外大厂在用。不过它的学习曲线陡峭运维组件多小团队没必要上来就搞这么重。另外如果你用的是云数据库比如阿里云、腾讯云的数据库产品它们大多自带高可用和读写分离的接入地址这种“托管的代理”最大的优点是免运维缺点是定制能力弱——你没法自己写路由函数也没法调整一些底层参数。我觉得它适合业务不复杂、不想养中间件专员的团队。4.4 自研轻量代理的取舍我也见过一些大厂自研数据库代理因为业务特性太强市面方案满足不了。自研的好处是深度可控可以针对自己的业务定制路由和合并逻辑比如索引数据自动路由坏处是这几乎是一个“无底洞”——SQL 解析、协议适配、分布式事务、高可用、监控告警每一项都是深水区。如果你认真评估后仍然决定自研我的建议是不要从零开始站在开源协议解析器的肩膀上再结合实际场景做裁剪。但对绝大多数团队我更推荐先选一款成熟的代理踩坑过程中再决定要不要自研局部组件。5. 实操实录用 ShardingSphere-Proxy 落地读写分离 分片5.1 场景设定与分片规划先设定一个典型场景订单库要支撑日千万级订单规划 2 个物理库每个库 8 张表共 16 张订单表按user_id哈希分片同时每库部署一主一从读走从库。分片数量选 16 而不是 2是因为要考虑未来两三年业务增长哈希取模的分片数一旦定下来扩容时迁移数据非常痛苦。这个规划里逻辑表名是t_order物理表是ds_0.t_order_0到ds_1.t_order_15代理负责把逻辑表的 SQL 路由到正确的物理表。5.2 代理配置与启动步骤ShardingSphere-Proxy 的配置分为两层server.yaml是代理自身的配置包括端口、权限、属性config-sharding.yaml是数据源和分片规则。我贴一个简化但可运行的配置片段基于 5.x 版本# config-sharding.yaml dataSources: ds_0: dataSourceClassName: com.zaxxer.hikari.HikariDataSource url: jdbc:mysql://192.168.1.10:3306/order_db_0 username: root password: change_me ds_1: dataSourceClassName: com.zaxxer.hikari.HikariDataSource url: jdbc:mysql://192.168.1.11:3306/order_db_1 username: root password: change_me rules: - !SHARDING tables: t_order: actualDataNodes: ds_${0..1}.t_order_${0..15} tableStrategy: standard: shardingColumn: user_id shardingAlgorithmName: t_order_hash keyGenerateStrategy: column: order_id keyGeneratorName: snowflake shardingAlgorithms: t_order_hash: type: HASH_MOD props: sharding-count: 16 keyGenerators: snowflake: type: SNOWFLAKE - !READWRITE_SPLITTING dataSources: ds_0: writeDataSourceName: ds_0_write readDataSourceNames: - ds_0_read_0 - ds_0_read_1 ds_1: writeDataSourceName: ds_1_write readDataSourceNames: - ds_1_read_0启动方式很简单解压发行包后修改配置文件执行bin/start.sh默认监听3307端口。业务侧只改数据源地址从原来的jdbc:mysql://数据库IP:3306/order_db改成jdbc:mysql://代理IP:3307/order_db用户名密码用代理里配置的账密。这里我要提醒一句actualDataNodes的写法决定了路由结果ds_${0..1}和t_order_${0..15}的顺序和数量一定要和真实部署一致不然启动时校验就会报错。5.3 验证路由效果与性能观察配置上线后第一件事是验证路由对不对。直接用mysql客户端连上代理执行PREVIEW SELECT * FROM t_order WHERE user_id 123代理会返回这条 SQL 实际被路由到了哪个数据源、哪个物理表。这是我最常用的排查命令比看日志直观得多。再测一个不带分片键的查询比如SELECT * FROM t_order WHERE order_id 1这会被广播到全部 16 张表如果线上真的有人这么查你就能立刻发现慢查询从哪里来。然后观察代理的监控指标前端连接数、后端连接池活跃连接数、SQL 响应时间、路由到各节点的请求分布。有一次我压测发现某个分片明显比其他片慢查下去是那个物理表的历史数据量比其他表大了三倍索引维护成本高这就是哈希不均匀的典型表现需要回看分片键的取值分布。6. 常见问题与排查技巧实录6.1 连接池被占满接口大面积超时这是代理上线后最容易遇到的问题。表象是应用侧连接池报Connection is not available代理侧后端连接数持续打满。排查思路是先分清是前端打满还是后端打满。如果前端连接数不高而后端满了多半是 SQL 扇出太狠——一条 SQL 广播到 16 张表瞬间占用 16 个后端连接几条慢查询就能把连接池吃光。解决方向有三个限制广播查询、优化慢 SQL、调大后端连接池并设置合理的排队超时。我习惯在代理前面加一层“访问控制”把不带分片键的查询默认拦截或转发到专门的查询库线上效果很好。如果你用的是 ShardingSphere-Proxy可以打开 SQL 审计日志统计哪些 SQL 的扇出数最高针对性优化比盲目扩容有效得多。6.2 路由结果和预期不符数据查不到这个坑几乎每个团队都会踩。最常见的原因是分片键值类型不一致——表结构里user_id是字符串但代码传的是数字哈希结果完全不同路由到的表自然对不上。第二种是隐含的隐式转换比如WHERE user_id ?的?绑定参数是字符串代理解析时按字符串算 hash和建表时用数字算的不一致也会路由错。建议在创建分片算法时先拿同一批真实用户 ID 做一轮路由预演把路由结果和预期物理表逐一比对。第三种原因是分片键被写在函数里比如WHERE DATE(create_time) 2024-01-01代理解析不出来只能全库扫描这种 SQL 虽然不会查不到数据但慢得让人怀疑人生。6.3 分布式事务下数据不一致怎么快速定位用了 XA 或 TCC 之后偶尔还是会出现“主库扣了钱明细库没写入”的情况。不要慌先看全局事务日志确认事务状态是 commit 还是 rollback。XA 的典型问题是协调者崩溃后 prepared 状态的节点不知道该怎么办这就需要事务恢复机制自动扫描并补偿。TCC 的问题更多出在 Confirm 和 Cancel 的幂等性上——如果不幂等重复调用就会把库存扣成负数。我的经验是TCC 的每个操作都要带全局事务 ID 和分支操作 ID目标库要建一张“事务执行记录表”同一事务 ID 的操作只执行一次这是最朴素的幂等方案。另外任何分布式事务方案都挡不住代码层面的 bug日志里必须能看到完整的调用链否则排查一个不一致问题可能要翻半天各个库的操作记录。6.4 热点分片和数据倾斜分库分表最怕的不是数据量大而是数据不均匀。某个超级用户的订单量是普通用户的上千倍按user_id哈希后那个分片就成了热点。遇到这种情况纯粹的哈希策略解决不了需要在业务层面拆散大 Key——比如给超级用户增加一个“子账户”维度让他的数据分散到多个分片或者按时间和用户组合分片把单用户的历史订单也摊开。这属于建模层面的优化代理配置改不动。还有一类倾斜是“尾部效应”新增分片后老数据的迁移没跟上查老数据时不时路由到不存在的地方。所以扩分片这个动作一定要有专门的迁移流程用一致性校验工具核对每个分片的行数和对账数据确认无误再切流量千万别图省事直接改配置。我个人做了几年数据库中间件相关的工作最大的体会是分布式数据库代理不是一个“装上去就能用”的工具它更像是把原来分散在各处的脏活累活集中到一个地方让团队能统一治理。它确实带来了新的运维复杂度但换来的收益是业务侧极大的简化——新同学接手一个分库分表系统不用再读那几千行路由代码只需要理解“连代理、写逻辑 SQL”就够了。如果你正准备引入代理层我的建议是先在非核心系统上跑一个月重点观察路由准确性、连接池表现和慢查询分布把这些基础问题解决了再推全网。毕竟中间件越强大你越要对它保持敬畏。