关于shardingsphere:Amazon-Aurora-读写能力扩展之-ShardingSphereJDBC-篇

文章起源亚马逊 AWS 官网博客

孙进华
亚马逊云科技资深解决方案架构师，负责帮忙客户进行上云架构的设计和征询。退出 AWS 前自主守业负责电商平台搭建和车企电商平台整体架构设计。曾就任于寰球当先的通讯设备公司，负责高级工程师，负责 LTE 设施零碎的多个子系统的开发与架构设计。在高并发、高可用零碎架构设计、微服务架构设计、数据库、中间件、IOT 等方面有着丰盛的教训。

1.前言

Amazon Aurora 是亚马逊云科技自研的一项关系数据库服务，它在提供和开源数据库 MySQL、PostgreSQL 的完整兼容性同时，也可能提供和商业数据库媲美的性能和可用性。性能方面，Aurora MySQL 可能反对到与开源规范 MySQL 等同配置下五倍的吞吐量，Aurora PostgreSQL 可能反对与开源规范 PostgreSQL 等同配置下三倍的吞吐量的晋升。在扩展性的角度，Aurora 在存储与计算、横向与纵向方面都进行了性能的加强和翻新。

Aurora 的最大数据存储量当初反对多达 128TB，而且能够反对存储的动静膨胀。计算方面，Aurora 提供多个读正本的可扩展性配置反对一个区域内多达 15 个读正本的扩大，提供多主的架构来反对同一个区域内 4 个写节点的扩大，提供 Serverless 无服务器化的架构实例级别的秒级纵向扩大，提供寰球数据库来实现数据库的低提早跨区域扩大。

随着用户数据量的增长，Aurora 曾经提供了很好的扩展性，那是否能够进一步加强更多的数据量、更多的并发拜访能力呢？您能够思考利用分库分表的形式，来反对底层多个 Aurora 集群的配置。基于此，蕴含这篇博客在内的系列博客会进行相应的介绍，旨在为您进行分库分表时代理或者 JDBC 的抉择提供参考。

1.1为什么要分库分表

AWS Aurora 提供了关系型数据库单机，主从，多主，寰球数据库等托管架构模式能够满足以上各种架构场景，但分库分表的场景下 Aurora 没有提供间接的反对，并且分库分表还衍生进去如垂直与程度多种状态,再进一步晋升数据容量的状况下，也带来一些须要解决的问题，如跨节点数据库 Join 关联查问、分布式事务、执行的 SQL 排序、翻页、函数计算、数据库全局主键、容量布局、分库分表后二次扩容等问题。

1.2分库分表的形式

查问一次所花的工夫业界公认 MySQL 单表容量在 1 千万以下是最佳状态，因为这时它的BTREE索引树高在 3~5 之间。通过对数据的切分能够在升高单表的数据量的同时，将读写的压力摊派到不同的数据节点上，数据切分能够分为：垂直切分和程度切分。

1.垂直切分的长处

解决业务零碎层面的耦合，业务清晰；

与微服务的治理相似，也能对不同业务的数据进行分级管理、保护、监控、扩大等；

高并发场景下，垂直切分肯定水平的晋升 IO、数据库连接数、单机硬件资源的瓶颈。

2.垂直切分的毛病

分库后无奈 Join，只能通过接口聚合形式解决，晋升了开发的复杂度；

分库后分布式事务处理简单；

仍然存在单表数据量过大的问题（须要程度切分）。

3.程度切分的长处

不存在单库数据量过大、高并发的性能瓶颈，晋升零碎稳定性和负载能力；

利用端革新较小，不须要拆分业务模块。

4.程度切分的毛病

跨分片的事务一致性难以保障；

跨库的 Join 关联查问性能较差；

数据屡次扩大难度和保护量极大。

联合以上剖析，在调研了常见的分库分表的中间件根底上，咱们选取 ShardingSphere 开源产品联合 Amazon Aurora，介绍这两种产品的联合是如何满足各种模式的分库分表形式和如何解决由分库分表带来的一些问题。

2.Sharding-JDBC 功能测试

2.1样例工程阐明

下载样例工程代码到本地，为保障测试代码的稳定性咱们这里抉择使 shardingsphere-example-4.0.0 这个 tag 版本。

