简介本资源是一份面向Java后端开发者与分布式系统学习者的分库分表实战项目包聚焦企业级大数据量场景下的数据库水平扩展难题重点解决多数据源动态切换、跨库路由与轻量级分片集成等核心问题。资源基于Sharding-JDBC框架构建SSMDemo示例工程涵盖完整可运行的SpringSpringMVCMyBatis整合结构含18个Java业务与配置类、18个XML映射与配置文件、21个编译后class字节码以及SQL建表脚本、Maven配置、Eclipse项目元数据等关键文件总计73个文件压缩包仅66KB轻量易导入。目前已有2068人学习下载适合中高级开发者快速理解分片原理并上手实践。读者可直接复用其分片规则配置如sharding-config.yaml、多数据源初始化逻辑、MyBatis兼容写法及典型分库分表SQL验证案例无需修改业务代码即可体验透明化数据路由效果。1. 分库分表不是“数据多了就拆”而是“事务边界被物理切开后一致性突然失语”你有没有遇到过这样的现场一个原本跑得好好的 Spring Boot 服务在接入分库分表后某天凌晨三点告警狂响——订单状态更新成功了但库存扣减却没发生或者更玄学的同一笔支付回调被两个不同数据源的实例同时处理生成了两条重复流水。这不是代码写错了也不是并发没加锁而是你亲手把 ACID 的“C”一致性从数据库引擎手里夺走又没给应用层配好新的“一致性罗盘”。分库分表从来不是为了解决“单库撑不住”的容量问题而生的权宜之计它的本质是一次对数据主权的重新划分当一张逻辑表被切成 N 张物理表、散落在 M 个数据库实例上时跨库的 JOIN、跨分片的事务、全局唯一主键、分布式二级索引……这些在单库时代被 MySQL 自动兜底的能力瞬间变成需要你逐行代码去重写、去补偿、去兜底的黑匣子。这份《分库分表多数据源的切换》资源不讲 ShardingSphere 配置怎么填也不列八种分片算法优劣对比表它直击那个被多数教程跳过的致命断层——当 JDBC Connection 不再是“一个数据库的句柄”而变成“一组数据库的调度器”时Spring 的 Transactional、MyBatis 的 SqlSession、甚至最基础的 DataSource.getConnection()底层契约全变了。搞懂这个切换机制你才能判断这笔钱该不该走本地事务这条日志该不该落异步队列这个 ID 是该用雪花算法还是号段模式否则所有“高可用”“高性能”的架构图都只是画在 PPT 上的后悔药。2. 多数据源切换不是换 Connection而是重建整个 SQL 执行上下文分库分表场景下“切换数据源”这四个字背后藏着远超字面的复杂性。它绝非简单地从 A 数据源取一个 Connection执行完 SQL 再换到 B 数据源——这种粗暴方式会直接击穿 Spring 的事务管理器TransactionManager、破坏 MyBatis 的 SqlSession 生命周期甚至让 Hibernate 的一级缓存形同虚设。真正的切换发生在DataSource → Connection → Statement → ResultSet这条链路的每一个环节且必须与 Spring 的事务传播行为、MyBatis 的 Executor 类型、以及分片路由规则严格对齐。2.1 Spring 事务管理器如何被“欺骗”AbstractRoutingDataSource 的动态代理陷阱Spring 提供的AbstractRoutingDataSource是实现多数据源切换的事实标准。它的核心在于determineCurrentLookupKey()方法该方法返回一个 keySpring 通过这个 key 从配置的targetDataSourcesMap 中查出对应的真实DataSource。但这里有个关键陷阱这个 key 的确定时机必须早于事务开始即早于 TransactionInterceptor 的 invoke。否则事务管理器会基于“默认数据源”开启事务后续 SQL 却发往另一个数据源导致事务失效。public class DynamicDataSource extends AbstractRoutingDataSource { Override protected Object determineCurrentLookupKey() { // ⚠️ 错误示范在 SQL 执行时才决定已晚于事务开启 // return DataSourceContextHolder.getDataSourceKey(); // ✅ 正确姿势在业务方法入口、事务注解生效前就绑定 return DataSourceContextHolder.getDataSourceKey(); } }提示DataSourceContextHolder通常是一个ThreadLocalString用于在线程内透传数据源标识。但注意——它必须在Transactional方法的第一行就设置比如通过 AOP 在进入方法前拦截并解析注解或参数而不是等到 DAO 层才去读取分片键。2.2 MyBatis 的 SqlSession 如何“认不出”新数据源Executor 与 Connection 的强耦合MyBatis 的SqlSession在创建时会绑定一个Executor而Executor又持有一个Connection。一旦SqlSession初始化完成它内部的Connection就固定了。这意味着如果你在同一个SqlSession生命周期内切换数据源MyBatis 仍会复用旧 Connection导致 SQL 发往错误库。解决方案只有两个强制刷新 SqlSession每次切换数据源前调用sqlSession.clearCache()并确保下次getMapper()获取的是新 Session放弃 SqlSession 复用改用SqlSessionTemplateSqlSessionManager让每次操作都走openSession()代价是连接池压力增大。更深层的机制在于CachingExecutor和SimpleExecutor的差异前者会缓存MappedStatement对应的BoundSql但不会缓存 Connection后者则每次 execute 都重新获取 Connection。因此在分库分表场景下SimpleExecutor反而是更安全的选择——它天然规避了 Connection 复用带来的路由错乱。2.3 分片键如何驱动路由决策从 SQL 解析到数据源 Key 的映射闭环分库分表的路由不是魔法它依赖对 SQL 的结构化解析。以SELECT * FROM t_order WHERE user_id 123 AND status PAID为例路由引擎需完成三步提取分片键值识别user_id是分库键sharding column提取其值123计算分片位置调用分片算法如user_id % 4得到库序号3映射数据源 Key将库序号3映射为ds_03再由DynamicDataSource查出真实DataSource实例。这个过程的关键在于SQL 解析的完备性。如果 SQL 中包含子查询、UNION、或WHERE条件中分片键被函数包裹如WHERE YEAR(create_time) 2024绝大多数开源分片中间件包括 ShardingSphere-JDBC 5.x 之前版本会退化为“广播查询”——即向所有数据源发送 SQL再在内存中合并结果。这不仅性能爆炸更可能因各库数据不一致导致结果错误。因此这份资源里提供的实战模块会强制你在 Mapper XML 中用bind标签预计算分片键或在 Service 层用HintManager显式指定分片值绕过 SQL 解析的不确定性。3. 分布式事务的幻灭与重建当 XA 不再可靠TCC 和 Saga 如何成为新共识单库事务靠BEGIN/COMMIT/ROLLBACK一条命令搞定分库分表后跨库更新一笔订单和库存就成了典型的分布式事务问题。但现实是JTA/XA 协议在生产环境几乎不可用——它要求所有参与方支持 XA 接口MySQL 5.7 仅部分支持且两阶段提交的阻塞特性会让系统吞吐量断崖式下跌。于是TCCTry-Confirm-Cancel和 Saga 成为事实标准。但它们不是银弹而是用应用层复杂度换取最终一致性。3.1 TCC 的“三段式”代价为什么 Try 阶段必须预留资源而非直接扣减TCC 要求每个服务提供try、confirm、cancel三个接口。以库存服务为例try(decrease: 10)检查库存是否充足并在t_stock_freeze表中插入冻结记录frozen_qty 10不真正扣减actual_qtyconfirm()将frozen_qty归零actual_qty - 10cancel()删除冻结记录释放占用。关键点在于try阶段必须是幂等、可回滚的“预留”操作而非“执行”操作。如果try直接扣减actual_qty那么当confirm失败时cancel就无法恢复原状因为扣减已发生。这份资源中的 TCC 模块会用TccTransaction注解自动注入TransactionContext并在try方法中强制校验frozen_qty actual_qty total确保预留不超限。3.2 Saga 的“补偿链”断裂风险如何用状态机保证补偿动作必达Saga 模式将一个长事务拆成多个本地事务每个事务都有对应的补偿操作。例如订单服务createOrder()→ 补偿cancelOrder()库存服务decreaseStock()→ 补偿restoreStock()支付服务pay()→ 补偿refund()。但问题来了如果decreaseStock()成功pay()却失败触发restoreStock()补偿但此时restoreStock()自身也失败了怎么办Saga 的答案是引入状态机State Machine持久化每一步的执行状态。这份资源采用Seata Saga的 JSON 状态定义{ States: { CreateOrder: { Type: ServiceTask, ServiceName: order-service, ServiceMethod: createOrder, CompensateName: cancelOrder, Next: DecreaseStock }, DecreaseStock: { Type: ServiceTask, ServiceName: stock-service, ServiceMethod: decreaseStock, CompensateName: restoreStock, Next: Pay } } }状态机引擎会将当前执行到哪一步如CurrentState: DecreaseStock写入saga_state表。即使服务宕机重启后也能从 DB 中恢复状态继续执行或发起补偿。没有状态持久化的 Saga就是裸奔的分布式事务。3.3 避坑分布式事务的五大血泪现场注意以下问题均来自某电商系统上线首周的真实故障已脱敏复现。现象 1TCC 的confirm方法超时但cancel未触发导致资金冻结无法释放原因confirm超时后TCC 框架未配置cancel的自动重试策略且cancel方法本身未做幂等校验重复调用会多次恢复库存。解决在cancel方法开头添加SELECT FOR UPDATE锁住订单记录检查status CONFIRMING才执行恢复同时配置maxRetryCount3。现象 2Saga 补偿时调用下游服务超时状态机卡死后续所有事务被阻塞原因状态机引擎的补偿任务使用同步 HTTP 调用下游服务响应慢导致线程池耗尽。解决将补偿动作改为异步消息如 Kafka状态机只负责发消息消费端幂等处理失败则重投。现象 3分库分表后Transactional注解对跨库操作完全失效但日志显示“Transaction started”原因Transactional默认使用DataSourceTransactionManager它只管理单个DataSource的事务。跨库操作时框架实际开启了两个独立事务彼此无感知。解决彻底弃用Transactional改用 TCC 或 Saga 显式编排或引入 Seata AT 模式需修改 JDBC Driver。现象 4ShardingSphere 的sharding-key在INSERT ... SELECT语句中无法解析导致全库广播原因INSERT INTO t_order SELECT * FROM t_temp WHERE user_id ?中user_id在SELECT子句ShardingSphere 5.2.0 之前版本无法提取。解决改写为INSERT INTO t_order (...) VALUES (?, ?, ...)分片键值由应用层显式传入或升级至 ShardingSphere 5.3.0 使用Hint强制路由。现象 5DataSource切换后Druid 连接池监控显示活跃连接数暴涨DB 出现大量Waiting for table metadata lock原因DynamicDataSource返回的DataSource实例未配置独立的 Druid 连接池所有分片共用同一连接池导致连接争抢。解决为每个物理DataSource配置独立的DruidDataSourceBean并在targetDataSources中注册避免共享连接池。4. 全局唯一 ID 的战争雪花算法不是终点而是分片路由的起点在单库时代AUTO_INCREMENT主键简洁可靠分库分表后它立刻变成灾难源头——不同库的自增 ID 必然冲突。于是雪花算法Snowflake成为标配。但很多人忽略了一个关键事实雪花 ID 的时间戳部分决定了它天然适合作为分库分表的路由键。因为时间有序按时间范围查询如WHERE create_time BETWEEN ? AND ?能天然命中少数几个分片避免全库扫描。4.1 雪花 ID 的位分配陷阱workerId 冲突如何让整个集群 ID 重复标准雪花 ID 是 64 位1 位符号位固定 041 位毫秒时间戳约 69 年10 位 workerId最多 1024 个节点12 位序列号每毫秒 4096 个 ID问题出在workerId如果集群用 ZooKeeper 动态分配但网络分区导致两个节点拿到相同workerId那么它们在同一毫秒生成的 ID 就会完全重复。这份资源采用“机器 IP 进程 PID” 哈希生成workerId并加入启动时校验public class SnowflakeIdGenerator { private static final long WORKER_ID_BITS 10L; private static final long MAX_WORKER_ID ~(-1L WORKER_ID_BITS); // 1023 private final long workerId; public SnowflakeIdGenerator() { String ip InetAddress.getLocalHost().getHostAddress(); int pid ManagementFactory.getRuntimeMXBean().getName().split()[0]; this.workerId (ip.hashCode() ^ pid) MAX_WORKER_ID; // 启动时校验若发现 workerId 为 0强制抛异常说明哈希冲突 if (workerId 0) { throw new RuntimeException(Snowflake workerId collision: ip ip , pid pid); } } }4.2 分片键与主键的耦合设计为什么推荐用 user_id 作分库键而非 order_id很多团队一上来就用order_id雪花 ID作分库键结果发现查询订单详情时SELECT * FROM t_order WHERE order_id ?路由精准但查询用户所有订单时SELECT * FROM t_order WHERE user_id ?却要扫全库因为user_id不是分片键。正确的做法是让分片键sharding key与高频查询条件对齐。user_id是用户维度操作的核心order_id只是单点查询标识。因此分库策略应为user_id % db_count而order_id仅作为主键存在。此时order_id的生成需携带user_id信息形成“复合 ID”// 生成 order_id高 32 位 user_id 的 hash低 32 位 雪花序列 public long generateOrderId(long userId) { long prefix Math.abs((int) userId); // user_id 的低 32 位 long suffix snowflake.nextId() 0xFFFFFFFFL; // 雪花低 32 位 return (prefix 32) | suffix; }这样order_id既全局唯一又隐含user_id信息便于反向路由。4.3 ID 生成服务的降级方案当 Redis 或 ZooKeeper 不可用时如何保命ID 生成器不能成为单点故障。这份资源内置三级降级一级正常Redis 原子自增INCR 时间戳拼接二级Redis 故障本地AtomicLong 时间戳每秒重置一次三级全故障UUID 的hashCode()截取 64 位虽不严格递增但保证唯一。降级开关通过Value(${idgen.fallback.level:1})控制运维可热更新。5. 分库分表的终极验证用 Chaos Engineering 拆掉你的“一致性幻觉”所有理论、所有配置、所有“测试通过”的用例都在生产流量面前不堪一击。真正的分库分表能力不是看它“能跑”而是看它“崩得有多优雅”。这份资源最硬核的部分是一个内嵌的混沌工程模块它不模拟网络延迟或机器宕机而是精准打击分布式事务中最脆弱的环节——补偿动作的幂等性、分片路由的确定性、以及跨库查询的一致性视图。5.1 “补偿丢失”实验强制 kill -9 Saga 补偿进程验证状态机恢复能力该模块会启动一个 Saga 流程如创建订单→扣库存→支付在decreaseStock成功后立即kill -9库存服务进程。5 秒后重启服务观察状态机是否从saga_state表中读取到CurrentState: DecreaseStock是否自动触发restoreStock补偿补偿失败时是否将状态更新为CompensatingFailed并告警。实验报告会输出关键指标RecoveryTime: 8.2s、CompensationSuccessRate: 100%、MaxRetryCount: 2。没有经过 Chaos 验证的 Saga都是纸面协议。5.2 “路由漂移”实验动态修改分片算法观测 SQL 是否发往预期库模块提供 REST API/api/sharding/algorithm?newExpruser_id%8实时更新分片表达式。随后发送 1000 条INSERT INTO t_order (user_id, ...) VALUES (123, ...)请求用tcpdump抓包分析user_id123的请求是否 100% 发往ds_03因为123%83修改算法为user_id%16后是否全部切到ds_03和ds_11123%1611若出现ds_07收到user_id123的请求则证明路由缓存未失效存在 bug。5.3 “幻读放大器”实验在跨库事务中制造时序差暴露最终一致性窗口这是最残酷的实验启动两个线程线程 A 执行update t_order set statusSHIPPED where order_id?线程 B 立即执行select status from t_order where order_id?。由于订单表和订单状态表可能分在不同库B 线程可能读到旧状态。模块会统计ReadAfterWriteLatency读写延迟分布若 99% 分位超过 200ms则说明跨库查询缺乏强一致性保障必须引入缓存双删或订阅 binlog 做最终一致。提示该实验默认关闭需在application-chaos.yml中显式启用chaos.read-after-write.enabledtrue。6. 设计取舍的十字路口当“分库分表”成为技术债你选择重构还是演进我经历过三次分库分表的落地第一次我们用 ShardingSphere-JDBC 硬切半年后发现 SQL 兼容性问题堆积如山被迫回滚第二次我们自研路由层把所有Mapper接口抽象为ShardingMapper结果开发效率暴跌新人上手要学三套语法第三次我们选了最笨的办法——不碰分库分表先做读写分离 垂直拆分把订单、用户、商品拆成独立服务每个服务内保持单库。两年过去只有订单服务因数据量过大才引入 ShardingSphere-Proxy 做透明分片。效果惊人故障率下降 70%而团队对分片逻辑的掌控力反而更强。这让我意识到分库分表不是架构的终点而是技术债的加速器。它解决的是“数据规模”问题却制造了“开发复杂度”“运维成本”“排查难度”三座大山。所以我现在的习惯是永远先问“能不能不拆”加缓存归档冷数据优化慢 SQL如果必须拆优先垂直拆分把大单体按业务域切比水平切表风险低一个数量级水平分片只在单域内进行订单服务内分库绝不跨服务分片所有分片逻辑必须可测试、可观测、可降级混沌实验不是选修课是上线前的必过门槛。这份资源里没有“最佳实践”只有我们在某电商系统、某金融平台、某 SaaS 服务中踩过的坑、填过的洞、写过的验证脚本。它不承诺让你一步登天但能确保你每一次分库分表的决策都建立在可验证的机制之上而非模糊的“听说它很牛”。从那以后我每次设计分片策略都强制走一遍混沌实验模块的./run-all-experiments.sh看着终端里滚动的PASS和FAIL心里才真正踏实。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/24 18:19:03 · 阅读 1.2k 分库分表本质：多数据源切换与分布式事务一致性实战
简介本资源是一份面向Java后端开发者与分布式系统学习者的分库分表实战项目包聚焦企业级大数据量场景下的数据库水平扩展难题重点解决多数据源动态切换、跨库路由与轻量级分片集成等核心问题。资源基于Sharding-JDBC框架构建SSMDemo示例工程涵盖完整可运行的SpringSpringMVCMyBatis整合结构含18个Java业务与配置类、18个XML映射与配置文件、21个编译后class字节码以及SQL建表脚本、Maven配置、Eclipse项目元数据等关键文件总计73个文件压缩包仅66KB轻量易导入。目前已有2068人学习下载适合中高级开发者快速理解分片原理并上手实践。读者可直接复用其分片规则配置如sharding-config.yaml、多数据源初始化逻辑、MyBatis兼容写法及典型分库分表SQL验证案例无需修改业务代码即可体验透明化数据路由效果。1. 分库分表不是“数据多了就拆”而是“事务边界被物理切开后一致性突然失语”你有没有遇到过这样的现场一个原本跑得好好的 Spring Boot 服务在接入分库分表后某天凌晨三点告警狂响——订单状态更新成功了但库存扣减却没发生或者更玄学的同一笔支付回调被两个不同数据源的实例同时处理生成了两条重复流水。这不是代码写错了也不是并发没加锁而是你亲手把 ACID 的“C”一致性从数据库引擎手里夺走又没给应用层配好新的“一致性罗盘”。分库分表从来不是为了解决“单库撑不住”的容量问题而生的权宜之计它的本质是一次对数据主权的重新划分当一张逻辑表被切成 N 张物理表、散落在 M 个数据库实例上时跨库的 JOIN、跨分片的事务、全局唯一主键、分布式二级索引……这些在单库时代被 MySQL 自动兜底的能力瞬间变成需要你逐行代码去重写、去补偿、去兜底的黑匣子。这份《分库分表多数据源的切换》资源不讲 ShardingSphere 配置怎么填也不列八种分片算法优劣对比表它直击那个被多数教程跳过的致命断层——当 JDBC Connection 不再是“一个数据库的句柄”而变成“一组数据库的调度器”时Spring 的 Transactional、MyBatis 的 SqlSession、甚至最基础的 DataSource.getConnection()底层契约全变了。搞懂这个切换机制你才能判断这笔钱该不该走本地事务这条日志该不该落异步队列这个 ID 是该用雪花算法还是号段模式否则所有“高可用”“高性能”的架构图都只是画在 PPT 上的后悔药。2. 多数据源切换不是换 Connection而是重建整个 SQL 执行上下文分库分表场景下“切换数据源”这四个字背后藏着远超字面的复杂性。它绝非简单地从 A 数据源取一个 Connection执行完 SQL 再换到 B 数据源——这种粗暴方式会直接击穿 Spring 的事务管理器TransactionManager、破坏 MyBatis 的 SqlSession 生命周期甚至让 Hibernate 的一级缓存形同虚设。真正的切换发生在DataSource → Connection → Statement → ResultSet这条链路的每一个环节且必须与 Spring 的事务传播行为、MyBatis 的 Executor 类型、以及分片路由规则严格对齐。2.1 Spring 事务管理器如何被“欺骗”AbstractRoutingDataSource 的动态代理陷阱Spring 提供的AbstractRoutingDataSource是实现多数据源切换的事实标准。它的核心在于determineCurrentLookupKey()方法该方法返回一个 keySpring 通过这个 key 从配置的targetDataSourcesMap 中查出对应的真实DataSource。但这里有个关键陷阱这个 key 的确定时机必须早于事务开始即早于 TransactionInterceptor 的 invoke。否则事务管理器会基于“默认数据源”开启事务后续 SQL 却发往另一个数据源导致事务失效。public class DynamicDataSource extends AbstractRoutingDataSource { Override protected Object determineCurrentLookupKey() { // ⚠️ 错误示范在 SQL 执行时才决定已晚于事务开启 // return DataSourceContextHolder.getDataSourceKey(); // ✅ 正确姿势在业务方法入口、事务注解生效前就绑定 return DataSourceContextHolder.getDataSourceKey(); } }提示DataSourceContextHolder通常是一个ThreadLocalString用于在线程内透传数据源标识。但注意——它必须在Transactional方法的第一行就设置比如通过 AOP 在进入方法前拦截并解析注解或参数而不是等到 DAO 层才去读取分片键。2.2 MyBatis 的 SqlSession 如何“认不出”新数据源Executor 与 Connection 的强耦合MyBatis 的SqlSession在创建时会绑定一个Executor而Executor又持有一个Connection。一旦SqlSession初始化完成它内部的Connection就固定了。这意味着如果你在同一个SqlSession生命周期内切换数据源MyBatis 仍会复用旧 Connection导致 SQL 发往错误库。解决方案只有两个强制刷新 SqlSession每次切换数据源前调用sqlSession.clearCache()并确保下次getMapper()获取的是新 Session放弃 SqlSession 复用改用SqlSessionTemplateSqlSessionManager让每次操作都走openSession()代价是连接池压力增大。更深层的机制在于CachingExecutor和SimpleExecutor的差异前者会缓存MappedStatement对应的BoundSql但不会缓存 Connection后者则每次 execute 都重新获取 Connection。因此在分库分表场景下SimpleExecutor反而是更安全的选择——它天然规避了 Connection 复用带来的路由错乱。2.3 分片键如何驱动路由决策从 SQL 解析到数据源 Key 的映射闭环分库分表的路由不是魔法它依赖对 SQL 的结构化解析。以SELECT * FROM t_order WHERE user_id 123 AND status PAID为例路由引擎需完成三步提取分片键值识别user_id是分库键sharding column提取其值123计算分片位置调用分片算法如user_id % 4得到库序号3映射数据源 Key将库序号3映射为ds_03再由DynamicDataSource查出真实DataSource实例。这个过程的关键在于SQL 解析的完备性。如果 SQL 中包含子查询、UNION、或WHERE条件中分片键被函数包裹如WHERE YEAR(create_time) 2024绝大多数开源分片中间件包括 ShardingSphere-JDBC 5.x 之前版本会退化为“广播查询”——即向所有数据源发送 SQL再在内存中合并结果。这不仅性能爆炸更可能因各库数据不一致导致结果错误。因此这份资源里提供的实战模块会强制你在 Mapper XML 中用bind标签预计算分片键或在 Service 层用HintManager显式指定分片值绕过 SQL 解析的不确定性。3. 分布式事务的幻灭与重建当 XA 不再可靠TCC 和 Saga 如何成为新共识单库事务靠BEGIN/COMMIT/ROLLBACK一条命令搞定分库分表后跨库更新一笔订单和库存就成了典型的分布式事务问题。但现实是JTA/XA 协议在生产环境几乎不可用——它要求所有参与方支持 XA 接口MySQL 5.7 仅部分支持且两阶段提交的阻塞特性会让系统吞吐量断崖式下跌。于是TCCTry-Confirm-Cancel和 Saga 成为事实标准。但它们不是银弹而是用应用层复杂度换取最终一致性。3.1 TCC 的“三段式”代价为什么 Try 阶段必须预留资源而非直接扣减TCC 要求每个服务提供try、confirm、cancel三个接口。以库存服务为例try(decrease: 10)检查库存是否充足并在t_stock_freeze表中插入冻结记录frozen_qty 10不真正扣减actual_qtyconfirm()将frozen_qty归零actual_qty - 10cancel()删除冻结记录释放占用。关键点在于try阶段必须是幂等、可回滚的“预留”操作而非“执行”操作。如果try直接扣减actual_qty那么当confirm失败时cancel就无法恢复原状因为扣减已发生。这份资源中的 TCC 模块会用TccTransaction注解自动注入TransactionContext并在try方法中强制校验frozen_qty actual_qty total确保预留不超限。3.2 Saga 的“补偿链”断裂风险如何用状态机保证补偿动作必达Saga 模式将一个长事务拆成多个本地事务每个事务都有对应的补偿操作。例如订单服务createOrder()→ 补偿cancelOrder()库存服务decreaseStock()→ 补偿restoreStock()支付服务pay()→ 补偿refund()。但问题来了如果decreaseStock()成功pay()却失败触发restoreStock()补偿但此时restoreStock()自身也失败了怎么办Saga 的答案是引入状态机State Machine持久化每一步的执行状态。这份资源采用Seata Saga的 JSON 状态定义{ States: { CreateOrder: { Type: ServiceTask, ServiceName: order-service, ServiceMethod: createOrder, CompensateName: cancelOrder, Next: DecreaseStock }, DecreaseStock: { Type: ServiceTask, ServiceName: stock-service, ServiceMethod: decreaseStock, CompensateName: restoreStock, Next: Pay } } }状态机引擎会将当前执行到哪一步如CurrentState: DecreaseStock写入saga_state表。即使服务宕机重启后也能从 DB 中恢复状态继续执行或发起补偿。没有状态持久化的 Saga就是裸奔的分布式事务。3.3 避坑分布式事务的五大血泪现场注意以下问题均来自某电商系统上线首周的真实故障已脱敏复现。现象 1TCC 的confirm方法超时但cancel未触发导致资金冻结无法释放原因confirm超时后TCC 框架未配置cancel的自动重试策略且cancel方法本身未做幂等校验重复调用会多次恢复库存。解决在cancel方法开头添加SELECT FOR UPDATE锁住订单记录检查status CONFIRMING才执行恢复同时配置maxRetryCount3。现象 2Saga 补偿时调用下游服务超时状态机卡死后续所有事务被阻塞原因状态机引擎的补偿任务使用同步 HTTP 调用下游服务响应慢导致线程池耗尽。解决将补偿动作改为异步消息如 Kafka状态机只负责发消息消费端幂等处理失败则重投。现象 3分库分表后Transactional注解对跨库操作完全失效但日志显示“Transaction started”原因Transactional默认使用DataSourceTransactionManager它只管理单个DataSource的事务。跨库操作时框架实际开启了两个独立事务彼此无感知。解决彻底弃用Transactional改用 TCC 或 Saga 显式编排或引入 Seata AT 模式需修改 JDBC Driver。现象 4ShardingSphere 的sharding-key在INSERT ... SELECT语句中无法解析导致全库广播原因INSERT INTO t_order SELECT * FROM t_temp WHERE user_id ?中user_id在SELECT子句ShardingSphere 5.2.0 之前版本无法提取。解决改写为INSERT INTO t_order (...) VALUES (?, ?, ...)分片键值由应用层显式传入或升级至 ShardingSphere 5.3.0 使用Hint强制路由。现象 5DataSource切换后Druid 连接池监控显示活跃连接数暴涨DB 出现大量Waiting for table metadata lock原因DynamicDataSource返回的DataSource实例未配置独立的 Druid 连接池所有分片共用同一连接池导致连接争抢。解决为每个物理DataSource配置独立的DruidDataSourceBean并在targetDataSources中注册避免共享连接池。4. 全局唯一 ID 的战争雪花算法不是终点而是分片路由的起点在单库时代AUTO_INCREMENT主键简洁可靠分库分表后它立刻变成灾难源头——不同库的自增 ID 必然冲突。于是雪花算法Snowflake成为标配。但很多人忽略了一个关键事实雪花 ID 的时间戳部分决定了它天然适合作为分库分表的路由键。因为时间有序按时间范围查询如WHERE create_time BETWEEN ? AND ?能天然命中少数几个分片避免全库扫描。4.1 雪花 ID 的位分配陷阱workerId 冲突如何让整个集群 ID 重复标准雪花 ID 是 64 位1 位符号位固定 041 位毫秒时间戳约 69 年10 位 workerId最多 1024 个节点12 位序列号每毫秒 4096 个 ID问题出在workerId如果集群用 ZooKeeper 动态分配但网络分区导致两个节点拿到相同workerId那么它们在同一毫秒生成的 ID 就会完全重复。这份资源采用“机器 IP 进程 PID” 哈希生成workerId并加入启动时校验public class SnowflakeIdGenerator { private static final long WORKER_ID_BITS 10L; private static final long MAX_WORKER_ID ~(-1L WORKER_ID_BITS); // 1023 private final long workerId; public SnowflakeIdGenerator() { String ip InetAddress.getLocalHost().getHostAddress(); int pid ManagementFactory.getRuntimeMXBean().getName().split()[0]; this.workerId (ip.hashCode() ^ pid) MAX_WORKER_ID; // 启动时校验若发现 workerId 为 0强制抛异常说明哈希冲突 if (workerId 0) { throw new RuntimeException(Snowflake workerId collision: ip ip , pid pid); } } }4.2 分片键与主键的耦合设计为什么推荐用 user_id 作分库键而非 order_id很多团队一上来就用order_id雪花 ID作分库键结果发现查询订单详情时SELECT * FROM t_order WHERE order_id ?路由精准但查询用户所有订单时SELECT * FROM t_order WHERE user_id ?却要扫全库因为user_id不是分片键。正确的做法是让分片键sharding key与高频查询条件对齐。user_id是用户维度操作的核心order_id只是单点查询标识。因此分库策略应为user_id % db_count而order_id仅作为主键存在。此时order_id的生成需携带user_id信息形成“复合 ID”// 生成 order_id高 32 位 user_id 的 hash低 32 位 雪花序列 public long generateOrderId(long userId) { long prefix Math.abs((int) userId); // user_id 的低 32 位 long suffix snowflake.nextId() 0xFFFFFFFFL; // 雪花低 32 位 return (prefix 32) | suffix; }这样order_id既全局唯一又隐含user_id信息便于反向路由。4.3 ID 生成服务的降级方案当 Redis 或 ZooKeeper 不可用时如何保命ID 生成器不能成为单点故障。这份资源内置三级降级一级正常Redis 原子自增INCR 时间戳拼接二级Redis 故障本地AtomicLong 时间戳每秒重置一次三级全故障UUID 的hashCode()截取 64 位虽不严格递增但保证唯一。降级开关通过Value(${idgen.fallback.level:1})控制运维可热更新。5. 分库分表的终极验证用 Chaos Engineering 拆掉你的“一致性幻觉”所有理论、所有配置、所有“测试通过”的用例都在生产流量面前不堪一击。真正的分库分表能力不是看它“能跑”而是看它“崩得有多优雅”。这份资源最硬核的部分是一个内嵌的混沌工程模块它不模拟网络延迟或机器宕机而是精准打击分布式事务中最脆弱的环节——补偿动作的幂等性、分片路由的确定性、以及跨库查询的一致性视图。5.1 “补偿丢失”实验强制 kill -9 Saga 补偿进程验证状态机恢复能力该模块会启动一个 Saga 流程如创建订单→扣库存→支付在decreaseStock成功后立即kill -9库存服务进程。5 秒后重启服务观察状态机是否从saga_state表中读取到CurrentState: DecreaseStock是否自动触发restoreStock补偿补偿失败时是否将状态更新为CompensatingFailed并告警。实验报告会输出关键指标RecoveryTime: 8.2s、CompensationSuccessRate: 100%、MaxRetryCount: 2。没有经过 Chaos 验证的 Saga都是纸面协议。5.2 “路由漂移”实验动态修改分片算法观测 SQL 是否发往预期库模块提供 REST API/api/sharding/algorithm?newExpruser_id%8实时更新分片表达式。随后发送 1000 条INSERT INTO t_order (user_id, ...) VALUES (123, ...)请求用tcpdump抓包分析user_id123的请求是否 100% 发往ds_03因为123%83修改算法为user_id%16后是否全部切到ds_03和ds_11123%1611若出现ds_07收到user_id123的请求则证明路由缓存未失效存在 bug。5.3 “幻读放大器”实验在跨库事务中制造时序差暴露最终一致性窗口这是最残酷的实验启动两个线程线程 A 执行update t_order set statusSHIPPED where order_id?线程 B 立即执行select status from t_order where order_id?。由于订单表和订单状态表可能分在不同库B 线程可能读到旧状态。模块会统计ReadAfterWriteLatency读写延迟分布若 99% 分位超过 200ms则说明跨库查询缺乏强一致性保障必须引入缓存双删或订阅 binlog 做最终一致。提示该实验默认关闭需在application-chaos.yml中显式启用chaos.read-after-write.enabledtrue。6. 设计取舍的十字路口当“分库分表”成为技术债你选择重构还是演进我经历过三次分库分表的落地第一次我们用 ShardingSphere-JDBC 硬切半年后发现 SQL 兼容性问题堆积如山被迫回滚第二次我们自研路由层把所有Mapper接口抽象为ShardingMapper结果开发效率暴跌新人上手要学三套语法第三次我们选了最笨的办法——不碰分库分表先做读写分离 垂直拆分把订单、用户、商品拆成独立服务每个服务内保持单库。两年过去只有订单服务因数据量过大才引入 ShardingSphere-Proxy 做透明分片。效果惊人故障率下降 70%而团队对分片逻辑的掌控力反而更强。这让我意识到分库分表不是架构的终点而是技术债的加速器。它解决的是“数据规模”问题却制造了“开发复杂度”“运维成本”“排查难度”三座大山。所以我现在的习惯是永远先问“能不能不拆”加缓存归档冷数据优化慢 SQL如果必须拆优先垂直拆分把大单体按业务域切比水平切表风险低一个数量级水平分片只在单域内进行订单服务内分库绝不跨服务分片所有分片逻辑必须可测试、可观测、可降级混沌实验不是选修课是上线前的必过门槛。这份资源里没有“最佳实践”只有我们在某电商系统、某金融平台、某 SaaS 服务中踩过的坑、填过的洞、写过的验证脚本。它不承诺让你一步登天但能确保你每一次分库分表的决策都建立在可验证的机制之上而非模糊的“听说它很牛”。从那以后我每次设计分片策略都强制走一遍混沌实验模块的./run-all-experiments.sh看着终端里滚动的PASS和FAIL心里才真正踏实。希望帮到你。本文还有配套的精品资源点击获取