企业官网建设流程全解析

简介：这份资源围绕分库分表与多数据源切换展开，面向具备一定Java基础、希望掌握数据库水平扩展方案的后端开发者与架构学习者，重点解决单库单表在海量数据下读写压力大、查询效率低的问题。压缩包共73个文件，约66KB，以18个java源码、21个class编译文件、18个xml配置及3个properties为主，辅以jsp页面、sql脚本和少量工程配置，构成一个可运行的SSMDemo示例工程。该示例演示了如何配置数据源信息、定义分片规则，并借助Sharding-JDBC在运行时自动完成SQL解析与数据路由，业务代码无需关心底层分片逻辑。已有2069人学习下载，读者可据此理解精确分片、范围分片等策略的落地方式，并进一步思考跨库关联查询、全局唯一ID与数据迁移等实践问题，适合作为分库分表入门的对照案例。

1. 分库分表之后，多数据源切换才是真正让人睡不着的那一环

单库单表跑到几百万行时，加索引、加缓存还能撑；等到单表过千万、写入开始排队，分库分表就成了绕不开的选择。但真正让项目组翻车的，往往不是分片算法本身，而是分完之后那堆数据源怎么切、切得干不干净。我见过一个模拟项目，订单按用户 ID 哈希拆成 8 库 64 表，上线第一周就出了事故：一个没走分片键的查询直接扫了全部数据源，连接池瞬间打满。这套方案要解决的，就是分库分表场景下多数据源的动态路由、事务边界和读写分离切换问题，适合正在做分布式存储毕设、课程设计，或者要给现有系统补一套分片中间件的同学和从业者参考。

2. 需求拆解与技术选型：先想清楚切什么、在哪切

2.1 从业务查询模式倒推分片键

分库分表的第一步不是选中间件，而是把查询模式列清楚。我一般会让团队把近三个月的慢查询日志拉出来，按「带不带分片键」分成两类。带分片键的查询走路由，不带的要么改业务、要么走广播、要么建异构索引表。这个判断决定了后面数据源切换的复杂度。

以订单场景为例，分片键选user_id，那么where user_id = ?能精确定位到单个库单张表；where order_no = ?就需要一张 order_no 到 user_id 的映射表，先查映射再路由。如果不做这层拆解，直接上中间件，结果就是每次查询都广播到 64 张表，性能比单库还差。

分片策略上，哈希取模分布均匀但扩容麻烦，范围分片扩容方便但容易热点。通常的做法是：核心交易表用哈希，日志类表用时间范围。这个组合在多数模拟项目里够用，也方便答辩时讲清楚取舍。

2.2 客户端分片 vs 代理层分片

多数据源切换有两种落地形态，选型时要想清楚团队维护能力。

课程设计或毕设阶段，我建议先用客户端分片，因为配置直观、调试方便，出问题能直接在应用日志里看到路由结果。代理层适合已经有多套应用、需要统一收口的场景。选型没有绝对优劣，关键是和你的交付周期、团队人数匹配。

2.3 多数据源切换要覆盖的三类场景

需求里说的「多数据源切换」，实际包含三层含义，很多人只做了第一层就以为完事了：

第一层是分片路由：根据分片键算出目标库和表，这是最基础的。第二层是读写分离：主库写、从库读，主从延迟时要能强制走主库。第三层是多租户或冷热分离：不同业务线连不同数据源，或者历史数据落到归档库。

这三层如果不在设计阶段分开建模，代码里就会变成一堆 if-else 嵌套。我的做法是抽象一个DataSourceRouter接口，每层实现一个策略，运行时按优先级链式判断。这样新增一类数据源只需要加一个策略实现，不用动主流程。

3. 总体架构设计：路由链、连接池与事务边界的职责划分

3.1 四层结构：接入层、路由层、执行层、存储层

整体架构我按四层来划分，每层职责单一，方便单独测试。

接入层负责接收 SQL 或方法调用，做参数校验和分片键提取。路由层根据分片规则和读写策略计算出目标数据源列表。执行层负责从连接池取连接、执行、归并结果。存储层就是真实的 MySQL 实例和表。

关键设计点在于：路由层不碰连接，执行层不做路由判断。这条边界一旦模糊，后面排查问题就是黑匣子。我见过把路由逻辑写进 DAO 层的代码，一个方法里既算分片又取连接，出问题时根本不知道是算错了还是连错了。

3.2 路由链的优先级设计

