网站核验单 没有网站 怎么办,深圳网站公司注册,网站seo诊断的主要内容,莘庄网站建设1 为什么要有服务端分库分表#xff1f; ShardingSphere-Proxy 是 ShardingSphere 提供的服务端分库分表工具#xff0c;定位是“透明化的数据库代理”。 它模拟 MySQL 或 PostgreSQL 的数据库服务#xff0c;应用程序#xff08;Application#xff09;只需像访问单个数据…1 为什么要有服务端分库分表 ShardingSphere-Proxy 是 ShardingSphere 提供的服务端分库分表工具定位是“透明化的数据库代理”。 它模拟 MySQL 或 PostgreSQL 的数据库服务应用程序Application只需像访问单个数据库一样访问 ShardingSphere-Proxy 实际的分库分表逻辑由 ShardingSphere-Proxy 在代理层完成对应用程序完全透明 ShardingSphere-JDBC 已经能实现分库分表为什么还需要 ShardingSphere-Proxy 对 ORM 框架更友好 ShardingSphere-JDBC 的问题需要在业务代码中直接写分库分表逻辑比如代码里写数据该路由到哪个库/表。如果项目用了 ORM 框架如 MyBatis、Hibernate这种代码侵入式的逻辑容易和 ORM 冲突 ShardingSphere-Proxy 的解决作为第三方服务端代理分库分表逻辑在代理层ShardingSphere-Proxy处理应用程序完全不用关心。应用只需按访问单库的方式写代码无缝对接 ORM 框架 对 DBA数据库管理员更友好 ShardingSphere-JDBC 的问题DBA 要管理分库分表后的数据库得先了解 ShardingSphere 的专属功能和 API学习成本高; ShardingSphere-Proxy 的解决对 DBA 完全透明。DBA 可以直接操作原始数据库像平时管理 MySQL/PostgreSQL 一样无需了解 ShardingSphere 的技术细节简化了 DBA 的工作 避免业务代码侵入分库分表逻辑 ShardingSphere-JDBC 的问题分库分表的规则配置比如“按用户 ID 分库”的规则要写在业务代码里会让业务代码变得臃肿。如果规则变更比如从“按用户 ID 分”改成“按订单 ID 分”要修改大量业务代码维护成本高 ShardingSphere-Proxy 的解决通过外部配置文件管理分库分表规则业务代码完全不用关心这些逻辑。规则变更时只需改配置不影响业务代码 实现“无中心化”数据治理 ShardingSphere-JDBC 的局限多数据源的治理比如跨库监控、报警、统一管理难以统一 ShardingSphere-Proxy 的解决多个数据源可以注册到同一个 ShardingSphere-Proxy 代理服务中。基于代理能实现跨数据源的数据治理比如统一监控、报警、数据管理特别适合大规模微服务系统的运维。
2 基本使用
2.1 部署 ShardingSphere-Proxy 下载并解压注意不要有中文此处选择的版本Apache Archive Distribution Directory ShardingSphere-Proxy 是一个典型的 Java 应用程序解压后目录结构如下 解压完成后如果要连接 MySQL 数据库那么需要手动将 JDBC 的驱动包mysql-connector-java-8.0.20.jar复制到 ShardingSphere-Proxy 的lib目录下ShardingSphere-Proxy 默认只附带了 PostgreSQL 的 JDBC 驱动包没有包含 MySQL 的 JDBC 驱动包 打开conf目录在这个目录下就有 ShardingSphere-Proxy 的所有配置文件不同版本的会不一样 打开server.yaml把其中的rules部分和props部分的注释取消 rules:# 权限控制规则配置- !AUTHORITYusers:# 定义用户权限root用户可从任何主机(%)访问拥有root角色sharding用户可从任何主机访问拥有sharding角色- root%:root- sharding:shardingprovider:# 权限提供者类型ALL_PERMITTED表示允许所有操作无权限限制type: ALL_PERMITTED# 事务管理配置- !TRANSACTION# 默认事务类型XA分布式事务defaultType: XA# 事务管理器提供者Atomikos一种XA事务管理器实现providerType: Atomikos# SQL解析器配置- !SQL_PARSER# 启用SQL注释解析功能sqlCommentParseEnabled: truesqlStatementCache:# SQL语句缓存初始容量initialCapacity: 2000# SQL语句缓存最大容量maximumSize: 65535parseTreeCache:# 解析树缓存初始容量initialCapacity: 128# 解析树缓存最大容量maximumSize: 1024# 属性配置
props:# 每个查询允许的最大连接数max-connections-size-per-query: 1# 内核线程池大小默认无限制kernel-executor-size: 16# 代理前端刷新阈值网络数据包刷新条件proxy-frontend-flush-threshold: 128# 是否启用Hint功能强制路由提示proxy-hint-enabled: false# 是否在日志中显示SQL语句sql-show: false# 是否启用表元数据一致性检查check-table-metadata-enabled: false# 代理后端查询获取大小-1表示使用不同JDBC驱动程序的最小值proxy-backend-query-fetch-size: -1# 代理前端执行线程数0表示由Netty自动决定proxy-frontend-executor-size: # 代理后端执行模式OLAP联机分析处理或OLTP联机事务处理proxy-backend-executor-suitable: OLAP# 代理前端最大连接数0或负数表示无限制proxy-frontend-max-connections: 0# SQL联邦查询类型NONE禁用ORIGINAL原始ADVANCED高级sql-federation-type: NONE# 代理后端驱动类型JDBC标准或ExperimentalVertx实验性Vert.xproxy-backend-driver-type: JDBC# 默认MySQL版本号当缺少schema信息时使用proxy-mysql-default-version: 8.0.20# 代理服务默认端口proxy-default-port: 3307# Netty网络连接后备队列长度proxy-netty-backlog: 1024注意为了与 MySQL JDBC 的驱动包mysql-connector-java-8.0.20.jar兼容将proxy-mysql-default-version修改为8.0.20 启动 然后就可以使用 MySQL 的客户端比如 DataGrip去连接 ShardingSphere-Proxy 了且可以像用 MySQL 一样去使用 ShardingSphere-Proxy mysql show databases;
--------------------
| schema_name |
--------------------
| shardingsphere |
| information_schema |
| performance_schema |
| mysql |
| sys |
--------------------
5 rows in set (0.01 sec)mysql use shardingsphere
Database changed
mysql show tables;
---------------------------------------
| Tables_in_shardingsphere | Table_type |
---------------------------------------
| sharding_table_statistics | BASE TABLE |
---------------------------------------
1 row in set (0.01 sec)mysql select * from sharding_table_statistics;
Empty set (1.25 sec)不过要注意此时 ShardingSphere-Proxy 只是一个虚拟库所以并不能像 MySQL 一样去随意建表或修改数据比如下面就建表失败 mysql CREATE TABLE test (id varchar(255) NOT NULL);
Query OK, 0 rows affected (0.00 sec)mysql select * from test;
30000 - Unknown exception: At line 0, column 0: Object test not found
mysql show tables;
---------------------------------------
| Tables_in_shardingsphere | Table_type |
---------------------------------------
| sharding_table_statistics | BASE TABLE |
---------------------------------------
1 row in set (0.01 sec)2.2 常用的分库分表配置策略 打开config-sharding.yaml配置逻辑表course # 逻辑数据库名称客户端连接时使用的虚拟数据库名
databaseName: sharding_db# 数据源配置定义实际的后端数据库连接
dataSources:# 第一个数据源命名为m0m0:# MySQL数据库连接URL指向192.168.65.212服务器的3306端口数据库名为shardingdb1url: jdbc:mysql://192.168.65.212:3306/shardingdb1?serverTimezoneUTCuseSSLfalseusername: rootpassword: root# 连接超时时间毫秒connectionTimeoutMilliseconds: 30000# 连接空闲超时时间毫秒idleTimeoutMilliseconds: 60000# 连接最大生命周期毫秒maxLifetimeMilliseconds: 1800000# 连接池最大大小maxPoolSize: 50# 连接池最小大小minPoolSize: 1# 第二个数据源命名为m1m1:url: jdbc:mysql://192.168.65.212:3306/shardingdb2?serverTimezoneUTCuseSSLfalseusername: rootpassword: rootconnectionTimeoutMilliseconds: 30000idleTimeoutMilliseconds: 60000maxLifetimeMilliseconds: 1800000maxPoolSize: 50minPoolSize: 1# 分片规则配置
rules:
- !SHARDING # 分片规则标识tables:# 配置course表的分片规则course:# 实际数据节点分布在m0和m1数据库的course_1和course_2表中actualDataNodes: m${0..1}.course_${1..2}# 数据库分片策略databaseStrategy:standard: # 标准分片策略shardingColumn: cid # 分片列根据此字段的值决定数据路由到哪个数据库shardingAlgorithmName: course_db_alg # 使用的分片算法名称# 表分片策略tableStrategy:standard: # 标准分片策略shardingColumn: cid # 分片列根据此字段的值决定数据路由到哪个表shardingAlgorithmName: course_tbl_alg # 使用的分片算法名称# 主键生成策略keyGenerateStrategy:column: cid # 需要生成主键的列名keyGeneratorName: alg_snowflake # 使用的主键生成器名称# 分片算法定义shardingAlgorithms:# 数据库分片算法取模算法course_db_alg:type: MOD # 取模分片算法props:sharding-count: 2 # 分片数量2个数据库# 表分片算法行表达式算法course_tbl_alg:type: INLINE # 行表达式分片算法props:# 算法表达式根据cid字段的值取模2再加1得到表后缀(1或2)algorithm-expression: course_${cid%21}# 主键生成器定义keyGenerators:# 雪花算法生成器用于生成分布式唯一IDalg_snowflake:type: SNOWFLAKE # 使用雪花算法重新启动 ShardingSphere-Proxy 服务 mysql show databases;
--------------------
| schema_name |
--------------------
| information_schema |
| performance_schema |
| sys |
| shardingsphere |
| sharding_db |
| mysql |
--------------------
6 rows in set (0.02 sec)mysql use sharding_db;
Database changed
mysql show tables;
-----------------------------------
| Tables_in_sharding_db | Table_type |
-----------------------------------
| course | BASE TABLE |
| user_2 | BASE TABLE |
| user | BASE TABLE |
| user_1 | BASE TABLE |
-----------------------------------
4 rows in set (0.02 sec)mysql select * from course;
----------------------------------------------
| cid | cname | user_id | cstatus |
----------------------------------------------
| 1017125767709982720 | java | 1001 | 1 |
| 1017125769383510016 | java | 1001 | 1 |mysql select * from course_1;
----------------------------------------------
| cid | cname | user_id | cstatus |
----------------------------------------------
| 1017125767709982720 | java | 1001 | 1 |
| 1017125769383510016 | java | 1001 | 1 |可以看到多了一个sharding_db库。
3 ShardingSphere-Proxy 中的分布式事务机制
3.1 为什么需要分布式事务 XA 事务 :: ShardingSphere 在2.1 部署 ShardingSphere-Proxy中配置server.yaml时有一个TRANSACTION配置项 rules:
- !TRANSACTIONdefaultType: XAproviderType: Atomikos为什么 ShardingSphere-Proxy 需要分布式事务 ShardingSphere尤其是 ShardingSphere-Proxy要操作分布式的数据库集群多个库、多个节点。而数据库的本地事务只能保证单个数据库内的事务安全无法覆盖跨多个数据库的场景 因此必须引入分布式事务管理机制才能保证 ShardingSphere-Proxy 中 SQL 执行的原子性。开启分布式事务后开发者不用再手动考虑跨库 SQL 的事务问题。
3.2 什么是 XA 事务 XA 是由 X/Open Group 组织定义的分布式事务标准主流关系型数据库如 MySQL、Oracle 等都实现了 XA 协议比如 MySQL 5.0.3 的 InnoDB 引擎支持 XA XA 事务的核心是两阶段提交2PC通过**准备Prepare和提交Commit**两个阶段保证跨多个数据库的事务一致性 XA 分布式事务操作示例 -- 1. 开启XA事务test是事务标识符(XID)将事务状态设置为ACTIVE(活跃)
-- 事务标识符用于在分布式环境中唯一标识一个事务
XA START test;-- 2. 在ACTIVE状态的XA事务中执行业务SQL语句
-- 这些操作是事务的一部分但尚未最终提交
INSERT INTO dict VALUES(1, t, test);-- 3. 结束XA事务将事务状态从ACTIVE改为IDLE(空闲)
-- 表示事务内的所有操作已完成准备进入准备阶段
XA END test;-- 4. 准备提交事务将事务状态从IDLE改为PREPARED(已准备)
-- 此阶段事务管理器会确保所有资源管理器都已准备好提交
XA PREPARE test;-- 5. 列出所有处于PREPARED状态的XA事务
-- 返回的信息包含gtrid(全局事务ID)、bqual(分支限定符)、formatID(格式ID)和data(数据)
XA RECOVER;-- 6. 提交已准备的XA事务使所有更改永久生效
-- 这是两阶段提交的第二阶段(提交阶段)
XA COMMIT test;-- 6. 替代方案回滚已准备的XA事务撤销所有更改
-- 在PREPARED状态下也可以选择回滚而不是提交
XA ROLLBACK test;-- 注意也可以使用单条命令直接提交将预备和提交合并操作
-- XA COMMIT test ONE PHASE;ShardingSphere 集成了多个 XA 实现框架Atomikos、Bitronix、Narayana。在 ShardingSphere-Proxy 中默认只集成了 Atomikos所以配置里 providerType: Atomikos。
3.3 实战理解 XA 事务 引入 Maven 依赖 dependencygroupIdorg.apache.shardingsphere/groupIdartifactIdshardingsphere-transaction-xa-core/artifactIdversion5.2.1/versionexclusionsexclusionartifactIdtransactions-jdbc/artifactIdgroupIdcom.atomikos/groupId/exclusionexclusionartifactIdtransactions-jta/artifactIdgroupIdcom.atomikos/groupId/exclusion/exclusions
/dependency
!-- 版本滞后了 --
dependencyartifactIdtransactions-jdbc/artifactIdgroupIdcom.atomikos/groupIdversion5.0.8/version
/dependency
dependencyartifactIdtransactions-jta/artifactIdgroupIdcom.atomikos/groupIdversion5.0.8/version
/dependency
!-- 使用XA事务时可以引入其他几种事务管理器 --
!-- dependency--
!-- groupIdorg.apache.shardingsphere/groupId--
!-- artifactIdshardingsphere-transaction-xa-bitronix/artifactId--
!-- version5.2.1/version--
!-- /dependency--
!-- dependency--
!-- groupIdorg.apache.shardingsphere/groupId--
!-- artifactIdshardingsphere-transaction-xa-narayana/artifactId--
!-- version5.2.1/version--
!-- /dependency--配置事务管理器 Configuration
EnableTransactionManagement
public class TransactionConfiguration {Beanpublic PlatformTransactionManager txManager(final DataSource dataSource) {return new DataSourceTransactionManager(dataSource);}
}测试案例 public class MySQLXAConnectionTest {public static void main(String[] args) throws SQLException {// 是否打印XA相关命令用于调试目的boolean logXaCommands true;// 初始化阶段建立数据库连接 // 获取第一个数据库连接资源管理器RM1Connection conn1 DriverManager.getConnection(jdbc:mysql://localhost:3306/coursedb?serverTimezoneUTC, root, root);// 创建XA连接包装器用于支持分布式事务XAConnection xaConn1 new MysqlXAConnection((com.mysql.cj.jdbc.JdbcConnection) conn1, logXaCommands);// 获取XA资源接口用于控制分布式事务XAResource rm1 xaConn1.getXAResource();// 获取第二个数据库连接资源管理器RM2Connection conn2 DriverManager.getConnection(jdbc:mysql://localhost:3306/coursedb2?serverTimezoneUTC, root, root);// 创建第二个XA连接包装器XAConnection xaConn2 new MysqlXAConnection((com.mysql.cj.jdbc.JdbcConnection) conn2, logXaCommands);// 获取第二个XA资源接口XAResource rm2 xaConn2.getXAResource();// 生成全局事务IDGTrid是全局事务标识符在整个事务生命周期中唯一byte[] gtrid g12345.getBytes();int formatId 1; // 格式标识符通常为1表示标准XID格式try {// 分别执行RM1和RM2上的事务分支 // 为第一个资源管理器生成分支事务IDBQualbyte[] bqual1 b00001.getBytes();// 创建完整的事务IDXID包含全局ID和分支IDXid xid1 new MysqlXid(gtrid, bqual1, formatId);// 开始第一个分支事务TMNOFLAGS表示新建一个事务不是加入或恢复现有事务rm1.start(xid1, XAResource.TMNOFLAGS);// 在第一个分支事务中执行SQL操作PreparedStatement ps1 conn1.prepareStatement(INSERT INTO dict VALUES (1, T, 测试1););ps1.execute();// 结束第一个分支事务TMSUCCESS表示事务执行成功rm1.end(xid1, XAResource.TMSUCCESS);// 为第二个资源管理器生成分支事务IDbyte[] bqual2 b00002.getBytes();// 创建第二个事务IDXid xid2 new MysqlXid(gtrid, bqual2, formatId);// 开始第二个分支事务rm2.start(xid2, XAResource.TMNOFLAGS);// 在第二个分支事务中执行SQL操作PreparedStatement ps2 conn2.prepareStatement(INSERT INTO dict VALUES (2, F, 测试2););ps2.execute();// 结束第二个分支事务rm2.end(xid2, XAResource.TMSUCCESS);// 两阶段提交流程 // 第一阶段准备阶段 - 询问所有资源管理器是否准备好提交事务int rm1_prepare rm1.prepare(xid1);int rm2_prepare rm2.prepare(xid2);// 第二阶段提交阶段 - 根据准备阶段的结果决定提交或回滚boolean onePhase false; // 设置为false表示使用标准的两阶段提交// 检查所有资源管理器是否都准备成功if (rm1_prepare XAResource.XA_OK rm2_prepare XAResource.XA_OK) {// 所有分支都准备成功提交所有事务rm1.commit(xid1, onePhase);rm2.commit(xid2, onePhase);} else {// 如果有任何一个分支准备失败回滚所有事务rm1.rollback(xid1);rm2.rollback(xid2);}} catch (XAException e) {// 处理XA异常打印异常信息e.printStackTrace();}}
}XA标准规范了事务XID的格式它由三个部分组成gtrid [, bqual [, formatID ]]具体含义如下 gtrid全局事务标识符 global transaction identifier是用于标识一个全局事务的唯一值 。在分布式事务场景下多个数据库节点参与同一个事务通过这个全局事务标识符可以将这些操作关联到一起明确它们属于同一个事务比如在一个涉及电商系统多个数据库订单库、库存库、支付库的分布式事务中通过相同的gtrid就能确认这些数据库上的操作都属于同一次购物流程对应的事务 bqual分支限定符 branch qualifier 用来进一步限定事务分支。如果没有提供会使用默认值即一个空字符串例如在一个分布式事务中有多个数据库节点每个节点上的操作可以看作事务的一个分支bqual 就可以用来区分和标识这些不同的分支以便更精确地管理事务在各个节点上的执行情况 formatID格式标识符 是一个数字用于标记gtrid和bqual值的格式是一个正整数最小为0默认值是1 它主要用于在不同的系统或数据库之间进行交互时明确全局事务标识符和分支限定符的格式规则以确保各方能够正确解析和处理事务标识信息。 使用XA事务时的注意事项 无法自动提交与本地事务在满足一定条件下可以自动提交不同XA事务需要开发者显式地调用提交指令如XA COMMIT 。这就要求开发者在编写代码时要准确把控事务提交的时机避免因疏忽未提交事务而导致数据不一致等问题。例如在编写一个涉及多个数据库操作的业务逻辑时开发者需要在所有操作都成功执行后手动调用提交语句来完成事务否则事务会一直处于未提交状态 效率低下XA事务执行效率远低于本地事务通常耗时能达到本地事务的10倍。这是因为在XA事务中全局事务的状态都需要持久化涉及到多个数据库节点之间的协调和通信比如在两阶段提交过程中准备阶段各个节点要记录事务状态等信息提交阶段又需要进行多次确认和交互这些额外的操作增加了系统开销降低了事务处理的速度。这就意味着在对性能要求极高的场景中使用XA事务可能并不合适需要谨慎评估 故障隔离困难在XA事务提交前如果出现故障如某个数据库节点宕机、网络中断等很难将问题隔离开 。由于XA事务涉及多个数据库节点的协同工作一个节点出现故障可能会影响到整个事务的执行而且故障排查和恢复相对复杂。例如在一个跨地域的分布式数据库系统中如果某个地区的数据库节点在XA事务准备阶段出现故障不仅要处理该节点自身的数据恢复问题还要协调其他节点来处理事务状态以保证整个系统的数据一致性。
3.4 如何在 ShardingSphere-Proxy 中使用其他事务管理器 ShardingSphere-Proxy 支持多种分布式事务管理器如 Atomikos、Narayana、Bitronix。默认集成的是 Atomikos若要改用其它两种事务管理器需手动配置 具体操作以 Narayana 为例 添加 Narayana 的依赖包 将 Narayana 事务集成的 Jar 包如 shardingsphere-transaction-xa-narayana-5.2.1.jar放到 ShardingSphere-Proxy 的 lib 目录下该 Jar 包可通过 Maven 依赖下载需要在项目的 Maven 配置中引入对应依赖构建后获取 Jar 包 在 server.yaml 的 rules 部分将事务的 providerType 配置为 Narayana。配置示例 rules:- !TRANSACTIONdefaultType: XAproviderType: Narayana注意事项ShardingSphere 版本更新快部分依赖可能未及时维护存在组件版本冲突的风险。使用前需确认依赖包与 ShardingSphere-Proxy 版本的兼容性。
4 ShardingSphere-Proxy 集群化部署
4.1 ShardingSphere-Proxy 的运行模式 在 server.yaml 文件中有一段被注释的 mode 配置。这段配置的作用是指定 ShardingSphere 的运行模式决定 ShardingSphere 如何管理复杂的配置信息 #mode:
# type: Cluster
# repository:
# type: ZooKeeper
# props:
# namespace: governance_ds
# server-lists: localhost:2181
# retryIntervalMilliseconds: 500
# timeToLiveSeconds: 60
# maxRetries: 3
# operationTimeoutMilliseconds: 500ShardingSphere 支持 Standalone独立模式 和 Cluster集群模式 两种运行模式核心差异如下 Standalone独立模式 ShardingSphere 不需要考虑其他实例的影响直接在内存中管理核心配置规则 是 ShardingSphere 默认的运行模式配置简单无需依赖第三方组件。 适用场景小型项目或对性能要求较高的场景因为没有额外的配置同步开销。通常配合 ShardingJDBC 使用ShardingJDBC 是客户端分库分表更侧重性能 Cluster集群模式 ShardingSphere 不仅要管理自身配置还要与集群中其他实例同步配置规则。因此需要引入第三方配置中心如 Zookeeper、etcd、Nacos 等来实现配置同步 推荐的配置中心在分库分表场景下配置信息变动少、访问频率低因此基于 CP 架构的 Zookeeper 最推荐CP 架构保证数据一致性适合配置这类强一致需求的场景 优先级如果应用本地和 Zookeeper 都有配置ShardingSphere 以 Zookeeper 中的配置为准保证集群配置统一 适用场景大规模集群环境需要多实例协同工作通常配合 ShardingSphere-Proxy 使用 模式选择建议 Standalone小型项目、性能敏感场景 → 配合 ShardingJDBC Cluster大规模集群环境 → 配合 ShardingSphere-Proxy且推荐用 Zookeeper 作为配置中心。
4.2 使用 Zookeeper 进行集群部署 接下来基于 Zookeeper 部署一下 ShardingSphere-Proxy 集群 首先在本地部署一个 Zookeeper然后将server.yaml中的mode部分解除注释 # ShardingSphere 运行模式配置
mode:# 运行模式类型Cluster 表示集群模式支持多个Proxy实例组成集群type: Cluster# 集群元数据存储仓库配置repository:# 仓库类型ZooKeeper使用ZooKeeper作为分布式协调服务type: ZooKeeper# ZooKeeper连接配置属性props:# ZooKeeper命名空间用于在ZooKeeper中隔离不同环境的配置namespace: governance_ds# ZooKeeper服务器地址列表支持多个服务器地址用逗号分隔server-lists: 192.168.65.212:2181# 重试间隔时间毫秒连接失败后重试的等待时间retryIntervalMilliseconds: 500# 节点存活时间秒在ZooKeeper中创建的临时节点的存活时间timeToLiveSeconds: 60# 最大重试次数连接ZooKeeper失败时的最大重试次数maxRetries: 3# 操作超时时间毫秒ZooKeeper操作如创建、读取节点的超时时间operationTimeoutMilliseconds: 500启动 ShardingSphere-Proxy 服务在 Zookeeper 注册中心可以看到 ShardingSphere 集群模式下的节点结构如下 # ShardingSphere 集群模式下的 ZooKeeper 节点结构详解# 根命名空间用于环境隔离避免不同环境配置相互干扰
namespace: governance_ds
# 全局配置节点
├── rules # 存储全局规则配置如分片规则、加密规则等
├── props # 存储全局属性配置如SQL显示开关、执行模式等
# 元数据管理节点
├── metadata # 元数据配置根目录
│ ├── ${databaseName} # 逻辑数据库名称如sharding_db
│ │ ├── schemas # 逻辑Schema列表
│ │ │ ├── ${schemaName} # 逻辑Schema名称
│ │ │ │ ├── tables # 表结构配置
│ │ │ │ │ ├── ${tableName} # 具体表的结构定义
│ │ │ │ │ └── ... # 其他表
│ │ │ │ └── views # 视图结构配置
│ │ │ │ ├── ${viewName} # 具体视图的定义
│ │ │ │ └── ... # 其他视图
│ │ │ └── ... # 其他Schema
│ │ └── versions # 元数据版本管理
│ │ ├── ${versionNumber} # 具体版本号如v1, v2
│ │ │ ├── dataSources # 该版本的数据源配置
│ │ │ └── rules # 该版本的规则配置
│ │ ├── active_version # 当前激活的元数据版本号
│ │ └── ... # 其他版本
# 计算节点管理Proxy和JDBC实例管理
├── nodes
│ ├── compute_nodes # 计算节点管理根目录
│ │ ├── online # 在线实例列表
│ │ │ ├── proxy # Proxy模式实例
│ │ │ │ ├── UUID # 每个Proxy实例的唯一标识如生成的实际UUID
│ │ │ │ └── ... # 其他Proxy实例
│ │ │ └── jdbc # JDBC模式实例
│ │ │ ├── UUID # 每个JDBC实例的唯一标识
│ │ │ └── ... # 其他JDBC实例
│ │ ├── status # 实例状态信息
│ │ │ ├── UUID # 具体实例的状态数据
│ │ │ └── ... # 其他实例状态
│ │ ├── worker_id # 工作节点ID分配
│ │ │ ├── UUID # 实例分配的工作ID
│ │ │ └── ... # 其他实例的工作ID
│ │ ├── process_trigger # 进程触发管理
│ │ │ ├── process_list_id:UUID # 进程列表与实例的关联
│ │ │ └── ... # 其他进程触发信息
│ │ └── labels # 实例标签管理
│ │ ├── UUID # 具体实例的标签配置
│ │ └── ... # 其他实例标签
# 存储节点管理实际数据源管理
│ └── storage_nodes # 存储节点管理根目录
│ ├── ${databaseName.groupName.ds} # 数据源节点命名格式逻辑库名.组名.数据源名
│ └── ${databaseName.groupName.ds} # 另一个数据源节点server.yaml中的rules部分同2.1 部署 ShardingSphere-Proxy 分库分表配置同2.2 常用的分库分表配置策略。
4.3 统一 JDBC 和 Proxy 配置信息
ShardingSphere-JDBC 也能像 ShardingSphere-Proxy 一样通过 Zookeeper 同步配置信息从而实现两者配置的统一管理减少配置分散便于集群化维护。
4.3.1 通过注册中心同步配置 在 application.properties 中删除之前 ShardingSphere-JDBC 相关的分库分表规则等配置只配置Zookeeper 的连接和集群模式。示例配置 # 指定运行模式为“集群模式Cluster”
spring.shardingsphere.mode.typeCluster
# 指定配置中心类型为 Zookeeper
spring.shardingsphere.mode.repository.typeZookeeper
# Zookeeper 的命名空间用于隔离不同配置自定义即可
spring.shardingsphere.mode.repository.props.namespacegovernance_ds
# Zookeeper 的地址和端口
spring.shardingsphere.mode.repository.props.server-listslocalhost:2181
# 重试间隔毫秒
spring.shardingsphere.mode.repository.props.retryIntervalMilliseconds600
# 存活时间秒
spring.shardingsphere.mode.repository.props.timeToLiveSeconds60
# 最大重试次数
spring.shardingsphere.mode.repository.props.maxRetries3
# 操作超时时间毫秒
spring.shardingsphere.mode.repository.props.operationTimeoutMilliseconds500配置完成后可继续验证对表如 course 表的分库分表操作此时 ShardingSphere-JDBC 会从 Zookeeper 中拉取配置信息来执行分库分表逻辑 注意 如果在 ShardingSphere-JDBC 中读取配置中心Zookeeper的配置需要用 spring.shardingsphere.database.name 指定对应的虚拟库若不配置该参数默认值为 logic_db这个虚拟库是 ShardingSphere 中逻辑上的数据库概念用于统一管理分库分表后的逻辑结构。
4.3.2 使用ShardingSphere-Proxy提供的JDBC驱动读取配置文件 ShardingSphere 过去是通过兼容 MySQL 或 PostgreSQL 服务的方式提供分库分表功能 应用端需要用 MySQL/PostgreSQL 的 JDBC 驱动去访问 ShardingSphere 封装的数据源ShardingSphereDataSource 这种方式相当于模拟成 MySQL/PostgreSQL 数据库让应用无感知地使用分库分表能力但依赖的是第三方数据库的 JDBC 驱动 在当前版本中ShardingSphere 直接提供了自己的 JDBC 驱动 这意味着应用可以不再依赖 MySQL/PostgreSQL 的 JDBC 驱动直接用 ShardingSphere 专属的驱动来连接和操作数据 优势是更原生、更直接地支持 ShardingSphere 的特性分库分表、分布式事务等减少对第三方驱动的依赖也能更灵活地扩展功能 比如在 ShardingSphere-JDBC 中可在类路径classpath下增加 config.yaml 文件将之前 ShardingSphere-Proxy中的关键配置整合到这个文件中。这样 ShardingSphere-JDBC 就能通过自身的 JDBC 驱动读取 config.yaml 里的配置分库分表规则、数据源等实现和 ShardingSphere-Proxy 类似的分库分表逻辑 rules:- !AUTHORITYusers:- root%:root- sharding:shardingprovider:type: ALL_PERMITTED- !TRANSACTIONdefaultType: XAproviderType: Atomikos- !SQL_PARSERsqlCommentParseEnabled: truesqlStatementCache:initialCapacity: 2000maximumSize: 65535parseTreeCache:initialCapacity: 128maximumSize: 1024- !SHARDINGtables:course:actualDataNodes: m${0..1}.course_${1..2}databaseStrategy:standard:shardingColumn: cidshardingAlgorithmName: course_db_algtableStrategy:standard:shardingColumn: cidshardingAlgorithmName: course_tbl_algkeyGenerateStrategy:column: cidkeyGeneratorName: alg_snowflakeshardingAlgorithms:course_db_alg:type: MODprops:sharding-count: 2course_tbl_alg:type: INLINEprops:algorithm-expression: course_$-{cid%21}keyGenerators:alg_snowflake:type: SNOWFLAKEprops:max-connections-size-per-query: 1kernel-executor-size: 16proxy-frontend-flush-threshold: 128proxy-hint-enabled: falsesql-show: falsecheck-table-metadata-enabled: falseproxy-backend-query-fetch-size: -1proxy-frontend-executor-size: 0proxy-backend-executor-suitable: OLAPproxy-frontend-max-connections: 0 sql-federation-type: NONEproxy-backend-driver-type: JDBCproxy-mysql-default-version: 8.0.20proxy-default-port: 3307proxy-netty-backlog: 1024databaseName: sharding_db
dataSources:m0:dataSourceClassName: com.zaxxer.hikari.HikariDataSourceurl: jdbc:mysql://127.0.0.1:3306/coursedb?serverTimezoneUTCuseSSLfalseusername: rootpassword: rootconnectionTimeoutMilliseconds: 30000idleTimeoutMilliseconds: 60000maxLifetimeMilliseconds: 1800000maxPoolSize: 50minPoolSize: 1m1:dataSourceClassName: com.zaxxer.hikari.HikariDataSourceurl: jdbc:mysql://127.0.0.1:3306/coursedb2?serverTimezoneUTCuseSSLfalseusername: rootpassword: rootconnectionTimeoutMilliseconds: 30000idleTimeoutMilliseconds: 60000maxLifetimeMilliseconds: 1800000maxPoolSize: 50minPoolSize: 1然后可以直接用 JDBC 的方式访问带有分库分表的虚拟库 public class ShardingJDBCDriverTest {Testpublic void test() throws ClassNotFoundException, SQLException {// 定义ShardingSphere JDBC驱动类全限定名// 这是ShardingSphere提供的专用JDBC驱动用于拦截和路由SQL请求String jdbcDriver org.apache.shardingsphere.driver.ShardingSphereDriver;// JDBC连接URL指定使用ShardingSphere驱动和配置文件路径// classpath:config.yaml 表示配置文件位于类路径下的config.yaml文件String jdbcUrl jdbc:shardingsphere:classpath:config.yaml;// 要执行的SQL查询语句// 这里查询的是逻辑数据库sharding_db中的course表// ShardingSphere会根据配置将查询路由到实际的物理表String sql select * from sharding_db.course;// 加载ShardingSphere JDBC驱动类// 这是使用JDBC驱动的标准方式驱动会自动注册到DriverManagerClass.forName(jdbcDriver);// 使用try-with-resources语句确保连接正确关闭try(Connection connection DriverManager.getConnection(jdbcUrl);) {// 创建Statement对象用于执行SQL语句Statement statement connection.createStatement();// 执行SQL查询并返回ResultSet结果集// ShardingSphere会在此处拦截SQL根据分片规则路由到正确的数据节点ResultSet resultSet statement.executeQuery(sql);// 遍历结果集处理查询结果while (resultSet.next()){// 从结果集中获取cid字段的值并输出// ShardingSphere会自动合并来自多个分片的结果System.out.println(course cid resultSet.getLong(cid));}// try-with-resources会自动关闭statement和resultSet}// try-with-resources会自动关闭connection释放数据库连接资源}
}官方的说明是 ShardingSphereDriver 读取config.yaml时 这个config.yaml配置信息与 ShardingSphere-Proxy 中的配置文件完全是相同的甚至可以直接将 ShardingSphere-Proxy 中的配置文件拿过来用。但是从目前版本来看还是有不少小问题的静待后续版本跟踪吧 到这里对于之前讲解过的 ShardingSphere 的混合架构有没有更新的了解
5 ShardingSphere-Proxy功能扩展 ShardingSphere-Proxy 支持通过 SPIService Provider Interface机制 进行自定义扩展只要将自定义的扩展功能如自定义算法、策略等按照 SPI 规范打成 Jar 包放入 ShardingSphere-Proxy 的 lib 目录就能被 ShardingSphere-Proxy 加载并使用 以自定义主键生成器为例 实现 KeyGeneratorAlgorithm 接口用于生成自定义格式的主键生成主键时结合当前时间戳格式化为 yyyyMMddHHmmssSSS和自增原子变量保证主键的唯一性和有序性 public class MyKeyGeneratorAlgorithm implements KeyGeneratorAlgorithm {private AtomicLong atom new AtomicLong(0);private Properties props;Overridepublic Comparable? generateKey() {LocalDateTime ldt LocalDateTime.now();// 格式化时间为 “年月日时分秒毫秒” 格式String timestamp DateTimeFormatter.ofPattern(yyyyMMddHHmmssSSS).format(ldt);// 结合自增数生成主键时间戳 自增数return Long.parseLong(timestamp atom.incrementAndGet());}Overridepublic Properties getProps() {return this.props;}Overridepublic String getType() {// 自定义算法的类型标识配置时会用到return MYKEY;}Overridepublic void init(Properties props) {this.props props;}
}要将自定义类和对应的 SPI 文件打成 Jar 包需在 pom.xml 中配置 maven-jar-plugin 指定要打包的自定义类com/your/package/algorithm/**和 SPI 配置文件META-INF/services/*生成包含扩展功能的 Jar 包 buildplugins!-- 将 SPI 扩展功能单独打成 Jar 包 --plugingroupIdorg.apache.maven.plugins/groupIdartifactIdmaven-jar-plugin/artifactIdversion3.2.0/versionexecutionsexecutionidshardingJDBDemo/idphasepackage/phasegoalsgoaljar/goal/goalsconfigurationclassifierspi-extention/classifierincludes!-- 包含自定义算法的包路径 --includecom/your/package/algorithm/**/include!-- 包含 SPI 配置文件META-INF/services/ 下的文件 --includeMETA-INF/services/*/include/includes/configuration/execution/executions/plugin/plugins
/build将打包好的 Jar 包放入 ShardingProxy 的 lib 目录。之后在 ShardingProxy 的配置中就可以像使用内置组件一样引用这个自定义的主键生成算法如配置 keyGeneratorName: MYKEY。
6 分库分表数据迁移方案 分库分表场景下数据迁移面临两大难题 海量数据迁移难度大旧项目无分库分表或需调整分片规则时数据量庞大迁移工程浩大 业务无感知难度高迁移过程中要保证业务正常运行不能因迁移导致服务中断 为平衡数据迁移和业务连续性在数据转移的过程中保证不影响业务正常进行采用冷热数据分离迁移 冷数据 即历史存量数据数据量大无法一次性迁移策略通过定时任务逐步迁移减少对业务的瞬间压力 热数据 即业务实时产生的新数据策略保证双写同时写入旧库和新库确保迁移过程中数据实时同步业务不受影响 基于 ShardingSphere 的迁移方案 热数据双写ShardingJDBC 数据双写库 核心逻辑用 ShardingSphereDataSource 替换旧的 DataSource配置双写规则核心业务表同时写入旧库和新库 实现方式在 ShardingJDBC 双写库中针对需迁移的核心表配置分片规则通过定制分片算法实现一份数据写两份库 新库分片写入ShardingJDBC 数据写入库 核心逻辑针对新数据库集群配置专门的 ShardingJDBC 写入库完整实现新的分片规则即分库分表的最终逻辑 关联方式将这个写入库配置到之前的双写库中保证新数据按新规则写入新库 冷数据增量迁移定时任务 ShardingProxy 冷数据特点量大、迁移慢需分批增量迁移 实现方式 用 ElasticJob 等定时任务框架分批读取旧库冷数据按新分片规则写入新库借助 ShardingProxy 服务简化新库的分片逻辑定时任务只需从旧库读、往新库写分片规则由 ShardingProxy 统一管理规则同步通过 ShardingSphere Governance Center如 Zookeeper保证 ShardingProxy 和 ShardingJDBC 写入库的分片规则一致 迁移完成后切换 核心逻辑冷数据迁移完成后删除双写库和旧库依赖只保留 ShardingJDBC 写入库新库的分片逻辑 业务影响应用层只需访问一个 DataSource底层由 ShardingSphere 切换为新库逻辑业务代码几乎无需修改 注意迁移过程中需梳理业务 SQL确保 SQL 符合 ShardingSphere尤其是 ShardingSphere-JDBC的支持范围避免使用不兼容的 SQL 语法导致迁移或业务异常。
