分库分表中间件：Sharding-JDBC 与 MyCat
中间件的两类架构
分库分表中间件分为两大流派：
| 类型 | 代表 | 架构 | 特点 |
|---|---|---|---|
| 客户端（轻量级） | Sharding-JDBC | 嵌入应用 | 无独立节点，直接连数据库 |
| 服务端（代理层） | MyCat、ShardingSphere-Proxy | 独立服务 | 作为数据库代理，应用连代理 |
Sharding-JDBC（现为 Apache ShardingSphere 的一部分）
架构定位
Sharding-JDBC 是一个 JDBC 协议的轻量级 Java 框架，以 jar 包形式嵌入应用层。
应用 → Sharding-JDBC → MySQL 实例 1
→ MySQL 实例 2
→ MySQL 实例 3
应用层代码通过配置声明分片规则，Sharding-JDBC 自动解析 SQL 并路由到正确分片。
核心功能
1. 分片配置
# spring boot 配置
spring.shardingsphere:
datasource:
names: ds0,ds1
ds0:
url: jdbc:mysql://localhost:3306/db0
ds1:
url: jdbc:mysql://localhost:3306/db1
sharding:
tables:
t_order:
actual-data-nodes: ds$->{0..1}.t_order_$->{0..1}
table-strategy:
inline:
sharding-column: order_id
algorithm-expression: t_order_$->{order_id % 2}
database-strategy:
inline:
sharding-column: user_id
algorithm-expression: ds$->{user_id % 2}
t_order_item:
actual-data-nodes: ds$->{0..1}.t_order_item_$->{0..1}
2. 读写分离
spring.shardingsphere:
masterslave:
load-balance-algorithm-type: round_robin
name: ms
master-data-source-name: ds_master
slave-data-source-names: ds_slave_0,ds_slave_1
3. 广播表与绑定表
# 广播表：所有分片都存在的一份完整副本
broadcast-tables: t_config
# 绑定表：保证关联查询在同一个分片
binding-tables: t_order, t_order_item
优势
- 性能高：无网络开销，直接连接数据库
- 轻量级：jar 包嵌入，部署简单
- 功能丰富：分片、读写分离、加密、影子库等
劣势
- 语言绑定：仅支持 Java
- DB 连接数增加：每个应用实例连接多个分片
MyCat
架构定位
MyCat 是一个独立的数据库中间件代理，运行在应用和 MySQL 之间。
应用 → MyCat（代理层）→ MySQL 实例 1
→ MySQL 实例 2
→ MySQL 实例 3
应用层只需要连接 MyCat，MyCat 负责 SQL 解析、路由、结果合并。
核心配置
1. schema.xml：定义分片规则
name="TESTDB" checkSQLschema="true">
name="travelrecord" primaryKey="ID"
dataNode="dn1,dn2,dn3"
rule="sharding-by-hash"/>
name="company" primaryKey="ID"
dataNode="dn1,dn2,dn3,dn4"
type="global"/>
name="dn1" dataHost="host1" database="db1" />
name="dn2" dataHost="host2" database="db2" />
name="host1" maxCon="100" minCon="10" balance="0"
writeType="0" dbType="mysql" dbDriver="native">
host="host1_1" url="192.168.0.1:3306"
user="root" password="123456"/>
2. rule.xml：分片规则定义
name="sharding-by-hash">
name="hash" class="io.mycat.route.function.PartitionByHash">
name="count">3
优势
- 多语言/多协议：任何支持 MySQL 协议的语言或工具都能连接（包括非 Java 应用）
- 连接数收敛：应用只连接 MyCat 而非所有 MySQL 实例
- 运维友好：SQL 执行在 MyCat 上查看，类似操作单库
劣势
- 性能损耗：代理层增加网络跳转和数据传输开销
- 部署复杂：需要独立部署和维护 MyCat 集群
- 内存占用大：结果合并在代理层做，大数据量时压力大
ShardingSphere-Proxy（融合两者）
ShardingSphere 现在同时提供两种模式：Sharding-JDBC（客户端）和 ShardingSphere-Proxy（服务端），并且支持混用（Hybrid）。
应用（Java）→ Sharding-JDBC（嵌入式）
↓
非 Java 应用 → ShardingSphere-Proxy（独立代理）→ MySQL 集群
如何选择
| 条件 | 推荐 |
|---|---|
| 技术栈纯 Java | Sharding-JDBC |
| 多语言技术栈 | MyCat 或 ShardingSphere-Proxy |
| 对性能要求极高 | Sharding-JDBC |
| 运维团队能力较弱 | ShardingSphere-Proxy（有管理界面） |
| 已有 MyCat 经验 | 可继续使用 MyCat |
| 新项目 | ShardingSphere（推荐） |
面试要点
- Sharding-JDBC 是”客户端模式”，MyCat/ShardingSphere-Proxy 是”代理模式”
- 两者没有绝对优劣，取决于团队技术栈和运维能力
- ShardingSphere 是目前生态最完整、社区最活跃的方案
- MyCat 已经很久没有重大更新，新项目建议优先考虑 ShardingSphere
- 能够说清分库分表中间件的 SQL 解析和路由基本原理
© 版权声明
文章版权归作者所有，未经允许请勿转载。
THE END
暂无评论内容