git clone https://github.com/apache/shardingsphere-example.git

工程项目阐明：

shardingsphere-example  ├── example-core  │   ├── config-utility  │   ├── example-api  │   ├── example-raw-jdbc  │   ├── example-spring-jpa #spring+jpa集成根底的entity，repository  │   └── example-spring-mybatis  ├── sharding-jdbc-example  │   ├── sharding-example  │   │   ├── sharding-raw-jdbc-example  │   │   ├── sharding-spring-boot-jpa-example #集成根底的sharding-jdbc的性能  │   │   ├── sharding-spring-boot-mybatis-example  │   │   ├── sharding-spring-namespace-jpa-example  │   │   └── sharding-spring-namespace-mybatis-example  │   ├── orchestration-example  │   │   ├── orchestration-raw-jdbc-example  │   │   ├── orchestration-spring-boot-example #集成根底的sharding-jdbc的治理的性能  │   │   └── orchestration-spring-namespace-example  │   ├── transaction-example  │   │   ├── transaction-2pc-xa-example #sharding-jdbc分布式事务两阶段提交的样例  │   │   └──transaction-base-seata-example #sharding-jdbc分布式事务seata的样例  │   ├── other-feature-example  │   │   ├── hint-example  │   │   └── encrypt-example  ├── sharding-proxy-example  │   └── sharding-proxy-boot-mybatis-example  └── src/resources        └── manual_schema.sql 

配置文件阐明：

application-master-slave.properties #读写拆散配置文件application-sharding-databases-tables.properties #分库分表配置文件application-sharding-databases.properties       #仅分库配置文件application-sharding-master-slave.properties    #分库分表加读写拆散的配置文件application-sharding-tables.properties          #分表配置文件application.properties                         #spring boot 配置文件

代码逻辑阐明：

Spring Boot 利用的入口类，执行该类就能够运行工程

其中 demo 的执行逻辑如下：

2.2读写拆散验证

随着业务增长，写和读申请拆散到不同的数据库节点上可能无效进步整个数据库集群的解决能力。Aurora 通过读/写的 endpoint 能够满足用户写和强一致性读的需要，独自只读的 endpoint 能够满足用户非强一致性读的需要。Aurora 的读写提早通常在毫秒级别，比 MySQL 基于 binlog 的逻辑复制要低得多，所以有很多负载是间接打到只读 endpoint。

通过一主多从的配置形式，能够将查问申请平均的扩散到多个数据正本，可能进一步的晋升零碎的解决能力。读写拆散尽管能够晋升零碎的吞吐量和可用性，但同时也带来了数据不统一的问题。Aurora 以齐全托管的模式提供了主从架构，但下层利用在与 Aurora 交互时，依然须要治理多个数据源，依据 SQL 语句的读写类型和肯定的路由策略将 SQL 申请路由到不同的节点上。

Sharding-JDBC 提供的读写拆散的个性，应用程序与 Sharding-JDBC 集成，将应用程序与数据库集群之间简单配置关系从应用程序中剥离进去，开发者通过配置文件治理 Shard，再联合一些 ORM 框架如 Spring JPA、Mybatis 就能够齐全将这些复制的逻辑从代码中拆散。极大的进步代码的可维护性，升高代码与数据库的耦合。

2.2.1数据库环境筹备

首先创立一套 Aurora MySQL 读写拆散集群，机型为 db.r5.2xlarge，每套集群有一个写节点 2 个读节点。如下图所示

2.2.2Sharding-JDBC 配置

application.properties spring boot 主配置文件阐明

如下图所属：绿色标注的局部你须要替换成本人环境上的配置

# jpa主动依据实体创立和drop数据表spring.jpa.properties.hibernate.hbm2ddl.auto=create-dropspring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MySQL5Dialectspring.jpa.properties.hibernate.show_sql=true#spring.profiles.active=sharding-databases#spring.profiles.active=sharding-tables#spring.profiles.active=sharding-databases-tables#激活master-slave 配置项，这样sharding-jdbc将应用master-slave配置文件spring.profiles.active=master-slave#spring.profiles.active=sharding-master-slave

application-master-slave.properties sharding-jdbc 配置文件阐明

