简介这是一份面向Spring Boot中高级开发者的技术实践项目聚焦多数据源管理与数据库分库分表核心场景解决高并发下单库性能瓶颈与读写分离需求。资源基于Spring Boot 2.x构建集成MyBatis-Plus简化DAO层开发采用dynamic-datasource实现多数据源动态路由Sharding-JDBC完成逻辑库表拆分Druid连接池保障连接稳定性并通过Lombok减少模板代码。压缩包共162个文件115个XML映射文件支撑SQL统一管理14个Java类含Controller、Service、Mapper及测试用例6个YML配置多环境参数总大小仅164KB结构精炼、开箱即用。已有623人学习下载包含完整可运行工程、JUnit单元测试用例如UserTest、OrderController等、分层清晰的业务模块用户/订单双实体服务事务验证以及启动类FenkuApplication和配套日志、构建脚本等适合快速理解分库分表落地细节并复用于实际微服务项目。1. 多数据源 数据库分库分表不是“加个配置就行”的缝合怪而是业务增长到2000万日订单时你不得不亲手拆开数据库黑匣子的生存动作当单库单表的 MySQL 在凌晨三点开始持续报Lock wait timeout exceeded当一个简单JOIN查询从 80ms 涨到 4.2s当 DBA 第三次在周会上说“再加索引也没用了”你就该明白多数据源 数据库分库分表不是架构师画 PPT 时炫技的箭头而是业务真实压过来时你必须亲手拆解、重组、监控、兜底的一套生产级数据底盘工程。它解决的不是“能不能连上多个库”这种表层问题而是“如何让订单、用户、商品三套核心数据在物理隔离前提下仍能完成跨库事务一致性、全局唯一ID生成、分布式查询路由、以及故障时自动降级不雪崩”。适合人群非常明确正在支撑日活50万、订单量日均300万、且未来6个月有翻倍预期的中台/电商/金融类后端工程师不是刚学完 Spring Boot 多数据源教程就来试水的新人——这里没有后悔药只有血泪经验换来的参数阈值和熔断开关。本文不讲 CAP 理论推导只讲我在两个千万级订单系统里用 ShardingSphere-JDBC Druid Seata 跑通全链路的真实路径从分片键怎么选不翻车到跨库分页为什么必须加_sharding_hint再到t_order和t_order_item的绑定表配置漏写一个字段导致联查结果直接少一半——这些坑我都替你踩过了。2. 为什么必须放弃“单库单表 读写分离”三组压测数据告诉你分库分表的不可逆临界点2.1 单库扛不住的三个硬指标QPS、连接数、B树层级膨胀我们拿真实压测环境说话。测试库为 MySQL 8.0.33SSD 存储16核32G主从延迟控制在 50ms 内。对一张t_order表当前 2800 万行含 12 个索引做阶梯式压测并发线程数QPS峰值平均响应时间连接池耗尽率B树深度主键索引2001,85042ms0%48003,120118ms12%4 →5分裂一次16002,040下跌487ms抖动89%5 →6二次分裂提示B树深度每增加 1 层主键查询需多一次磁盘 IO。深度从 4→5 时随机读性能下降约 35%5→6 后即使加缓存热点更新锁冲突概率飙升至 67%。这不是理论值是我们在订单创建接口中实测的innodb_row_lock_waits指标曲线拐点。单库读写分离在此刻彻底失效从库无法分担写压力主库连接池打满后新请求排队等待而排队队列本身又成为新的瓶颈。此时加从库只是把“等锁”变成“等连接”治标不治本。2.2 多数据源 ≠ 分库分表它们解决的是完全不同的维度问题很多团队误以为“配了两个DataSource就算支持多数据源”甚至把“分库分表”当成“多数据源”的子集。这是致命认知偏差。我们用一张表厘清边界维度多数据源Multi-DataSource分库分表Sharding目标连接不同物理库如 MySQL PostgreSQL Oracle将同一逻辑库/表拆到多个物理库/表中典型场景报表系统查 Oracle交易系统写 MySQL日志写 PostgreSQL订单库按user_id % 4拆成 4 个库每个库再按order_id % 8拆 8 张表SQL 兼容性基本兼容原生 SQL但跨库 JOIN / 事务需手动处理需改写 SQL如SELECT * FROM t_order WHERE user_id ?否则路由失败事务模型本地事务每个 DataSource 自己 commit必须引入分布式事务Seata AT / XA / Saga我们选型依据业务已存在异构库如老系统用达梦新模块用 MySQL单库数据量 2000 万行 或 单表大小 20GB注意本文标题中的“多数据源数据库分库分表”是并列关系非包含关系。它指系统同时存在两类需求① 对接多个异构数据库如 MySQL 用户库 Elasticsearch 商品搜索库 Redis 缓存② 对其中某个高增长核心库如订单库实施水平分片。二者共存时分片逻辑必须严格限定在目标库内不能污染其他数据源。2.3 为什么选 ShardingSphere-JDBC 而非 MyCat 或 Vitess我们对比了三款主流分片中间件在真实业务中的落地成本评估项ShardingSphere-JDBCJVM 内嵌MyCat独立代理层VitessK8s 原生部署复杂度零新增服务仅加依赖配置文件需单独部署、维护、升级代理节点需 K8s 集群Operator学习成本极高SQL 兼容性支持 95% 原生 MySQL 语法含子查询、UNION对复杂 JOIN / GROUP BY 支持弱常需改写兼容性好但需适配 VTTablet 协议事务支持原生集成 SeataAT 模式成功率 99.2%XA 事务性能差Seata 集成文档缺失Saga 模式为主补偿逻辑开发量大监控可观测性完整暴露shardingsphere_metricsPrometheus 指标日志分散无统一 metrics 接口Metrics 丰富但需 Grafana 深度定制我们最终选择理由业务已用 Spring CloudJDBC 层改造最小运维不愿多管一个 Java 进程DBA 拒绝在生产网关前再加一层代理————结论很现实没有银弹只有约束下的最优解。ShardingSphere-JDBC 是目前 Java 生态中对现有架构侵入最小、社区活跃度最高、企业级功能最全的分片方案。它不是最“酷”的但最扛得住线上流量。3. 从零跑通分库分表用 ShardingSphere-JDBC 5.3.2 实现订单库四库八表实战3.1 环境准备与依赖锁定版本不一致是 70% 翻车的根源我们严格锁定以下组合经 3 个生产环境验证!-- pom.xml -- dependency groupIdorg.apache.shardingsphere/groupId artifactIdshardingsphere-jdbc-core-spring-boot-starter/artifactId version5.3.2/version !-- 关键5.4.x 有路由缓存 bug5.2.x 不支持 MySQL 8.0.33 的 autoIncrement -- /dependency dependency groupIdcom.alibaba/groupId artifactIddruid-spring-boot-starter/artifactId version1.2.18/version !-- 必须 1.2.16否则无法识别 ShardingSphere 的动态数据源 -- /dependency dependency groupIdio.seata/groupId artifactIdseata-spring-boot-starter/artifactId version1.7.0/version !-- 与 ShardingSphere 5.3.2 兼容性最佳 -- /dependency血泪经验曾因druid-spring-boot-starter用 1.1.23 版本导致 ShardingSphere 创建的ShardingSphereDataSource被 Druid 的DruidDataSourceAutoConfigure错误包装引发ClassCastException。解决方案只有两个要么升 Druid要么在application.yml中显式关闭 Druid 自动配置spring: autoconfigure: exclude: com.alibaba.druid.spring.boot.autoconfigure.DruidDataSourceAutoConfigure3.2 分片策略设计为什么user_id是比order_id更稳的分片键分片键Sharding Key选错等于给系统埋雷。我们对比两种主流方案方案分片键路由方式优点致命缺陷按 order_idUUID / Snowflakeorder_id % 4→ 库order_id % 8→ 表全局唯一插入无热点查询必须带 order_id但用户查订单列表时只有user_id导致全库广播查询按 user_idLong 类型user_id % 4→ 库(user_id / 4) % 8→ 表用户维度查询 100% 路由精准避免广播user_id需保证连续或可哈希老系统若用字符串 ID 需改造我们最终采用user_id方案并强制要求所有订单查询接口必须传user_id前端调用时透传网关层校验后台管理后台查“所有订单”走 Elasticsearch 同步方案绝不走分库分表库user_id类型为BIGINT UNSIGNED确保哈希计算无符号溢出。分片配置application-sharding.ymlspring: shardingsphere: mode: Standalone # 生产用 ZooKeeper此处本地调试用 Standalone props: sql-show: true # 开发期必开看实际路由 SQL datasource: common: driver-class-name: com.mysql.cj.jdbc.Driver type: com.alibaba.druid.pool.DruidDataSource names: ds_0,ds_1,ds_2,ds_3 ds_0: jdbc-url: jdbc:mysql://127.0.0.1:3306/order_db_0?useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 ds_1: jdbc-url: jdbc:mysql://127.0.0.1:3306/order_db_1?useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 ds_2: jdbc-url: jdbc:mysql://127.0.0.1:3306/order_db_2?useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 ds_3: jdbc-url: jdbc:mysql://127.0.0.1:3306/order_db_3?useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 rules: - !SHARDING tables: t_order: actualDataNodes: ds_${0..3}.t_order_${0..7} # 四库八表 tableStrategy: standard: shardingColumn: user_id shardingAlgorithmName: t_order_table_inline databaseStrategy: standard: shardingColumn: user_id shardingAlgorithmName: t_order_database_inline defaultDatabaseStrategy: none: # 全局默认不路由强制显式指定 defaultTableStrategy: none: shardingAlgorithms: t_order_database_inline: type: INLINE props: algorithm-expression: ds_${user_id % 4} # 库路由user_id % 4 t_order_table_inline: type: INLINE props: algorithm-expression: t_order_${(user_id / 4) % 8} # 表路由先除4取整再模8参数说明algorithm-expression: ds_${user_id % 4}user_id1001→1001 % 4 1→ 路由到ds_1algorithm-expression: t_order_${(user_id / 4) % 8}user_id1001→1001 / 4 250整除→250 % 8 2→ 路由到t_order_2为什么表路由用(user_id / 4) % 8而非user_id % 8避免数据倾斜若直接user_id % 8则user_id1,9,17...全进t_order_1而user_id4,12,20...全进t_order_4导致单表数据量差异超 300%。用/4先做粗粒度打散再%8细分实测各表数据量标准差 5%。3.3 绑定表Binding Table配置解决t_order与t_order_item联查不广播的关键订单主表t_order和明细表t_order_item必须绑定否则JOIN会触发全库广播4库×8表32次查询。绑定前提是两表分片键相同且分片算法一致。# 接续上文 rules 配置 - !SHARDING tables: t_order_item: actualDataNodes: ds_${0..3}.t_order_item_${0..7} tableStrategy: standard: shardingColumn: user_id shardingAlgorithmName: t_order_item_table_inline databaseStrategy: standard: shardingColumn: user_id shardingAlgorithmName: t_order_item_database_inline bindingTables: - t_order,t_order_item # 绑定表声明必须同名、同路由逻辑 shardingAlgorithms: t_order_item_database_inline: type: INLINE props: algorithm-expression: ds_${user_id % 4} t_order_item_table_inline: type: INLINE props: algorithm-expression: t_order_item_${(user_id / 4) % 8}逻辑说明ShardingSphere 检测到SELECT o.*, i.* FROM t_order o JOIN t_order_item i ON o.order_id i.order_id WHERE o.user_id ?时会根据o.user_id算出目标库ds_X和表t_order_Y复用同一套计算逻辑得出i.user_id对应的ds_X和t_order_item_Y仅向ds_X.t_order_Y和ds_X.t_order_item_Y发起 JOIN避免跨库。若未配置bindingTables则会对t_order_item单独计算路由极大概率落到不同库触发笛卡尔积广播。4. 多数据源协同如何让 ShardingSphere 分片库与 Elasticsearch、Redis、达梦数据库和平共处4.1 多数据源注册用AbstractRoutingDataSource动态切换避开 ShardingSphere 的“全包揽”陷阱ShardingSphere-JDBC 默认接管所有DataSourceBean但我们需要它只管订单库分片不管其他数据源。否则DS(es)注解会失效Elasticsearch 操作被错误路由。正确做法手动注册非分片数据源ShardingSphere 只负责shardingDataSource。Configuration public class DataSourceConfig { Bean Primary public DataSource shardingDataSource() { // ShardingSphere 创建的分片数据源只用于订单库 return ShardingSphereDataSourceFactory.createDataSource( createDataSourceMap(), Collections.singletonList(createShardingRuleConfiguration()), new Properties() ); } Bean(esDataSource) public DataSource esDataSource() { // Elasticsearch 不是 JDBC 数据源此处为示意实际用 RestHighLevelClient return new EsDataSource(); // 自定义空实现仅占位 } Bean(dmDataSource) public DataSource dmDataSource() { // 达梦数据库数据源独立配置 DruidDataSource dataSource new DruidDataSource(); dataSource.setUrl(jdbc:dm://127.0.0.1:5236?useSSLfalse); dataSource.setUsername(SYSDBA); dataSource.setPassword(SYSDBA); return dataSource; } }关键点Primary只标注shardingDataSource()Spring 事务管理器DataSourceTransactionManager默认使用它。而达梦、ES 等操作必须显式指定数据源Service public class OrderService { Resource(name shardingDataSource) private DataSource shardingDs; // 分片库专用 Resource(name dmDataSource) private DataSource dmDs; // 达梦库专用 Transactional(transactionManager shardingTransactionManager) public void createOrder(Order order) { // 此处用 shardingDs } Transactional(transactionManager dmTransactionManager) public void syncToDameng(Order order) { // 此处用 dmDs } }4.2 全局唯一 ID 生成Snowflake 改造版解决时钟回拨与机器号冲突分库分表后自增主键失效。我们弃用UUID太长、无序、索引碎片化采用改良 SnowflakeComponent public class OrderIdGenerator { private final long twepoch 1609459200000L; // 2021-01-01 00:00:00 private final long workerIdBits 5L; private final long datacenterIdBits 5L; private final long maxWorkerId -1L ^ (-1L workerIdBits); private final long maxDatacenterId -1L ^ (-1L datacenterIdBits); private final long sequenceBits 12L; private long workerId; private long datacenterId; private long sequence 0L; private long lastTimestamp -1L; public OrderIdGenerator(Value(${sharding.worker-id:1}) long workerId, Value(${sharding.datacenter-id:1}) long datacenterId) { if (workerId maxWorkerId || workerId 0) { throw new IllegalArgumentException(String.format(worker Id cant be greater than %d or less than 0, maxWorkerId)); } if (datacenterId maxDatacenterId || datacenterId 0) { throw new IllegalArgumentException(String.format(datacenter Id cant be greater than %d or less than 0, maxDatacenterId)); } this.workerId workerId; this.datacenterId datacenterId; } public synchronized long nextId() { long timestamp timeGen(); if (timestamp lastTimestamp) { // 时钟回拨最多容忍 5ms否则抛异常避免脏数据 if (lastTimestamp - timestamp 5) { try { Thread.sleep(lastTimestamp - timestamp); timestamp timeGen(); } catch (InterruptedException e) { Thread.currentThread().interrupt(); throw new RuntimeException(e); } } else { throw new RuntimeException(String.format(Clock moved backwards. Refusing to generate id for %d milliseconds, lastTimestamp - timestamp)); } } if (lastTimestamp timestamp) { sequence (sequence 1) ((1 sequenceBits) - 1); if (sequence 0) { timestamp tilNextMillis(lastTimestamp); } } else { sequence 0L; } lastTimestamp timestamp; // 时间戳(41) 数据中心(5) 工作机器(5) 序列号(12) 63bit return ((timestamp - twepoch) 22) | (datacenterId 17) | (workerId 12) | sequence; } private long tilNextMillis(long lastTimestamp) { long timestamp timeGen(); while (timestamp lastTimestamp) { timestamp timeGen(); } return timestamp; } private long timeGen() { return System.currentTimeMillis(); } }参数说明worker-id和datacenter-id通过application.yml注入每个应用实例必须唯一K8s 下用 StatefulSet 序号 namespace hash时钟回拨处理小于 5ms 自动等待大于 5ms 直接抛异常强制运维介入避免 ID 重复生成 ID 示例182456789012345678919位 long可直接存 MySQLBIGINT且天然按时间有序利于范围查询。4.3 分布式事务Seata AT 模式接入三步搞定跨库一致性订单创建需同时写t_order分片库、t_user_balance单库、t_inventory另一分片库。我们用 Seata AT 模式自动代理Step 1在t_order所在的分片数据源上启用 Seata# application-seata.yml seata: enabled: true tx-service-group: my_test_tx_group service: vgroup-mapping: my_test_tx_group: default grouplist: default: 127.0.0.1:8091 config: type: nacos nacos: server-addr: 127.0.0.1:8848 group: SEATA_GROUP registry: type: nacos nacos: application: seata-server server-addr: 127.0.0.1:8848Step 2在GlobalTransactional方法内所有 DAO 必须使用shardingDataSourceService public class OrderServiceImpl implements OrderService { Resource private OrderMapper orderMapper; // 使用 shardingDataSource Resource private UserBalanceMapper userBalanceMapper; // 使用单库数据源 Resource private InventoryMapper inventoryMapper; // 使用另一套分片数据源需额外配置 Override GlobalTransactional // Seata 全局事务注解 public void createOrder(Order order) { // 1. 写分片库 t_order orderMapper.insert(order); // 2. 写单库 t_user_balance userBalanceMapper.deduct(order.getUserId(), order.getAmount()); // 3. 写另一分片库 t_inventory需确保其 DataSource 也接入 Seata inventoryMapper.lock(order.getItemId(), order.getCount()); } }避坑点Seata AT 模式要求所有参与库的undo_log表结构一致且必须在每个物理库中创建不是逻辑库。例如order_db_0~order_db_3每个库都要有undo_log表。脚本如下CREATE TABLE undo_log ( id bigint(20) NOT NULL AUTO_INCREMENT, branch_id bigint(20) NOT NULL, xid varchar(100) NOT NULL, context varchar(128) NOT NULL, rollback_info longblob NOT NULL, log_status int(11) NOT NULL, log_created datetime NOT NULL, log_modified datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY ux_undo_log (xid,branch_id) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8mb4;5. 避坑指南那些让团队加班到凌晨的 5 个真实翻车现场5.1 现象分页查询LIMIT 20,10返回结果不足 10 条且数据重复原因ShardingSphere 对LIMIT的重写逻辑是“每个分片查LIMIT 20,10再内存合并”。若各分片数据分布不均如ds_0有 15 条ds_1有 5 条合并后总条数可能 10且ORDER BY create_time未加sharding_key时各分片排序不一致导致重复。解决强制要求分页必须带WHERE user_id ?路由到单库单表若必须查全量改用Streamskip(20).limit(10)内存分页仅限数据量 10 万或启用shardingSphere.props.sql-showtrue看实际下发的 SQL确认是否广播。5.2 现象INSERT INTO t_order SELECT ... FROM t_order_backup批量导入失败报Can not find owner data source原因ShardingSphere 不支持跨数据源的INSERT ... SELECTt_order_backup若不在分片规则中会被视为非法数据源。解决将备份表t_order_backup加入actualDataNodes并配置相同分片算法即使不分片也要声明或改用应用层分批读取t_order_backup再调用t_order的insert方法推荐可控性强。5.3 现象COUNT(*)查询响应时间从 200ms 涨到 8s原因COUNT(*)会被路由到所有分片执行再汇总。若分片数多、单分片数据量大IO 和网络开销剧增。解决业务层改用近似统计SELECT TABLE_ROWS FROM information_schema.TABLES WHERE TABLE_SCHEMAorder_db_0 AND TABLE_NAMEt_order_0误差 5%或在写入时用 Redis HyperLogLog 统计去重 UV用INCRBY统计 PV替代实时 COUNT。5.4 现象DS(slave)读写分离注解失效所有查询都打到主库原因ShardingSphere 的MasterSlaveDataSource与ShardingSphereDataSource冲突。ShardingSphere 5.x 已废弃MasterSlave改用ReadwriteSplitting规则。解决删除所有DS注解在sharding规则中配置读写分离rules: - !READWRITE_SPLITTING dataSources: pr_ds: writeDataSourceName: ds_0_write readDataSourceNames: [ds_0_read_0, ds_0_read_1]5.5 现象应用启动时报java.lang.NoClassDefFoundError: org/apache/shardingsphere/infra/route/context/RouteContext原因Maven 依赖传递冲突shardingsphere-jdbc-core-spring-boot-starter与shardingsphere-jdbc-governance-spring-boot-starter同时引入后者包含旧版 infra 包。解决mvn dependency:tree | grep shardingsphere查冲突在pom.xml中exclusion掉冲突包exclusion groupIdorg.apache.shardingsphere/groupId artifactIdshardingsphere-infra-common/artifactId /exclusion6. 生产验证与兜底技巧用这 3 个命令和 1 个脚本守住你的分库分表生命线6.1 验证分片路由是否精准shardingSphere.metrics Prometheus GrafanaShardingSphere 5.3.2 暴露完整 metrics无需额外埋点。在application.yml中开启spring: shardingsphere: props: metrics.enabled: true metrics.prometheus.host: 0.0.0.0 metrics.prometheus.port: 9191然后用 Prometheus 抓取重点关注三个指标指标名含义健康阈值告警建议shardingsphere_routing_count_total{typedatabase}库路由次数每秒 500 1000 次/秒且持续 5 分钟触发“路由风暴”告警shardingsphere_broadcast_count_total广播查询次数 0 0 即表示有 SQL 未带分片键立即排查日志shardingsphere_actual_sql_count_total实际执行 SQL 数含分片后≈ 逻辑 SQL 数 × 分片数若远大于此值说明有笛卡尔积或未绑定表技巧在 Grafana 中建面板用rate(shardingsphere_broadcast_count_total[1h]) 0做告警第一时间发现“裸奔查询”。6.2 检查分片数据均衡性一条 SQL 查清各分片数据量在任意一个分片库如order_db_0中执行SELECT ds_0 as db_name, table_name, table_rows, round(((data_length index_length) / 1024 / 1024), 2) as size_mb FROM information_schema.TABLES WHERE table_schema order_db_0 AND table_name LIKE t_order_% UNION ALL SELECT ds_1 as db_name, table_name, table_rows, round(((data_length index_length) / 1024 / 1024), 2) as size_mb FROM information_schema.TABLES WHERE table_schema order_db_1 AND table_name LIKE t_order_% -- 依此类推 ds_2, ds_3 ORDER BY db_name, table_name;判断标准各table_rows标准差 10%size_mb差异 15%。若ds_0.t_order_0有 500 万行而ds_0.t_order_1只有 80 万行说明表路由算法有 bug需检查(user_id / 4) % 8计算逻辑。6.3 兜底降级脚本当分片中间件崩溃时一键切回单库模式我们写了一个 Bash 脚本switch-to-single-db.sh放在运维平台一键执行#!/bin/bash # 切换单库模式停用 ShardingSphere直连 order_db_0 APP_PID$(pgrep -f java.*OrderApplication) if [ -z $APP_PID ]; then echo App not running exit 1 fi # 1. 修改配置中心Nacos的 dataId: order-service.yaml curl -X POST http://nacos:8848/nacos/v1/cs/configs?dataIdorder-service.yamlgroupDEFAULT_GROUP \ -H Content-Type: text/plain \ -d spring: datasource: url: jdbc:mysql://127.0.0.1:3306/order_db_0?useSSLfalse username: root password: 123456 # 2. 重启应用优雅停机 kill -15 $APP_PID sleep 10 # 3. 验证连接 nc -z 127.0.0.1 3306 echo Single DB mode activated || echo Failed为什么有效我们所有 DAO 层代码都基于JdbcTemplate或MyBatis未强依赖 ShardingSphere 的ShardingSphereDataSource。只要DataSourceBean 换成普通 Druid业务代码零修改即可运行性能下降但可用。最后说句实在话分库分表不是终点而是起点。我见过太多团队花三个月上线分片结果因为没做t_order_item的绑定表本文还有配套的精品资源点击获取