SpringBoot3 + ShardingSphere-Proxy5.5.2 分库分表
摘要
-
本文介绍 SpringBoot3.5.5 + ShardingSphere-Proxy5.5.2 分库分表的使用。
-
本文将 SpringBoot3 + ShardingSphere-JDBC5.5.2 分库分表 修改为
ShardingSphere-Proxy
的模式
ShardingSphere-Proxy 简介
-
ShardingSphere-Proxy 定位为透明化的数据库代理端,通过实现数据库二进制协议,对异构语言提供支持。 目前提供 MySQL 和 PostgreSQL 协议,透明化数据库操作,对 DBA 更加友好。
- 向应用程序完全透明,可直接当做 MySQL/PostgreSQL 使用;
- 兼容 MariaDB 等基于 MySQL 协议的数据库,以及 openGauss 等基于 PostgreSQL 协议的数据库;
- 适用于任何兼容 MySQL/PostgreSQL 协议的的客户端,如:MySQL Command Client, MySQL Workbench, Navicat 等。
-
ShardingSphere-Proxy 独立部署架构图
-
ShardingSphere-Proxy 与 ShardingSphere-JDBC 的特性比较
特性 | ShardingSphere-JDBC | ShardingSphere-Proxy |
---|---|---|
数据库支持 | 任意数据库 | MySQL / PostgreSQL |
连接消耗数 | 高 | 低 |
异构语言支持 | 仅支持 Java | 支持任意语言 |
性能 | 损耗低 | 损耗略高 |
无中心化 | 是 | 否 |
静态入口 | 无 | 有 |
部署 ShardingSphere-Proxy
-
运行 ShardingSphere-Proxy 要求 JDK 1.8+
1 | wget https://www.apache.org/dyn/closer.lua/shardingsphere/5.5.2/apache-shardingsphere-5.5.2-shardingsphere-proxy-bin.tar.gz |
配置 ShardingSphere-Proxy
-
conf/global.yaml
: 全局配置,所谓全局,就是对所有逻辑库都生效的配置
1 | # https://shardingsphere.apache.org/document/current/cn/user-manual/shardingsphere-proxy/yaml-config/authority/ |
-
conf/database-my.yaml
: 自定义分配规则配置
注意:
1.名称必须以database-
开头,实际上conf
目录下有很多示例,我们可以根据需要进行配置
2.global.yaml
中的配置项不能配置到database-my.yaml
中
1 | # 数据库名称,默认值:logic_db |
-
上面的
rules
中使用的是mysql
数据库,所以我们需要引入mysql
数据库的依赖
1 | cd apache-shardingsphere-5.5.2-shardingsphere-proxy-bin/ |
-
同时
rules
中包含一些自定义的算法,我们也需要将这些算法作为依赖进行引入,将这些算法类打成jar
,然后也拷贝到ext-lib
目录下,我已经将其发布到了github上,实际上和前文中的shardingsphere-jdbc
项目中将算法配置为spi
的方式是一致的。
1 | # 1. 只克隆仓库的基本信息,不下载所有文件 |
启动与关闭 ShardingSphere Proxy
-
ShardingSphere Proxy 要求 JDK 1.8 或以上版本
1 | cd $shardingsphere-proxy$/bin |
-
参数说明
参数 | 说明 | 默认值 |
---|---|---|
-a |
绑定地址,可以是 IPv4、IPv6 或主机名,多个地址用逗号分隔。 | 0.0.0.0 |
-p |
绑定端口号,可以在 global.yaml 中修改。-p 优先级更高 |
3307 |
-c |
ShardingSphere-Proxy 配置目录路径。 | conf |
-f |
强制启动 ShardingSphere-Proxy。 | 无 |
-g |
如果在 agent 目录下部署了 shardingsphere-agent ,启用 agent 功能。 |
无 |
-s |
指定用于连接的 socket 文件路径。 | 无 |
-
ShardingSphere-Proxy 启动命令速查表
场景 | 命令示例 | 说明 |
---|---|---|
默认启动 | ./start.sh |
默认端口 3307 ,配置目录 conf |
指定端口和配置目录 | ./start.sh 3308 /opt/shardingsphere-proxy/conf |
简写模式,指定端口和配置目录 |
参数形式启动 | ./start.sh -p 3308 -c /opt/shardingsphere-proxy/conf |
与上面等效,但更明确 |
指定监听地址 | ./start.sh -a 192.168.1.100 -p 3307 -c conf |
指定单个 IP 地址 |
指定多个监听地址 | ./start.sh -a 192.168.1.100,127.0.0.1 -p 3307 -c conf |
多个地址用逗号分隔 |
强制启动 | ./start.sh -p 3307 -c conf -f |
遇到残留 PID 文件时使用 |
启用 agent | ./start.sh -p 3307 -c conf -g |
启动 ShardingSphere-Agent |
使用 Unix Socket | ./start.sh -p 3307 -c conf -s /tmp/sharding-proxy.sock |
通过 Socket 文件进行连接 |
多选项组合 | ./start.sh -a 127.0.0.1 -p 3310 -c /opt/proxy/conf -f -g -s /tmp/proxy.sock |
一次性指定多个选项 |
项目连接 ShardingSphere-Proxy 时,就像连接普通的 mysql 服务一样
后记
-
在
ShardingSphere-JDBC
和ShardingSphere-Proxy
中,存在部分 MySQL(其它数据库也类似) 的 SQL 语法或功能目前还不完全支持的情况。ShardingSphere
在做 SQL 路由、改写、执行时,必须能解析 SQL 并理解其语义,但并不是 MySQL 的 100% 完全代理。因此,有些复杂或特定场景下的 SQL 可能无法被正确解析或执行。 -
支持良好的 SQL 语法
- 基础 DML
SELECT、INSERT、UPDATE、DELETE
基本的条件查询、排序、分页、分组、聚合函数(如 COUNT、SUM、AVG) - DCL
基本的事务语句:BEGIN、COMMIT、ROLLBACK - DDL
部分表结构管理语句:CREATE TABLE、ALTER TABLE、DROP TABLE - 函数支持
大部分常用的 MySQL 内置函数,如字符串、数学、日期函数
- 基础 DML
在 ShardingSphere + MySQL 下建议避免或谨慎使用的 SQL 清单
-
- 跨分片复杂查询
SQL 场景 | 原因 | 建议处理方式 |
---|---|---|
多表复杂 JOIN(特别是跨分片) | 需要跨库数据聚合,性能差,可能报错 | 使用广播表/绑定表,或在应用层完成 |
跨分片子查询 | SQL 路由困难,可能不支持 | 尽量改成单表查询或分步查询 |
跨分片的 GROUP BY / ORDER BY | 在 Proxy 层聚合,性能很差 | 尽量避免,或控制数据量 |
-
- DDL 相关
SQL 场景 | 原因 | 建议处理方式 |
---|---|---|
ALTER TABLE 复杂变更 |
需在所有分片执行,可能执行失败 | 手动在每个分片库执行 |
CREATE TRIGGER 、PROCEDURE |
Proxy 不解析这些语法,直接透传不安全 | 尽量在单库手动创建 |
CREATE FUNCTION |
同上 | 单库执行或应用层替代 |
FULLTEXT INDEX 、SPATIAL INDEX |
分片环境下无法自动维护索引 | 单库手动维护或避免使用 |
-
- 文件导入导出
SQL 场景 | 原因 | 建议处理方式 |
---|---|---|
LOAD DATA INFILE |
Proxy 不支持文件系统直接访问 | 在分片库手动执行或通过应用导入 |
SELECT ... INTO OUTFILE |
同上 | 应用层处理导出 |
-
- MySQL 特有功能
功能 | 支持情况 | 建议 |
---|---|---|
MySQL 8.0 公共表表达式(CTE) | 部分支持 | 避免跨分片使用 |
窗口函数(OVER() PARTITION BY ) |
部分支持 | 避免跨分片大数据量使用 |
JSON 函数 | 基本支持 | 单表场景可用,跨分片需谨慎 |
-
分布式事务
场景 | 问题原因 | 建议处理方式 |
---|---|---|
跨分片原生事务 | MySQL 原生事务不支持跨库 | 使用 ShardingSphere XA / BASE |
大事务 + 分布式事务 | 性能开销大 | 尽量控制事务范围 |