spring.shardingsphere.datasource.names=ds_master,ds_slave_0,ds_slave_1# 数据源 主库-masterspring.shardingsphere.datasource.ds_master.driver-class-name=com.mysql.jdbc.Driverspring.shardingsphere.datasource.ds_master.password= 您本人的主db明码spring.shardingsphere.datasource.ds_master.type=com.zaxxer.hikari.HikariDataSourcespring.shardingsphere.datasource.ds_master.jdbc-url=您本人的主db数据源url spring.shardingsphere.datasource.ds_master.username=您本人的主db用户名 # 数据源 从库spring.shardingsphere.datasource.ds_slave_0.driver-class-name=com.mysql.jdbc.Driverspring.shardingsphere.datasource.ds_slave_0.password= 您本人的从db明码spring.shardingsphere.datasource.ds_slave_0.type=com.zaxxer.hikari.HikariDataSourcespring.shardingsphere.datasource.ds_slave_0.jdbc-url=您本人的从db数据源urlspring.shardingsphere.datasource.ds_slave_0.username= 您本人的从db用户名# 数据源 从库spring.shardingsphere.datasource.ds_slave_1.driver-class-name=com.mysql.jdbc.Driverspring.shardingsphere.datasource.ds_slave_1.password=您本人的从db明码spring.shardingsphere.datasource.ds_slave_1.type=com.zaxxer.hikari.HikariDataSourcespring.shardingsphere.datasource.ds_slave_1.jdbc-url= 您本人的从db数据源urlspring.shardingsphere.datasource.ds_slave_1.username= 您本人的从db用户名# 路由策略配置spring.shardingsphere.masterslave.load-balance-algorithm-type=round_robinspring.shardingsphere.masterslave.name=ds_msspring.shardingsphere.masterslave.master-data-source-name=ds_masterspring.shardingsphere.masterslave.slave-data-source-names=ds_slave_0,ds_slave_1# sharding-jdbc 配置信息存储形式spring.shardingsphere.mode.type=Memory# 开启shardingsphere 日志，开启的状况下从打印中能够看到逻辑SQL到理论SQL的转换spring.shardingsphere.props.sql.show=true

2.2.3测试验证过程阐明

测试环境数据初始化：Spring JPA 初始化主动创立用于测试的表

• 在主实例上写入数据

如下图 ShardingSphere-SQL log 所示，写 SQL 在 ds_master 数据源上执行。

• 数据查问操作在从库上执行

如下图 ShardingSphere-SQL log 所示，读 SQL 依照轮询的形式在 ds_slave 数据源上执行。

[INFO ] 2022-04-02 19:43:39,376 --main-- [ShardingSphere-SQL] Rule Type: master-slave [INFO ] 2022-04-02 19:43:39,376 --main-- [ShardingSphere-SQL] SQL: select orderentit0_.order_id as order_id1_1_, orderentit0_.address_id as address_2_1_, orderentit0_.status as status3_1_, orderentit0_.user_id as user_id4_1_ from t_order orderentit0_ ::: DataSources: ds_slave_0 ---------------------------- Print OrderItem Data -------------------Hibernate: select orderiteme1_.order_item_id as order_it1_2_, orderiteme1_.order_id as order_id2_2_, orderiteme1_.status as status3_2_, orderiteme1_.user_id as user_id4_2_ from t_order orderentit0_ cross join t_order_item orderiteme1_ where orderentit0_.order_id=orderiteme1_.order_id[INFO ] 2022-04-02 19:43:40,898 --main-- [ShardingSphere-SQL] Rule Type: master-slave [INFO ] 2022-04-02 19:43:40,898 --main-- [ShardingSphere-SQL] SQL: select orderiteme1_.order_item_id as order_it1_2_, orderiteme1_.order_id as order_id2_2_, orderiteme1_.status as status3_2_, orderiteme1_.user_id as user_id4_2_ from t_order orderentit0_ cross join t_order_item orderiteme1_ where orderentit0_.order_id=orderiteme1_.order_id ::: DataSources: ds_slave_1 

留神：如下图所示，如果在一个事务中既有读也有写，Sharding-JDBC 将读写操作都路由到主库；如果读写申请不在一个事务中，那么对应读申请将依照路由策略散发到不同的读节点上。