路由链按「强制指定 > 读写分离 > 分片路由 > 默认数据源」的顺序判断。强制指定用于主从延迟敏感的场景，比如支付回调后立即查订单，必须走主库。读写分离根据 SQL 类型判断，select走从库，insert/update/delete走主库。分片路由只在带分片键时生效，不带的走默认数据源或广播。

public interface DataSourceRouter { // 返回目标数据源标识，null 表示交给下一级策略 String route(RouteContext context); } // 强制主库策略：上下文标记了 forceMaster 就直接返回主库 public class ForceMasterRouter implements DataSourceRouter { @Override public String route(RouteContext context) { if (context.isForceMaster()) { return "master"; } return null; // 交给下一级 } } // 分片路由策略：根据 user_id 哈希取模 public class ShardRouter implements DataSourceRouter { private final int shardCount; public ShardRouter(int shardCount) { this.shardCount = shardCount; } @Override public String route(RouteContext context) { Long userId = context.getShardKey(); if (userId == null) return null; int index = (int) (userId % shardCount); return "ds_" + index; } }

上面两个策略实现同一个接口，RouteContext里携带分片键、SQL 类型、强制标记等上下文。路由链按顺序调用，第一个返回非 null 的结果即为最终数据源。这样新增策略不用改调用方，符合开闭原则。参数上shardCount要和实际库数一致，改扩容方案时只改这一个值，但要注意扩容后旧数据的迁移，这是后面避坑章节要讲的。

3.3 连接池按数据源隔离

每个物理数据源配独立连接池，不要共用一个。共用池在某个库慢查询时会拖垮所有库，这是血泪经验。配置上最小连接数按 QPS 估算，最大连接数留 20% 余量。

# 每个数据源独立配置，以 ds_0 为例 spring: datasource: ds_0: url: jdbc:mysql://host0:3306/order_db_0 username: app_user password: ${DB_PASSWORD} hikari: minimum-idle: 5 maximum-pool-size: 20 connection-timeout: 3000 idle-timeout: 600000

connection-timeout设 3 秒是刻意压短的，目的是让路由错误快速暴露而不是线程堆积。maximum-pool-size按「单库 QPS × 平均耗时」估算，20 是模拟项目里的经验值，实际要压测后调整。密码用环境变量注入，不要写死在配置文件里，这是基本的安全习惯。

4. 核心模块实现：分片算法、动态数据源与分布式事务

4.1 分片算法实现与扩容预留

分片算法要预留扩容空间，否则数据量涨上来只能停机迁移。我一般用「虚拟槽位」的思路：先固定 1024 个槽，每个槽映射到一个物理库，扩容时只迁移槽的映射关系，不动数据本身。

public class SlotBasedSharding { private static final int TOTAL_SLOTS = 1024; private final int dbCount; private final int tableCountPerDb; public SlotBasedSharding(int dbCount, int tableCountPerDb) { this.dbCount = dbCount; this.tableCountPerDb = tableCountPerDb; } // 先算槽位，再映射到库和表 public ShardResult locate(long userId) { int slot = (int) (userId % TOTAL_SLOTS); int dbIndex = slot % dbCount; int tableIndex = (slot / dbCount) % tableCountPerDb; return new ShardResult("ds_" + dbIndex, "order_" + tableIndex); } }

槽位总数 1024 是 2 的幂，取模可以用位运算优化。dbIndex和tableIndex分开算，保证同一用户的数据落在确定的库表组合上。扩容时把dbCount从 4 改成 8，只需要迁移一半槽位的数据，迁移期间双写保证一致性。这个设计在答辩时是个加分点，因为它回答了「数据量再涨怎么办」这个必问题。

4.2 动态数据源切换的 AOP 实现

数据源切换用 AOP 在方法入口织入，比在每个 DAO 方法里手动setDataSource干净得多。

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface UseDataSource { String value() default ""; // 指定数据源，空则走路由链 boolean forceMaster() default false; } @Aspect @Component public class DataSourceAspect { @Around("@annotation(useDs)") public Object switchDs(ProceedingJoinPoint pjp, UseDataSource useDs) throws Throwable { RouteContext ctx = RouteContextHolder.get(); ctx.setForceMaster(useDs.forceMaster()); String target = routerChain.route(ctx); try { DynamicDataSource.set(target); return pjp.proceed(); } finally { DynamicDataSource.clear(); // 必须清理，防止线程复用串库 } } }

finally里的clear()是关键，线程池复用线程时如果不清理，下一个请求可能用到上一个请求的数据源，这种 bug 排查起来极其痛苦。RouteContextHolder用 ThreadLocal 存上下文，同样要在请求结束时清理。注解上的forceMaster给业务方一个显式控制手段，比隐式规则可靠。

4.3 跨库事务的取舍：本地消息表 vs 两阶段提交

跨库写事务是分库分表最难的环节。两阶段提交（2PC）强一致但性能差、协调者单点；本地消息表最终一致但实现简单、可补偿。模拟项目里我通常选本地消息表，因为答辩时能讲清楚「为什么不用 2PC」本身就是加分项。

-- 本地消息表，和业务表在同一个库，保证本地事务原子性 CREATE TABLE local_message ( id BIGINT PRIMARY KEY AUTO_INCREMENT, biz_id VARCHAR(64) NOT NULL COMMENT '业务单号', payload TEXT NOT NULL COMMENT '消息内容', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待发送 1已发送 2已消费', retry_count INT NOT NULL DEFAULT 0, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_status (status) );

业务写操作和消息插入在同一个本地事务里，保证要么都成功要么都失败。后台任务扫描status=0的记录投递到消息队列，消费方幂等处理。retry_count控制重试上限，超过阈值转人工。这套方案牺牲了强一致，换来了可用性和可补偿性，适合订单、库存这类能接受最终一致的场景。金融级强一致场景另说，但那是另一个量级的复杂度。

5. 避坑与排查：多数据源切换最容易翻车的五个点

5.1 现象：偶发查询到错误库的数据

原因：ThreadLocal 上下文没清理，线程池复用导致串库。异步任务、线程池提交的任务尤其容易中招。

解决：所有set操作配finally clear，异步任务提交时显式传递上下文快照，不要依赖父线程的 ThreadLocal。上线前用压测工具跑一轮混合查询，专门验证数据归属。

5.2 现象：主从延迟导致刚写入的数据查不到

原因：写主库后立即读从库，从库同步有毫秒级延迟。

解决：对延迟敏感的操作加forceMaster标记，或者用「写后读窗口」策略，写入后 N 秒内的读强制走主库。N 按实际主从延迟 P99 取值，通常 1 到 3 秒。

5.3 现象：扩容后部分用户数据查不到

原因：分片规则改了但旧数据没迁移，或者迁移过程中双写不一致。

解决：扩容必须走「双写 + 校验 + 切读 + 下线旧写」四步，每步之间留观察期。校验环节用抽样比对，发现不一致立即回滚切读。不要图快一步到位，这是最容易出生产事故的环节。

5.4 现象：连接池耗尽但数据库负载不高

原因：某个数据源的路由错误导致连接泄漏，或者慢查询占住连接不释放。

解决：给每个数据源加连接使用监控，超过阈值告警。排查时先看show processlist确认是哪个库的连接堆积，再回溯路由日志定位是哪个分片键算错了。

5.5 现象：广播查询拖垮全部数据源

原因：不带分片键的查询走了全库扫描，数据量大时直接打满连接池。

解决：在路由层拦截无分片键的查询，强制走异构索引表或拒绝执行。业务侧要推动查询模式改造，不能靠中间件兜底。这条要在设计评审时就定下来，事后补代价很大。

6. 验收与答辩：用一张路由矩阵表证明方案闭环

验收这套方案，我一般不看代码写得多漂亮，而是让作者交一张「路由矩阵表」，把分片键有无、读写类型、强制标记三个维度的组合列全，每格填上预期数据源和实际测试结果。这张表能一次性暴露路由链的覆盖漏洞。

答辩时重点讲三件事：第一，分片键怎么选的，依据是什么查询模式；第二，扩容方案怎么设计的，槽位迁移怎么保证一致性；第三，跨库事务为什么选最终一致而不是强一致。这三个问题答清楚，基本就闭环了。老师或评委追问「如果数据量再翻十倍」，你就把槽位扩容的迁移步骤讲一遍，比空谈「可以加机器」有说服力得多。

演示环节建议准备一个脚本，连续执行「写主库 → 立即读 → 观察是否命中主库 → 等待延迟窗口 → 再读 → 观察是否命中从库」，把读写分离的切换过程可视化。再准备一个错误分片键的查询，展示拦截告警。这两个演示比讲十分钟架构图管用。

从那以后我每次做多数据源方案，都强制先画路由矩阵表再写代码，表填不满就说明设计有漏洞。希望这套结构能帮到你，少走几个我踩过的坑。

本文还有配套的精品资源，点击获取