MySQL 实战宝典（九）：Sharding-JDBC分库分表框架解析

文章目录

- 一、Sharding-JDBC简介：什么是分片中间件？
- 二、分片场景：为什么需要分库分表？
- - [2.1 单表数据量过大](#2.1 单表数据量过大)
  - [2.2 单库并发压力过高](#2.2 单库并发压力过高)
  - [2.3 业务垂直拆分需求](#2.3 业务垂直拆分需求)
  - [2.4 分片场景对比](#2.4 分片场景对比)
- 三、分片策略：如何拆分数据？
- 四、分布式事务
- - [4.1 两种分布式事务模型](#4.1 两种分布式事务模型)
  - [4.2 XA 两阶段提交示意（刚性事务）](#4.2 XA 两阶段提交示意（刚性事务）)
  - [4.3 Saga事务流程示意（柔性事务）](#4.3 Saga事务流程示意（柔性事务）)
- 五、读写分离
- 六、Sharding-JDBC核心架构
- - [6.1 架构设计](#6.1 架构设计)
  - [6.2 核心工作流程](#6.2 核心工作流程)
- 总结

在互联网业务高速发展的今天，数据量呈爆炸式增长，单库单表的架构早已难以承载高并发、大数据量的业务场景。此时，分库分表成为突破性能瓶颈的关键技术，而Sharding-JDBC作为国内成熟的分库分表中间件，以其轻量级、易集成的特性被广泛采用。本文将从分片场景、分片策略、多字段复合分片、多数据源适配及分布式事务等多个核心维度，带大家全面掌握Sharding-JDBC的核心能力。

一、Sharding-JDBC简介：什么是分片中间件？

在深入细节之前，我们先明确Sharding-JDBC的定位。Sharding-JDBC是Apache ShardingSphere生态中的核心组件，它并非独立的数据库，而是一个基于JDBC的分库分表中间件，通过对JDBC接口的封装，实现分库分表、读写分离等功能，且对业务代码完全透明。

核心优势：无需部署独立服务，直接集成到应用中；支持多种数据库（MySQL、Oracle等）；兼容ORM框架（MyBatis、Hibernate等）。

二、分片场景：为什么需要分库分表？

在讨论如何分片之前，我们必须先明确什么时候需要分片。当业务满足以下场景时，就应该考虑引入Sharding-JDBC实现分库分表：

2.1 单表数据量过大

MySQL单表数据量超过1000万条后，索引查询效率会急剧下降，即使优化SQL和索引，性能提升也十分有限。此时需要将单表数据拆分到多个表中，降低单表数据量。

例如：电商平台的订单表，按年拆分后，每个表仅存储当年订单数据，查询效率大幅提升。

2.2 单库并发压力过高

当应用并发请求量过高时，单库的连接数、IO能力会达到瓶颈。此时需要将数据拆分到多个数据库中，分散并发压力。

例如：秒杀系统中，将商品库存表拆分到多个数据库，每个数据库处理部分商品的秒杀请求，避免单库连接耗尽。

2.3 业务垂直拆分需求

除了水平分片（分库分表），Sharding-JDBC也支持垂直分片：将一个数据库中不同业务模块的表拆分到不同数据库中，实现业务解耦。

例如：将电商系统的用户表、订单表、商品表分别拆分到用户库、订单库、商品库中。

2.4 分片场景对比

场景类型	适用场景	优势
水平分表	单表数据量过大	降低单表数据量，提升查询效率
水平分库	单库并发过高	分散并发压力，提升系统吞吐量
垂直分库	业务模块解耦	降低库间耦合，便于独立扩容

三、分片策略：如何拆分数据？

分片策略是Sharding-JDBC的核心，决定了数据如何拆分到不同的库和表中。Sharding-JDBC提供了内置分片策略 和自定义分片策略，满足不同业务需求。

以下是 Sharding-JDBC 核心内置分片策略的表格汇总，涵盖策略类型、适用场景、核心逻辑、配置方式、优缺点等关键信息，方便快速查阅与选型：

分片策略类型	核心算法/逻辑	适用场景	分片键要求	配置方式（核心属性）	优点	缺点
哈希取模分片（HASH_MOD）	对分片键取值哈希后，对分片数量取模（支持正负数处理，默认取绝对值）	数据均匀分布需求高的场景（如用户ID分片、订单ID分片）	数值型（Long、Integer等）	`type: HASH_MOD` `props.sharding-count: 分片数量`	实现简单、数据分布均匀、查询效率高	扩容时数据迁移量大（需重算模值）
范围分片（RANGE）	按分片键的连续范围划分分片（如时间范围、数值区间）	按区间查询频繁的场景（如按创建时间分表、按用户ID区间分库）	可比较类型（日期、数值、字符串）	`type: RANGE` `props.range-labels: 区间配置（如 202401,202406,202501）`	支持区间查询、便于数据归档（如历史数据清理）	需提前规划分片范围，避免热点分片（如某区间数据过多）
时间范围分片（TIME_RANGE）	基于时间字段自动按固定周期划分（支持年、月、日、小时等周期）	时间维度相关数据（如订单创建时间、日志时间）	时间类型（LocalDateTime、Date等）	`type: TIME_RANGE` `props.period: 周期（YEAR/MONTH/DAY/HOUR）` `props.start-time: 起始时间`	无需手动划分区间、自动扩容、适配时间归档	仅支持时间字段，非时间场景无法使用
枚举分片（INLINE）	基于Groovy表达式的枚举匹配（如 `user_id in (1,3,5) → db0`）	分片键取值固定且有限的场景（如按地区编码、用户类型分片）	任意类型（需匹配表达式）	`type: INLINE` `props.algorithm-expression: 表达式（如 db$->{user_id % 2}）`	配置灵活、支持复杂枚举逻辑、性能好	表达式复杂度高时不易维护
复合分片（COMPLEX）	组合多个分片键，通过多键协同计算分片（需配合自定义算法或内置算法组合）	复杂查询场景（如用户ID+时间范围、商家ID+订单状态）	多个字段（至少2个）	`type: COMPLEX` `props.sharding-columns: 分片键1,分片键2` `props.algorithm-name: 复合算法`	适配多维度查询、减少跨分片查询	配置与算法实现复杂、路由计算成本高
Hint分片（HINT）	不依赖SQL中的分片键，通过程序代码手动指定分片（如ThreadLocal传递分片信息）	无分片键但需固定路由的场景（如管理员按租户ID查询、跨租户数据隔离）	无（手动指定分片）	`type: HINT` `props.algorithm-name: 提示算法`	突破SQL分片键限制、路由精准	侵入业务代码、需手动维护分片上下文
一致性哈希分片（CONSISTENT_HASH）	基于一致性哈希算法，将分片键映射到哈希环，按节点分布决定分片（支持虚拟节点）	数据源扩容频繁的场景（如云原生弹性伸缩、分片节点动态增减）	数值型/字符串型	`type: CONSISTENT_HASH` `props.sharding-count: 分片数量` `props.virtual-node-count: 虚拟节点数`	扩容时数据迁移量小、负载均衡	配置稍复杂、查询路由计算比哈希取模慢
自动分片（AUTO）	由ShardingSphere自动推断分片规则（无需手动配置算法，适合快速测试）	测试环境、简单场景（无需复杂分片逻辑）	任意类型	`type: AUTO` `props.sharding-count: 分片数量`	零配置成本、快速上手	不支持复杂场景、生产环境不推荐

关键补充说明：

配置方式统一说明：所有内置策略均支持 Spring Boot 配置文件（YAML/Properties）或 Java 代码配置，表格中仅列出核心属性，完整配置需结合数据源、表规则关联；
复合分片（COMPLEX）特殊说明 ：内置未提供固定复合算法，需通过 CLASS_BASED 关联自定义复合算法，或组合多个内置算法（如哈希取模+范围分片）；
性能优先级 ：HASH_MOD > INLINE > TIME_RANGE > CONSISTENT_HASH > COMPLEX > HINT，需根据场景平衡性能与灵活性；
生产选型建议 ：
- 简单均匀分布：优先 HASH_MOD；
- 时间相关场景：优先 TIME_RANGE；
- 扩容频繁场景：优先 CONSISTENT_HASH；
- 复杂查询场景：优先 COMPLEX（配合自定义算法）；
- 测试/快速验证：优先 AUTO 或 INLINE。

四、分布式事务

Sharding-JDBC在多数据源写入场景下，需要处理跨库事务一致性；Sharding-JDBC 提供本地事务（Best Efforts Delivery、柔性事务）与 XA 事务（强一致）两类方案。

4.1 两种分布式事务模型

柔性事务刚性事务应用代码 Sharding-JDBC 各分片数据源

柔性事务（BASE 思路）
- Bed（Best Efforts Delivery）：基于数据库本地事务 +补偿/异步确认，保证最终一致。
- Saga：长事务拆分为一系列有正向/补偿操作的子事务，由内部调度器顺序/并发驱动。
- 适用：对一致性要求稍弱、更看重吞吐或可用性；业务可容忍短暂不一致。
XA 强一致事务
- 基于 JTA 规范实现，两阶段提交（2PC），协调器为 Sharding-JDBC 内部 XA 事务管理器。
- 支持 Atomikos、Narayana 等 XA 实现；要求数据源驱动可提供 XA 支持。
- 适用：金融、订单等"绝不允许脏写"场景，但性能相对受限。

4.2 XA 两阶段提交示意（刚性事务）

应用 Sharding-JDBC TM 数据源1 数据源2 begin() XA start XA start 执行业务SQL prepare prepare commit commit rollback rollback alt [所有分支准备成功] [任一失败] 应用 Sharding-JDBC TM 数据源1 数据源2

4.3 Saga事务流程示意（柔性事务）

Saga 定义：在配置或代码中描述每个 Step 的"正向/补偿"SQL 与依赖关系，调度器据此生成状态机。
顺序/并发执行：可按线性或拓扑顺序执行，调度器维护上下文（变量、前置结果）。
状态持久化：每个 Step 的开始、成功、失败、补偿等状态写入事件表，崩溃后可恢复继续。
补偿策略 ：失败即触发"逆序补偿"，每个补偿操作需幂等，并能安全回滚对应正向操作。
- 逆向操作回滚：对已执行的正向 SQL，补偿通常是等价的反向语句，例如插入对应删除、库存扣减改为加回。
- 业务字段还原：记录关键字段原值（可放上下文或事件表），补偿时用原值更新，以防依赖数据库当前状态。
- 幂等保障：所有补偿操作必须可重复执行，通过业务主键、防重表或"幂等状态位"防止重复回滚造成二次伤害。
- 异步补偿：补偿任务可能异步执行，失败可重试或进入人工干预队列；需要记录补偿状态方便监控。
- 组合补偿：复杂场景可将多个正向操作对应到一个补偿脚本，按依赖拓扑逆序执行，确保整体一致。
重试与超时：可设重试间隔、最大次数；若补偿失败进入人工干预或待办队列。

业务服务 Sharding-JDBC Saga 调度器库A分支库B分支发起 Saga（定义步骤 + 上下文）返回事务ID 执行 Step1 正向操作成功/失败执行 Step2 正向操作成功/失败补偿 Step1（若已部分完成）通知失败 alt [Step1 成功] [Step1 失败] Saga 完成触发 Step2 补偿触发 Step1 补偿返回失败并附补偿结果 alt [所有正向步骤成功] [某步失败] 业务服务 Sharding-JDBC Saga 调度器库A分支库B分支

五、读写分离

Sharding-JDBC 的读写分离是其核心能力之一，基于 "SQL 类型路由" 实现，无需独立中间件，嵌入应用即可将读 / 写操作分流到主库（写库）和从库（读库），核心目标是减轻主库压力、提升读操作吞吐量，同时保证数据一致性。

Sharding-JDBC 读写分离基于 "规则配置 + 路由分发" 实现，架构上复用其核心分层，重点新增 "读写分离规则" 和 "负载均衡引擎"：
原生JDBC API 拦截SQL 依赖配置依赖连接写操作读操作主从复制返回读结果返回写结果封装结果 ResultSet返回核心业务层-读写分离核心 SQL解析引擎
判断SQL类型-读/写路由引擎
读写分离路由 + 负载均衡延迟补偿引擎
处理主从延迟事务引擎
保证跨库事务一致性应用程序 JDBC接口层
ShardingConnection/Statement 核心业务层规则配置层
读写分离规则 + 数据源映射数据源适配层
主从数据源管理 + 连接池适配主库Master 从库集群Slave1/ Slave2/ Slave3

关键组件职责：

规则配置层：存储主从数据源映射（如 master_db → slave_db_1/slave_db_2）、负载均衡策略、延迟补偿阈值等配置；
SQL 解析引擎：解析 SQL 语法树，判断操作类型（写操作：INSERT/UPDATE/DELETE/DDL；读操作：SELECT）；
路由引擎：
写操作：直接路由到主库；
读操作：先判断是否需要延迟补偿 / 强制路由，再按负载均衡策略选择从库；
延迟补偿引擎：监控主从延迟，若满足补偿条件（如刚写主库后 N 秒内读），自动将读操作路由到主库；
强制路由：手动指定某条读操作走主库（如查询实时性要求极高的场景）；
数据源适配层：管理主从数据源连接池（如 Druid、HikariCP），提供连接复用和故障转移（如从库下线自动剔除）。

六、Sharding-JDBC核心架构

6.1 架构设计

Sharding-JDBC 架构遵循 "插件化、分层设计" 思想，从上到下分为 5 层，每层职责清晰、解耦，且支持扩展（如自定义分片算法、数据源类型等）。

层级	核心职责	核心组件/接口
1. JDBC 接口层	兼容原生 JDBC API（Connection、Statement、PreparedStatement、ResultSet 等），让应用无感知迁移	适配层：`ShardingConnection`、`ShardingPreparedStatement`、`ShardingResultSet`
2. 核心业务层	实现分库分表、读写分离、分布式事务等核心能力，是逻辑处理核心	分片引擎、路由引擎、改写引擎、合并引擎、事务引擎、认证引擎
3. 规则配置层	接收用户配置的分片规则、读写分离规则、数据源配置等，统一管理配置信息	`ShardingRule`（分片规则）、`DataSourceRule`（数据源规则）、`RuleConfiguration`
4. 元数据层	管理数据库元数据（表结构、字段类型、索引等），为上层逻辑提供数据支持	`MetaDataContext`、`TableMetaData`、`SchemaMetaData`
5. 数据源适配层	适配多种数据库连接池（Druid、HikariCP 等）和数据库类型（MySQL、Oracle 等）	`DataSource` 适配、`Connection` 代理、数据库方言（`Dialect`）

Sharding-JDBC核心原生JDBC API调用代理封装依赖配置依赖元数据关联数据源关联数据库连接物理数据库 JDBC接口层
ShardingConnection/Statement 核心业务层
分片/路由/改写/合并/事务引擎规则配置层
ShardingRule/DataSourceRule 元数据层
TableMetaData/SchemaMetaData 数据源适配层
连接池适配/数据库方言应用程序物理数据库集群
多库多表/主从

6.2 核心工作流程

以"用户查询订单"为例（假设规则：按 user_id % 2 分库，按 create_time 月份分表），拆解 Sharding-JDBC 的完整工作流程：
应用程序 JDBC接口层核心业务层规则配置层元数据层数据源适配层物理数据库集群执行逻辑SQL（SELECT * FROM t_order WHERE user_id=101...）拦截SQL请求，传递原生SQL 1. SQL解析（提取逻辑表、分片键、查询条件） 2. 获取分片规则（分库键user_id、分表键create_time） 3. 获取表结构元数据（字段类型、索引） 4. 分片计算（user_id%2=1→db_1；create_time→t_order_202401） 5. 生成路由方案（精准路由：db_1.t_order_202401） 6. 改写SQL（逻辑表→物理表，优化分页） 7. 发起物理SQL执行请求（目标数据源db_1） 8. 建立连接，执行物理SQL 返回分片结果集传递结果集 9. 结果集合并（单分片直接返回，多分片聚合）传递合并后结果集通过ResultSet返回结果（原生JDBC格式）应用程序 JDBC接口层核心业务层规则配置层元数据层数据源适配层物理数据库集群

步骤拆解：

应用发起 SQL 请求 ：应用通过原生 JDBC API 执行逻辑 SQL（逻辑表名 t_order），此处 connection 实际是 Sharding-JDBC 代理的 ShardingConnection。
SQL 解析与分片键提取：Sharding-JDBC 拦截 SQL，通过 SQL 解析器（基于 Antlr 实现）解析 SQL 语法树，提取逻辑表、分片键、查询条件等关键信息。
分片计算 ：核心业务层的分片引擎根据规则配置层的分片规则，计算目标库（user_id % 2 = 1 → db_1）和目标表（create_time 属于 2024-01 → t_order_202401）。
路由方案生成：路由引擎基于分片计算结果，生成精准路由方案（单库单表）。
SQL 改写：改写引擎将逻辑 SQL 改写为物理 SQL（替换表名，适配目标库）。
物理 SQL 执行 ：数据源适配层从目标数据源 db_1 获取原生数据库连接，执行物理 SQL 并获取结果集。
结果集合并：合并引擎对多分片结果集进行聚合（单分片直接返回）。
结果返回 ：合并后的结果集通过 ShardingResultSet 封装，以原生 JDBC 接口格式返回给应用。

总结

Sharding-JDBC 是 Java 生态下分布式数据库改造的 "轻量首选"，核心优势是低侵入、高性能、易集成，适合中小规模、读多写少、以 Java 为主的系统；其不足主要集中在多语言支持、复杂 SQL 适配、分布式事务权衡等方面，需结合业务场景规避。
若业务规模较小、改造成本敏感，且能接受其功能限制，Sharding-JDBC 是最优解；若业务跨语言、数据量超大或依赖复杂 SQL，建议选择中心化代理（Sharding-Proxy）或原生分布式数据库。

维度	优点	不足
部署集成	轻量无中心化，jar包嵌入应用，无需独立中间件；兼容原生JDBC，代码零侵入	-
性能表现	减少中间网络层级，精准路由+流式合并，性能损耗低	跨分片关联查询/分页/聚合操作性能显著下降
功能覆盖	支持分库分表、读写分离、分布式事务等核心能力；适配多数据库/连接池	对复杂SQL解析能力弱，不兼容部分数据库原生高级特性（如MySQL全文索引）
扩展能力	核心组件插件化，支持自定义分片/脱敏/负载均衡等；对接微服务生态	-
技术栈兼容	-	仅支持Java，多语言架构需搭配Sharding-Proxy，增加复杂度
运维排查	-	无统一管控台，故障需结合应用+数据库日志分析；版本兼容风险高
数据一致性	支持XA/SAGA等分布式事务，可适配不同一致性要求	读写分离场景下主从延迟易导致读旧数据；XA事务性能损耗高