@Override@Transactional // 开启事务时在该事务中读写都走主库；敞开事务时，读走从库，写走主库public void processSuccess() throws SQLException {    System.out.println("-------------- Process Success Begin ---------------");    List<Long> orderIds = insertData();    printData();    deleteData(orderIds);    printData();    System.out.println("-------------- Process Success Finish --------------");}

2.2.4Aurora failover 场景验证

Aurora 数据库环境采纳 2.2.1 中的配置。

2.2.4.1验证过程中阐明

1.启动 Spring-Boot 工程

2.在 Aurora 的 console 上执行故障转移操作

3.执行 Rest API 申请

4.屡次执行 POST （http://localhost:8088/save-user） 直到该 API 的调用写入 Aurora 失败到最终复原胜利。

5.观测执行代码 failover 过程如下图所示，从 log 能够剖析最近一次 SQL 执行写入操作胜利到下次执行再次写入胜利大略须要 37s，也就是利用从 Aurora failover 中能够主动复原，复原的时长大略是 37s。

2.3仅分表性能验证

2.3.1Sharding-JDBC 配置

application.properties spring boot 主配置文件阐明

# jpa 主动依据实体创立和drop数据表spring.jpa.properties.hibernate.hbm2ddl.auto=create-dropspring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MySQL5Dialectspring.jpa.properties.hibernate.show_sql=true#spring.profiles.active=sharding-databases#激活sharding-tables配置项#spring.profiles.active=sharding-tables#spring.profiles.active=sharding-databases-tables# spring.profiles.active=master-slave#spring.profiles.active=sharding-master-slave

application-sharding-tables.properties sharding-jdbc 配置文件阐明

## 主键策略配置spring.shardingsphere.sharding.tables.t_order.key-generator.column=order_idspring.shardingsphere.sharding.tables.t_order.key-generator.type=SNOWFLAKEspring.shardingsphere.sharding.tables.t_order.key-generator.props.worker.id=123spring.shardingsphere.sharding.tables.t_order_item.actual-data-nodes=ds.t_order_item_$->{0..1}spring.shardingsphere.sharding.tables.t_order_item.table-strategy.inline.sharding-column=order_idspring.shardingsphere.sharding.tables.t_order_item.table-strategy.inline.algorithm-expression=t_order_item_$->{order_id % 2}spring.shardingsphere.sharding.tables.t_order_item.key-generator.column=order_item_idspring.shardingsphere.sharding.tables.t_order_item.key-generator.type=SNOWFLAKEspring.shardingsphere.sharding.tables.t_order_item.key-generator.props.worker.id=123# 配置t_order与 t_order_item的绑定关系spring.shardingsphere.sharding.binding-tables[0]=t_order,t_order_item# 配置播送表spring.shardingsphere.sharding.broadcast-tables=t_address# sharding-jdbc的模式spring.shardingsphere.mode.type=Memory# 开启shardingsphere日志spring.shardingsphere.props.sql.show=true

2.3.2测试验证过程阐明

1.DDL 操作

如下图所属，JPA 主动创立用于测试的表，在配置了 Sharding-JDBC 的路由规定的状况下，client 端执行 DDL，Sharding-JDBC 会主动依据分表规定创立对应的表；如 t_address 是播送表，因为只有一个主实例，所以创立一个 t_address；t_order 依照取模分表，创立 t_order 时会创立 t_order_0, t_order_1 两张表物理表。

2.写操作

如下图所示 Logic SQL 向 t_order 插入一条记录，Sharding-JDBC 执行的时候会依据分表规定将数据分布放到 t_order_0, t_order_1 中。

当 t_order 和 t_order_item 配置了绑定关系时，order_item 与 order 有关联关系的记录会放到同一个物理分表中。

3.读操作

绑定表下的 join 查问操作 order 和 order_item，如下图所示，会依据绑定关系精确定位对应的物理 shard 上。

非绑定表下的 join 查问操作 order 和 order_item，如下图所属，会遍历所有的 shard。

2.4仅分库性能验证

2.4.1数据库环境筹备

如下图所属，在 Aurora 上创立两个实例：ds_0 和 ds_1

启动 Sharding-spring-boot-jpa-example 工程时会在两个 Aurora 实例上创立表 t_order, t_order_item，t_address

