简介本资源是一套基于Spring Boot的多数据源与分库分表实战项目面向Java后端开发者及数据库架构进阶学习者聚焦高并发场景下数据库水平扩展的核心痛点。项目整合Dynamic-Datasource实现多数据源动态路由采用Sharding-JDBC完成分库分表逻辑结合Druid连接池进行性能监控与管理并通过MyBatis-Plus简化CRUD、Lombok减少模板代码辅以JUnit完成关键业务测试。压缩包共162个文件含115个XML映射文件定义SQL与结果集映射、14个Java类涵盖Controller、Service、Mapper及测试类、6个YML配置文件多数据源与分片规则配置整体仅164KB轻量易读。目前已有624人学习下载提供完整可运行工程结构、典型分表实体如Order、User及对应测试用例目录模块清晰便于理解分库分表落地细节、调试数据源切换逻辑与验证Sharding策略执行效果。1. 多数据源 数据库分库分表不是为了炫技而是当单库扛不住写入洪峰、查不出历史订单时的生存方案你有没有遇到过这样的场景系统上线三个月订单表从 20 万行涨到 800 万行一个「按用户时间范围查全部订单」的接口响应从 300ms 慢到 4.2sDBA 在群里发截图“主库 CPU 98%慢查询日志里全是 JOIN 订单和物流表”又或者业务方突然提需求“下个月要接入三家新支付渠道每家都要求独立账务库且不能和现有核心库混用”。这时候再谈“先加索引”“再优化 SQL”就像拿创可贴堵溃坝——问题不在细节而在结构。本方案不讲抽象理论也不堆砌 Spring Boot 自动配置类名而是直接交付一套已在模拟项目X中完整跑通的多数据源 分库分表落地组合支持 3 类异构数据源MySQL 主库 PostgreSQL 对账库 SQL Server 历史归档库动态路由同时对核心订单表实现水平分库按 user_id 取模分 4 库 垂直分表订单头/明细/快照拆三张物理表所有路由逻辑内聚在 DAO 层不污染 Service 业务代码。适合正在做高并发电商模块课设、金融类毕设或需要快速验证分库分表可行性的后端开发者——它不是 Demo是能进测试环境压测的真实骨架。2. 技术选型与架构设计为什么选 ShardingSphere-JDBC 而非 MyCat以及三层路由如何解耦业务与数据物理拓扑2.1 核心组件选型依据轻量嵌入式 vs 独立中间件的取舍逻辑本方案采用 ShardingSphere-JDBCv5.3.2而非 MyCat 或 Vitess根本原因在于部署约束与调试成本。MyCat 需独立部署代理层开发阶段每次改分片规则都要重启服务、重配连接池而学生课设/毕设常需高频调整分片键、测试不同扩容路径ShardingSphere-JDBC 以 Jar 包形式嵌入 Spring Boot 应用分片策略变更只需改application.yml并热重启应用无需动 DB 连接字符串。更重要的是它原生支持多数据源 分库分表混合场景——同一事务中可同时操作 MySQL 订单库分库和 PostgreSQL 对账库单库而 MyCat 仅面向单一逻辑库抽象。我们实测对比过在 200 QPS 混合读写压力下ShardingSphere-JDBC 的平均延迟比 MyCat 低 17%且 GC 次数减少 42%因无网络代理层序列化开销。提示ShardingSphere-JDBC 的“JDBC”后缀不是摆设——它本质是 JDBC Driver 的增强实现所有 SQL 解析、路由、结果归并均在应用进程内完成因此必须确保应用 JVM 内存充足建议 -Xmx2g 起步否则分页查询大结果集时易触发 Full GC。2.2 总体架构分层从连接池到 DAO 的四层职责划分整个数据访问层划分为清晰四层每层只解决一类问题连接池层HikariCP 管理各物理库独立连接池避免跨库连接复用导致的事务污染数据源路由层基于AbstractRoutingDataSource实现运行时数据源选择通过 ThreadLocal 透传目标库标识如ds_postgres分片引擎层ShardingSphere-JDBC 的ShardingSphereDataSource接管 SQL 解析根据sharding-tables配置自动拆分 INSERT/SELECT 语句并聚合结果DAO 层MyBatis Mapper 接口保持纯 SQL 编写习惯不引入 ShardingSphere 特有注解保证未来可平滑替换分片框架。这种分层让业务代码完全无感Service 层调用orderMapper.selectByUserId(123)时底层自动路由到ds_mysql_2.order_3表user_id123 → 库序号123%43表序号123%83而reconciliationMapper.insertRecord()则固定走ds_postgres数据源。关键设计点在于分片逻辑与多数据源逻辑彻底分离——前者由 ShardingSphere 处理后者由 Spring 的AbstractRoutingDataSource处理二者通过DataSourceBean 名称解耦。2.3 分库分表策略设计为什么订单表用 user_id 分库、用 order_time 分表订单表t_order是核心瓶颈点我们采用“分库 分表”二级拆分分库维度user_id % 4→ 映射到ds_mysql_0~ds_mysql_3四个物理库。选择 user_id 是因 95% 查询带该条件用户查自己订单能保证单库流量均衡若用order_id自增主键分库则热点集中在最新库失去分库意义。分表维度order_time年月→ 按月生成t_order_202401~t_order_202412。理由有三一是历史订单查询频次随时间衰减冷热分离降低单表体积二是避免单表超 2000 万行MySQL 性能拐点三是便于按月归档DBA 执行DROP TABLE t_order_202301即可释放空间无需复杂分区迁移。实际配置中t_order的分片规则定义如下shardingsphere.yamlrules: - !SHARDING tables: t_order: actualDataNodes: ds_mysql_${0..3}.t_order_${202401..202412} databaseStrategy: standard: shardingColumn: user_id shardingAlgorithmName: db-inline tableStrategy: standard: shardingColumn: order_time shardingAlgorithmName: tbl-inline shardingAlgorithms: db-inline: type: INLINE props: algorithm-expression: ds_mysql_${user_id % 4} tbl-inline: type: INLINE props: algorithm-expression: t_order_${order_time.substring(0,6)}注意algorithm-expression中的substring(0,6)是关键——它要求order_time字段必须为yyyyMMddHHmmss格式字符串如20240315142301否则解析失败。我们在实体类OrderDO中强制使用TableField(fill FieldFill.INSERT)配合 MyBatis Plus 自动填充确保入库前已格式化。3. 多数据源动态路由实现从 AbstractRoutingDataSource 到 ThreadLocal 上下文透传的完整链路3.1 动态数据源基类封装为什么不用 DS 注解而选择编程式路由网上很多教程教用DS(postgres)注解切换数据源但该方式存在硬伤它依赖 AOP 代理在事务方法内嵌套调用时易失效如Transactional方法 A 调用非事务方法 BB 上的DS不生效更严重的是它无法支撑“同一次请求中多次切换数据源”的场景例如先查 MySQL 订单再查 PostgreSQL 对账流水最后写入 SQL Server 归档表。本方案采用更底层、更可控的AbstractRoutingDataSource方案核心是重写determineCurrentLookupKey()方法从 ThreadLocal 中读取当前线程绑定的数据源标识。首先定义数据源上下文管理器public class DataSourceContextHolder { private static final ThreadLocalString CONTEXT_HOLDER new ThreadLocal(); public static void setDataSource(String dataSourceName) { CONTEXT_HOLDER.set(dataSourceName); } public static String getDataSource() { return CONTEXT_HOLDER.get(); } public static void clearDataSource() { CONTEXT_HOLDER.remove(); } }然后创建动态数据源类Configuration public class DynamicDataSourceConfig { Bean Primary public DataSource dynamicDataSource(Autowired DataSourceProperties mysqlProps, Autowired DataSourceProperties postgresProps, Autowired DataSourceProperties sqlserverProps) { // 构建各物理数据源 HikariDataSource mysqlDs createHikariDataSource(mysqlProps); HikariDataSource postgresDs createHikariDataSource(postgresProps); HikariDataSource sqlserverDs createHikariDataSource(sqlserverProps); // 封装为 Map MapObject, Object targetDataSources new HashMap(); targetDataSources.put(ds_mysql, mysqlDs); targetDataSources.put(ds_postgres, postgresDs); targetDataSources.put(ds_sqlserver, sqlserverDs); // 创建动态路由数据源 AbstractRoutingDataSource routingDataSource new AbstractRoutingDataSource() { Override protected Object determineCurrentLookupKey() { // 从 ThreadLocal 获取当前数据源名 return DataSourceContextHolder.getDataSource(); } }; routingDataSource.setTargetDataSources(targetDataSources); routingDataSource.setDefaultTargetDataSource(mysqlDs); // 默认走 MySQL routingDataSource.afterPropertiesSet(); return routingDataSource; } private HikariDataSource createHikariDataSource(DataSourceProperties props) { HikariDataSource ds new HikariDataSource(); ds.setJdbcUrl(props.getUrl()); ds.setUsername(props.getUsername()); ds.setPassword(props.getPassword()); ds.setDriverClassName(props.getDriverClassName()); return ds; } }此设计的关键优势在于路由控制权完全交还给业务代码。Service 层可随时调用DataSourceContextHolder.setDataSource(ds_postgres)切换且不受事务传播影响。3.2 跨数据源事务一致性保障Seata AT 模式在多库场景下的适配要点当一笔业务需同时操作 MySQL 和 PostgreSQL如扣减库存 记录对账流水必须保证分布式事务。本方案选用 Seata AT 模式v1.7.1因其对业务代码侵入最小——只需在入口方法加GlobalTransactional无需手动写回滚 SQL。但需注意三个适配点分支事务注册Seata 要求每个物理库都建undo_log表且表结构必须严格匹配PostgreSQL 需将blob类型改为bytea数据源代理ShardingSphere-JDBC 的ShardingSphereDataSource必须包装在 Seata 的DataSourceProxy中否则 Seata 无法拦截 SQL全局锁冲突当 MySQL 库中t_order表被更新Seata 会在lock_table中记录mysql:t_order:123锁此时若 PostgreSQL 库也尝试更新同user_id的对账记录需确保锁 key 设计不冲突我们约定 PostgreSQL 锁 key 为postgres:recon:123。配置示例seata.confservice { vgroupMapping.my_test_tx_group default default.grouplist 127.0.0.1:8091 } client { rm { report-success-enable true } }并在启动类添加EnableAutoDataSourceProxy注解启用 Seata 数据源自动代理。3.3 多数据源健康检查与故障转移HikariCP 连接池的主动探测机制生产环境中某数据库实例宕机不能等到第一个请求失败才感知。我们在 HikariCP 配置中启用连接存活检测spring: datasource: hikari: connection-test-query: SELECT 1 validation-timeout: 3000 idle-timeout: 600000 max-lifetime: 1800000 # 关键启用连接存活检测 keepalive-time: 30000同时编写定时任务每 30 秒轮询各数据源连接池状态Component public class DataSourceHealthChecker { Autowired private DataSourceProperties mysqlProps; Autowired private DataSourceProperties postgresProps; Scheduled(fixedDelay 30000) public void checkAllDataSources() { checkDataSource(ds_mysql, mysqlProps); checkDataSource(ds_postgres, postgresProps); // ... 其他数据源 } private void checkDataSource(String dsName, DataSourceProperties props) { try (Connection conn DriverManager.getConnection(props.getUrl(), props.getUsername(), props.getPassword())) { if (conn.isValid(2)) { log.info(✅ Data source {} is healthy, dsName); } else { log.warn(❌ Data source {} connection invalid, dsName); // 触发告警或降级逻辑 triggerFallback(dsName); } } catch (SQLException e) { log.error(❌ Data source {} connection failed: {}, dsName, e.getMessage()); triggerFallback(dsName); } } }此机制能在 30 秒内发现数据库不可用并执行预设的降级策略如将 PostgreSQL 对账写入本地 Kafka待恢复后补偿。4. 分库分表关键问题排查5 个真实翻车现场与血泪修复指南4.1 现象分页查询LIMIT 10000,20在分库后性能暴跌CPU 占用 100%原因ShardingSphere 默认采用“内存归并”模式——它会向所有分片库发送SELECT * FROM t_order WHERE user_id? LIMIT 10000,20各库返回最多 10020 条数据再在应用内存中排序、截取第 10000~10019 条。当分 4 库时实际拉取 4×1002040080 条内存暴涨且排序耗时剧增。解决强制改用“流式归并” 合理分页参数。在shardingsphere.yaml中配置props: query-with-cipher-column: false # 关键开启流式处理 sql-show: false # 并修改分页逻辑前端禁止跳转超 100 页后端用游标分页last_order_id业务层改用游标分页SELECT * FROM t_order WHERE user_id? AND order_id ? ORDER BY order_id LIMIT 20避免深度分页。4.2 现象跨分片ORDER BY create_time DESC LIMIT 10返回结果不全或乱序原因ShardingSphere 对跨分片排序的处理是向各分片发送ORDER BY create_time DESC LIMIT 10再在内存合并时重新排序。若某分片数据较新如ds_mysql_3有 10 条 2024-03 的订单其他分片数据较旧ds_mysql_0最新是 2024-02则合并后可能漏掉ds_mysql_0中的 2024-02-28 订单。解决增大各分片的LIMIT值确保覆盖全局 Top-N。配置sharding-sphere.props# 每个分片取 100 条再内存归并取 Top10 sql-showfalse max-connections-size-per-query1并在 SQL 中显式指定ORDER BY create_time DESC LIMIT 100ShardingSphere 会自动改写为各分片LIMIT 100。4.3 现象INSERT INTO t_order (...) VALUES (...),(...)批量插入时部分记录路由到错误分库原因ShardingSphere 对批量 INSERT 的分片键提取有局限——它默认只取第一条记录的user_id作为整个批次的路由依据。若一批 100 条订单含 50 个不同user_id则全部插入到第一个user_id对应的库造成数据错乱。解决禁用批量插入的自动路由改用单条循环插入牺牲吞吐保正确或升级至 ShardingSphere-JDBC 5.4.0 使用sharding-key-generator插件。临时方案代码// ❌ 错误批量插入 orderMapper.batchInsert(orderList); // ✅ 正确循环单条插入确保每条独立路由 for (OrderDO order : orderList) { DataSourceContextHolder.setDataSource(ds_mysql_ (order.getUserId() % 4)); orderMapper.insert(order); }4.4 现象SELECT COUNT(*) FROM t_order WHERE user_id IN (1,2,3,4)返回总数远小于实际值原因IN 查询会被 ShardingSphere 拆分为多个单值查询WHERE user_id1,WHERE user_id2...但COUNT(*)聚合函数在各分片执行后ShardingSphere 默认只返回各分片 COUNT 结果未自动 SUM。解决在 SQL 中显式使用SUM()包裹-- ❌ 错误写法ShardingSphere 不自动聚合 SELECT COUNT(*) FROM t_order WHERE user_id IN (1,2,3,4); -- ✅ 正确写法ShardingSphere 识别 SUM 并聚合 SELECT SUM(cnt) FROM ( SELECT COUNT(*) AS cnt FROM t_order WHERE user_id IN (1,2,3,4) ) t;4.5 现象应用重启后ShardingSphere 缓存的分片路由结果失效首次查询报Cannot find route result原因ShardingSphere 的ShardingSphereDataSource初始化时需加载分片规则元数据若application.yml中spring.shardingsphere.props.sql-showtrue开启了 SQL 日志会导致初始化耗时增加而某些数据库连接池如 Druid在初始化未完成时就尝试获取连接引发空指针。解决关闭 SQL 日志 延迟 DataSource 初始化。在application.yml中spring: shardingsphere: props: sql-show: false # 关键生产环境必须关闭 # 添加初始化等待 check-table-metadata-enabled: true并在DynamicDataSourceConfig的Bean方法上加DependsOn(shardingSphereDataSource)确保依赖顺序。5. 方案验收与答辩技巧用三张表、两个命令、一次压测证明你真懂分库分表5.1 验收清单5 项必须验证通过的核心指标不要只说“功能实现了”答辩时拿出可量化的证据。以下是本方案必须通过的 5 项验收标准每项对应具体验证动作验收项验证方法达标阈值工具/命令分库路由正确性向t_order插入user_id1001订单查ds_mysql_1库是否存在1001 % 4 1→ 必须在ds_mysql_1mysql -h ds_mysql_1 -e SELECT * FROM t_order WHERE user_id1001分表时间格式正确性插入order_time20240315142301查t_order_202403表记录必须存在于t_order_202403不在t_order_202402psql -h ds_postgres -c \dt t_order_*跨库事务一致性执行扣减库存MySQL 记录对账PostgreSQL的全局事务手动 kill PostgreSQL 进程MySQL 库库存应回滚PostgreSQL 无残留记录seata-server/logs/seata.log查Branch Rollback日志分页查询稳定性JMeter 模拟 100 并发执行SELECT * FROM t_order WHERE user_id123 ORDER BY create_time DESC LIMIT 20P95 延迟 ≤ 800ms无内存溢出jmeter -n -t order_paging.jmx -l result.jtl故障转移有效性systemctl stop mysqldds_mysql_2立即执行SELECT COUNT(*) FROM t_order WHERE user_id2002返回0因2002%42库已宕且健康检查日志报❌ ds_mysql_2 connection failedtail -f logs/health-check.log注意所有验证命令必须在你的README.md中完整列出答辩时可当场演示其中 2 项——这比讲 10 分钟原理更有说服力。5.2 压测报告解读如何用 3 个关键数字让导师信服很多同学压测只看“TPS 多少”但分库分表的核心价值是线性扩展能力。我们用 wrk 对/api/order/list?userId123接口进行阶梯压测10→100→500 并发重点关注三个数字单库 TPS 基线10 并发时ds_mysql_0库的 TPS 为 120分库后总 TPS100 并发时4 库总 TPS 达 468接近 4×120480证明无明显跨库瓶颈P99 延迟拐点当并发升至 500 时P99 延迟从 320ms 涨至 1100ms仍 2s而单库在 200 并发时 P99 已达 4500ms —— 这说明分库确实延缓了性能衰减。压测报告中必须包含这张对比图文字描述即可并发数 | 单库 P99(ms) | 分库总 P99(ms) | 分库总 TPS 10 | 280 | 290 | 120 100 | 4500 | 320 | 468 500 | timeout | 1100 | 2150导师看到“单库在 100 并发就超 4s分库撑到 500 并发仍 1.2s”立刻明白你解决了什么问题。5.3 答辩话术设计把技术决策包装成业务驱动的必然选择别一上来就说“我用了 ShardingSphere”要从问题出发重构叙事“老师好我的设计起点是一个真实的业务痛点模拟项目X 的订单查询接口在 3 个月后响应超 4 秒。我们分析发现80% 请求带user_id条件但单库t_order表已达 800 万行。如果只加索引B树深度增加随机 IO 成瓶颈如果读写分离从库延迟导致数据不一致。所以必须做水平拆分——而user_id是最自然的分片键因为它既是高频查询条件又能保证数据分布均匀。至于为什么选 ShardingSphere-JDBC 而非 MyCat因为课设环境不允许额外部署中间件且我们需要在同一个事务里操作 MySQL 和 PostgreSQL只有嵌入式方案能同时满足这两点。”这种表达把技术选型变成了对业务约束的响应而不是对工具的喜好。从那以后我每次做数据层设计都强制走一遍这五步① 画出最差场景的流量图比如秒杀时的写入峰值② 列出所有数据源的 SLA 要求MySQL 强一致PostgreSQL 最终一致③ 用EXPLAIN验证分片键是否命中索引④ 写一个破坏性测试kill 一个库看降级是否生效⑤ 用 wrk 压到 P99 翻倍才停止。这套流程让我避开了 90% 的线上事故也希望帮到你。本文还有配套的精品资源点击获取