2.4.2Sharding-JDBC 配置

application.properties springboot 主配置文件阐明

# jpa 主动依据实体创立和drop数据表spring.jpa.properties.hibernate.hbm2ddl.auto=createspring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MySQL5Dialectspring.jpa.properties.hibernate.show_sql=true# 激活sharding-databases配置项spring.profiles.active=sharding-databases#spring.profiles.active=sharding-tables#spring.profiles.active=sharding-databases-tables#spring.profiles.active=master-slave#spring.profiles.active=sharding-master-slaveapplication-sharding-databases.properties sharding-jdbc 配置文件阐明spring.shardingsphere.datasource.names=ds_0,ds_1# ds_0spring.shardingsphere.datasource.ds_0.type=com.zaxxer.hikari.HikariDataSourcespring.shardingsphere.datasource.ds_0.driver-class-name=com.mysql.jdbc.Driverspring.shardingsphere.datasource.ds_0.jdbc-url= spring.shardingsphere.datasource.ds_0.username= spring.shardingsphere.datasource.ds_0.password=# ds_1spring.shardingsphere.datasource.ds_1.type=com.zaxxer.hikari.HikariDataSourcespring.shardingsphere.datasource.ds_1.driver-class-name=com.mysql.jdbc.Driverspring.shardingsphere.datasource.ds_1.jdbc-url= spring.shardingsphere.datasource.ds_1.username= spring.shardingsphere.datasource.ds_1.password=spring.shardingsphere.sharding.default-database-strategy.inline.sharding-column=user_idspring.shardingsphere.sharding.default-database-strategy.inline.algorithm-expression=ds_$->{user_id % 2}spring.shardingsphere.sharding.binding-tables=t_order,t_order_itemspring.shardingsphere.sharding.broadcast-tables=t_addressspring.shardingsphere.sharding.default-data-source-name=ds_0spring.shardingsphere.sharding.tables.t_order.actual-data-nodes=ds_$->{0..1}.t_orderspring.shardingsphere.sharding.tables.t_order.key-generator.column=order_idspring.shardingsphere.sharding.tables.t_order.key-generator.type=SNOWFLAKEspring.shardingsphere.sharding.tables.t_order.key-generator.props.worker.id=123spring.shardingsphere.sharding.tables.t_order_item.actual-data-nodes=ds_$->{0..1}.t_order_itemspring.shardingsphere.sharding.tables.t_order_item.key-generator.column=order_item_idspring.shardingsphere.sharding.tables.t_order_item.key-generator.type=SNOWFLAKEspring.shardingsphere.sharding.tables.t_order_item.key-generator.props.worker.id=123# sharding-jdbc的模式spring.shardingsphere.mode.type=Memory# 开启shardingsphere日志spring.shardingsphere.props.sql.show=true

2.4.3测试验证过程阐明

1.DDL 操作

JPA 主动创立用于测试的表，如下图所属，在配置了 Sharding-JDBC 的分库路由规定的状况下，client 端执行 DDL，Sharding-JDBC 会主动依据分表规定创立对应的表；如 t_address 是播送表在 ds_0 和 ds_1 上都会创立物理表 t_address，t_order，t_order_item 依照取模分库，这三个表会别离在 ds_0 和 ds_1 上创立。

2.写操作

对于播送表 t_address，每写入一条记录会在 ds_0 和 ds_1 的 t_address 表上都写入

对于分库的表 t_order，t_order_item，会依照分库字段和路由策略写入到对应实例上的表中。

3.读操作

如下图所示，查问 order，依据分库路由规定路由到对应的 Aurora 实例上。

如下图所示，查问 Address，因为 address 是播送表，会在所用的节点中随机抉择一个 address 所在的实例查问。

如下图所示，绑定表下的 join 查问操作 order 和 order_item 时，会依据绑定关系精确定位对应的物理 shard 上。

2.5分库分表性能验证

2.5.1数据库环境筹备

如下图所示，在 Aurora 上创立两个实例：ds_0和ds_1

启动 sharding-spring-boot-jpa-example 工程时会在两个 Aurora 实例上创立物理表 t_order_01, t_order_02, t_order_item_01，t_order_item_02 和 t_address 全局表。

2.5.2Sharding-JDBC 配置

application.properties springboot 主配置文件阐明

# jpa 主动依据实体创立和drop数据表spring.jpa.properties.hibernate.hbm2ddl.auto=createspring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MySQL5Dialectspring.jpa.properties.hibernate.show_sql=true# 激活sharding-databases-tables配置项#spring.profiles.active=sharding-databases#spring.profiles.active=sharding-tablesspring.profiles.active=sharding-databases-tables#spring.profiles.active=master-slave#spring.profiles.active=sharding-master-slave

application-sharding-databases.properties sharding-jdbc 配置文件阐明

spring.shardingsphere.datasource.names=ds_0,ds_1# ds_0spring.shardingsphere.datasource.ds_0.type=com.zaxxer.hikari.HikariDataSourcespring.shardingsphere.datasource.ds_0.driver-class-name=com.mysql.jdbc.Driverspring.shardingsphere.datasource.ds_0.jdbc-url= 306/dev?useSSL=false&characterEncoding=utf-8spring.shardingsphere.datasource.ds_0.username= spring.shardingsphere.datasource.ds_0.password=spring.shardingsphere.datasource.ds_0.max-active=16# ds_1spring.shardingsphere.datasource.ds_1.type=com.zaxxer.hikari.HikariDataSourcespring.shardingsphere.datasource.ds_1.driver-class-name=com.mysql.jdbc.Driverspring.shardingsphere.datasource.ds_1.jdbc-url= spring.shardingsphere.datasource.ds_1.username= spring.shardingsphere.datasource.ds_1.password=spring.shardingsphere.datasource.ds_1.max-active=16# 默认的分库策略spring.shardingsphere.sharding.default-database-strategy.inline.sharding-column=user_idspring.shardingsphere.sharding.default-database-strategy.inline.algorithm-expression=ds_$->{user_id % 2}spring.shardingsphere.sharding.binding-tables=t_order,t_order_itemspring.shardingsphere.sharding.broadcast-tables=t_address# 不满足分库策略的表放在ds_0上spring.shardingsphere.sharding.default-data-source-name=ds_0# t_order分表策略spring.shardingsphere.sharding.tables.t_order.actual-data-nodes=ds_$->{0..1}.t_order_$->{0..1}spring.shardingsphere.sharding.tables.t_order.table-strategy.inline.sharding-column=order_idspring.shardingsphere.sharding.tables.t_order.table-strategy.inline.algorithm-expression=t_order_$->{order_id % 2}spring.shardingsphere.sharding.tables.t_order.key-generator.column=order_idspring.shardingsphere.sharding.tables.t_order.key-generator.type=SNOWFLAKEspring.shardingsphere.sharding.tables.t_order.key-generator.props.worker.id=123# t_order_item分表策略spring.shardingsphere.sharding.tables.t_order_item.actual-data-nodes=ds_$->{0..1}.t_order_item_$->{0..1}spring.shardingsphere.sharding.tables.t_order_item.table-strategy.inline.sharding-column=order_idspring.shardingsphere.sharding.tables.t_order_item.table-strategy.inline.algorithm-expression=t_order_item_$->{order_id % 2}spring.shardingsphere.sharding.tables.t_order_item.key-generator.column=order_item_idspring.shardingsphere.sharding.tables.t_order_item.key-generator.type=SNOWFLAKEspring.shardingsphere.sharding.tables.t_order_item.key-generator.props.worker.id=123# sharding-jdbc的模式spring.shardingsphere.mode.type=Memory# 开启shardingsphere日志spring.shardingsphere.props.sql.show=true

2.5.3测试验证过程阐明

1.DDL 操作

JPA 主动创立用于测试的表，如下图所示，在配置了 Sharding-JDBC 的分库分表路由规定的状况下，client 端执行 DDL，Sharding-JDBC 会主动依据分表规定创立对应的表；如 t_address 是播送表在 ds_0 和 ds_1 上都会创立 t_address。t_order，t_order_item 依照取模分库分表，这三个表会别离在 ds_0 和 ds_1 上创立。

2.写操作

对于播送表 t_address，每写入一条记录会在 ds_0 和 ds_1 的 t_address 表上都写入。

对于分库的表 t_order，t_order_item，会依照分库字段和路由策略写入到对应实例上的表中。

3.读操作

读操作与仅分库性能验证相似，这里不再赘述

2.6分库分表加读写拆散性能验证

2.6.1数据库环境筹备

创立的数据库实例于对应的物理表如下图所示。

2.6.2Sharding-JDBC 配置

application.properties spring boot 主配置文件阐明

# jpa 主动依据实体创立和drop数据表spring.jpa.properties.hibernate.hbm2ddl.auto=createspring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MySQL5Dialectspring.jpa.properties.hibernate.show_sql=true# 激活sharding-databases-tables配置项#spring.profiles.active=sharding-databases#spring.profiles.active=sharding-tables#spring.profiles.active=sharding-databases-tables#spring.profiles.active=master-slavespring.profiles.active=sharding-master-slave

application-sharding-master-slave.properties sharding-jdbc 配置文件阐明

其中数据库的 url、name、password 须要批改成你本人的数据库的参数。

spring.shardingsphere.datasource.names=ds_master_0,ds_master_1,ds_master_0_slave_0,ds_master_0_slave_1,ds_master_1_slave_0,ds_master_1_slave_1spring.shardingsphere.datasource.ds_master_0.type=com.zaxxer.hikari.HikariDataSourcespring.shardingsphere.datasource.ds_master_0.driver-class-name=com.mysql.jdbc.Driverspring.shardingsphere.datasource.ds_master_0.jdbc-url= spring.shardingsphere.datasource.ds_master_0.username= spring.shardingsphere.datasource.ds_master_0.password=spring.shardingsphere.datasource.ds_master_0.max-active=16spring.shardingsphere.datasource.ds_master_0_slave_0.type=com.zaxxer.hikari.HikariDataSourcespring.shardingsphere.datasource.ds_master_0_slave_0.driver-class-name=com.mysql.jdbc.Driverspring.shardingsphere.datasource.ds_master_0_slave_0.jdbc-url= spring.shardingsphere.datasource.ds_master_0_slave_0.username= spring.shardingsphere.datasource.ds_master_0_slave_0.password=spring.shardingsphere.datasource.ds_master_0_slave_0.max-active=16spring.shardingsphere.datasource.ds_master_0_slave_1.type=com.zaxxer.hikari.HikariDataSourcespring.shardingsphere.datasource.ds_master_0_slave_1.driver-class-name=com.mysql.jdbc.Driverspring.shardingsphere.datasource.ds_master_0_slave_1.jdbc-url= spring.shardingsphere.datasource.ds_master_0_slave_1.username= spring.shardingsphere.datasource.ds_master_0_slave_1.password=spring.shardingsphere.datasource.ds_master_0_slave_1.max-active=16spring.shardingsphere.datasource.ds_master_1.type=com.zaxxer.hikari.HikariDataSourcespring.shardingsphere.datasource.ds_master_1.driver-class-name=com.mysql.jdbc.Driverspring.shardingsphere.datasource.ds_master_1.jdbc-url= spring.shardingsphere.datasource.ds_master_1.username= spring.shardingsphere.datasource.ds_master_1.password=spring.shardingsphere.datasource.ds_master_1.max-active=16spring.shardingsphere.datasource.ds_master_1_slave_0.type=com.zaxxer.hikari.HikariDataSourcespring.shardingsphere.datasource.ds_master_1_slave_0.driver-class-name=com.mysql.jdbc.Driverspring.shardingsphere.datasource.ds_master_1_slave_0.jdbc-url=spring.shardingsphere.datasource.ds_master_1_slave_0.username=spring.shardingsphere.datasource.ds_master_1_slave_0.password=spring.shardingsphere.datasource.ds_master_1_slave_0.max-active=16spring.shardingsphere.datasource.ds_master_1_slave_1.type=com.zaxxer.hikari.HikariDataSourcespring.shardingsphere.datasource.ds_master_1_slave_1.driver-class-name=com.mysql.jdbc.Driverspring.shardingsphere.datasource.ds_master_1_slave_1.jdbc-url= spring.shardingsphere.datasource.ds_master_1_slave_1.username=adminspring.shardingsphere.datasource.ds_master_1_slave_1.password=spring.shardingsphere.datasource.ds_master_1_slave_1.max-active=16spring.shardingsphere.sharding.default-database-strategy.inline.sharding-column=user_idspring.shardingsphere.sharding.default-database-strategy.inline.algorithm-expression=ds_$->{user_id % 2}spring.shardingsphere.sharding.binding-tables=t_order,t_order_itemspring.shardingsphere.sharding.broadcast-tables=t_addressspring.shardingsphere.sharding.default-data-source-name=ds_master_0spring.shardingsphere.sharding.tables.t_order.actual-data-nodes=ds_$->{0..1}.t_order_$->{0..1}spring.shardingsphere.sharding.tables.t_order.table-strategy.inline.sharding-column=order_idspring.shardingsphere.sharding.tables.t_order.table-strategy.inline.algorithm-expression=t_order_$->{order_id % 2}spring.shardingsphere.sharding.tables.t_order.key-generator.column=order_idspring.shardingsphere.sharding.tables.t_order.key-generator.type=SNOWFLAKEspring.shardingsphere.sharding.tables.t_order.key-generator.props.worker.id=123spring.shardingsphere.sharding.tables.t_order_item.actual-data-nodes=ds_$->{0..1}.t_order_item_$->{0..1}spring.shardingsphere.sharding.tables.t_order_item.table-strategy.inline.sharding-column=order_idspring.shardingsphere.sharding.tables.t_order_item.table-strategy.inline.algorithm-expression=t_order_item_$->{order_id % 2}spring.shardingsphere.sharding.tables.t_order_item.key-generator.column=order_item_idspring.shardingsphere.sharding.tables.t_order_item.key-generator.type=SNOWFLAKEspring.shardingsphere.sharding.tables.t_order_item.key-generator.props.worker.id=123# 主从数据源，分库数据源配置spring.shardingsphere.sharding.master-slave-rules.ds_0.master-data-source-name=ds_master_0spring.shardingsphere.sharding.master-slave-rules.ds_0.slave-data-source-names=ds_master_0_slave_0, ds_master_0_slave_1spring.shardingsphere.sharding.master-slave-rules.ds_1.master-data-source-name=ds_master_1spring.shardingsphere.sharding.master-slave-rules.ds_1.slave-data-source-names=ds_master_1_slave_0, ds_master_1_slave_1# sharding-jdbc的模式spring.shardingsphere.mode.type=Memory# 开启shardingsphere日志spring.shardingsphere.props.sql.show=true

2.6.3测试验证过程阐明

1.DDL 操作所属

JPA 主动创立用于测试的表，如下图，在配置了 Sharding-JDBC 的分库路由规定的状况下，client 端执行 DDL，Sharding-JDBC 会主动依据分表规定创立对应的表；如 t_address 是播送表在 ds_0 和 ds_1 上都会创立, t_address，t_order，t_order_item 依照取模分库，这三个表会别离在 ds_0 和 ds_1 上创立。

2.写操作

对于播送表 t_address，每写入一条记录会在 ds_0 和 ds_1 的 t_address 表上都写入

对于分库的表 t_order，t_order_item，会依照分库字段和路由策略写入到对应实例上的表中。

3.读操作

绑定表下的 join 查问操作 order 和 order_item，如下图所示。

3.结语

ShardingSphere 作为一款专一于数据库加强的开源产品，从社区活跃度、产品成熟度、文档丰盛水平上来看都是比拟好的。其中的 Sharding-JDBC 是基于客户端的分库分表计划，它反对了所有的分库分表的场景，并且无需引入 Proxy 这样的中间层，所以升高了运维的复杂性，相比 Proxy 这种形式因为少了中间层所以时延实践上会比 Proxy 低，其次 Sharding-JDBC 能够反对各种基于 SQL 规范的关系型数据库如 MySQL/PostgreSQL/Oracle/SQL Server 等。但因为 Sharding-JDBC 与应用程序集成，目前反对的语言仅限于 Java，对应用程序有肯定的耦合性，但 Sharding-JDBC 将所以分库分表的配置从应用程序中拆散，这样面临切换其余的中间件时由此带来的变更绝对较小。综上所述如果您不心愿引入中间层，且应用基于 Java 语言开发的零碎，且须要对接不同的关系型数据库，Sharding-JDBC 将会是一个不错的抉择。