Apache ShardingSphere：ShardingSphere中间件4.x介绍，分库分表读写分离，ShardingSphere-JDBC，Proxy，ShardingSphere事务，XA

	ShardingSphere-JDBC	ShardingSphere-Proxy	ShardingSphere-Sidecar
数据库	任意	MySQL/PostgreSQL	MySQL/PostgreSQL
连接消耗数	高	低	高
异构语言	仅 Java	任意	任意
性能	损耗低	损耗略高	损耗低
无中心化	是	否	是
静态入口	无	有	无

1.2.4. 同类产品对比

	ShardingSphere	mycat	drds
性能	高	中	高
应用场景限制	Sharding JDBC限java应用，Sharding Proxy无限制	无	无
是否支持自定义sharding路由	是	是	是
最大支持sharding路由维度	2	1	2
分布式事务	4.0.0支持	支持弱xa、支持XA分布式事务（1.6.5）	支持以下分布式事务策略：FREE、2PC、XA、FLEXIBLE
限制	不支持子语句,不支持UNION 和 UNION ALL,不支持批量插入,不支持DISTINCT聚合	详见《MYCAT权威指南》	未明确说明
是否开源	是	是	否

1.3. 谁在用ShardingSphere?

1.3.2. 各大公司

包括当当、京东、滴滴、中通、携程、哔哩哔哩、斗鱼、爱奇艺、搜狐、58、OPPO....

第2章相关技术理论

2.1. 什么是分库分表？

2.1.1. 业务背景

随着时间和业务发展，关系型数据库表里面数据越来越多，再进行curd，造成性能问题。

即便是从硬件上扩充CPU核数、磁盘、内存容量，也是治标不治本。

2.1.2. 分区说明

Hive建表及通过映射关系存数据。

Hive建表语句：CREATE EXTERNAL TABLE IF NOT EXISTS `table_name` (...) PARTITIONED BY ....

Hive可通过查询指定分区查询数据，而不需要进行全表扫描。

MySQL5.1（关系型数据库）以上也支持分区功能，但是缺点多，主要是主键、唯一索引、外键等方面会有很多问题。

2.2. 怎么分库分表？

2.2.2. 分库分表的方式

2.2.2.1. 垂直分表

操作数据库中某张表，把这张表中一部分字段数据存到一张新表里面，再把这张表另一部分字段数据存到另外一张表里面。

2.2.2.2. 垂直分库

把单一数据库按照业务进行划分，专库专表。

2.2.2.3. 水平分库

将一个数据库按照一定的规则拆分成两个数据库。

2.2.2.4. 水平分表

将一个数据库中的一张表拆成多张表。

2.2.3. 分库分表缺点

在数据库设计时候考虑垂直分库和垂直分表

要考虑考虑缓存处理，读写分离，使用索引等等方式

跨节点连接查询问题（分页、排序、Join）

多数据源管理问题

分布式事务问题（ShardingSphere 4.x已解决该问题，后文说明）

2.3. 什么是读写分离？

数据库双机热备：主从模式中有的数据库负责写、有的数据库负责读。

主从复制：当主服务器有写入（insert/update/delete）语句时候，从服务器自动获取。

读写分离：insert/update/delete语句操作一台服务器，select操作另一个服务器。

第3章 ShardingSphere-JDBC

3.1. 简介

3.0版本前是当当网研发的开源分布式数据库中间件。

4.0 版本之后的版本为 Apache 版本。

目前只支持Java API。

3.1.1. 定位

轻量级 Java 框架。

增强版的 JDBC 驱动。

3.1.2. 优点

适用于任何基于 JDBC 的 ORM 框架。

支持任何第三方的数据库连接池。

支持任意实现 JDBC 规范的数据库。

3.2. ShardingSphere-JDBC读写分离原理

根据SQL语义的分析，将读操作和写操作分别路由至主库与从库。

提供透明化读写分离，让使用方尽量像使用一个数据库一样使用主从数据库集群。

ShardingSphere-JDBC提供一主多从的读写分离配置，可独立使用，也可配合分库分表使用。

ShardingSphere-JDBC不提供主从数据库的数据同步功能，需要采用其他机制支持。

3.3. 应用测试

3.3.1. 测试水平分表

创建一个数据库course_db，两个表course_1、course_2，修改SpringBoot项目的application.properties配置，相关配置文件示例如下：

使用Java API执行插入操作。

查看表中数据，其中cid为奇偶数的数据被插入到不同的表中。

3.3.2. 测试水平分库

创建数据库course_db_1、course_db_2，表course_1、course_2，修改SpringBoot项目的application.properties配置，使用Java API执行插入操作。

查看两个数据库、四个表中都有数据。

3.3.3. 测试垂直分库

创建数据库user_db，表t_user，修改SpringBoot项目的application.properties配置，使用Java API执行插入操作。

查看表内容，程序会讲数据插入到m0对应的库（user_db）中。

3.3.4. 测试公共表

创建数据库course_db_1、course_db_2、user_db，公共表t_udict，修改SpringBoot项目的application.properties配置，使用Java API执行插入操作。

查看表，发现所有表中数据均被插入。

测试使用Java删除某个数据库中的数据。

查看表，发现所有表中指定的数据均被删除。

说明：各个部门对公共表进行crud和单个部门对公共表进行维护有区别。

3.3.5. 测试主从模式读写分离

先在window中搭建主从MySQL并启动，Mac及Linux系统以及其他相关操作请参考其他文档。

测试Java API往t_user表中插入数据，程序每次都只会往主机m0中插入数据。

一段时间后查看主从机中的数据，发现从机中的数据也被更新了。

第4章 ShardingSphere-Proxy

4.1. 简介

4.1.1. 定位

透明化的数据库代理端。

4.1.2. 优点

向应用程序完全透明，可直接当做 MySQL/PostgreSQL 使用。

适用于任何兼容 MySQL/PostgreSQL 协议的的客户端。

4.2. 应用测试

Sharding-Proxy 独立应用，需要安装服务，进行分库分表或者读写分离配置，启动后才能使用。

4.2.1. 测试ShardingSphere-Proxy分表

安装好Sharding-Proxy以后，修改文件 server.yaml，相关配置如下：

通过执行start.bat(Linux中执行start.sh)来启动Sharding-Proxy服务,一段时间后查看主从机数据库表。

往主机中插入一条数据：

查看主机、从机：

4.2.2. 测试ShardingSphere-Proxy分库

修改config-sharding.yaml文件，启动Sharding-Proxy服务,一段时间后查看主从机数据库表。

4.2.3. 测试Sharding-Proxy读写分离

创建三个数据库course_db、course_db_1、course_db_2，执行如下SQL：

INSERT INTO course_1 VALUES (1234, '测试读写分离', 5678, 'test');

修改config-master-slave.yaml文件，启动Sharding-Proxy服务,一段时间后查看主从机数据库表：

第5章 ShardingSphere 4.x分布式事务

参考ShardingSphere事务官网：https://shardingsphere.apache.org/document/current/cn/features/transaction/

5.1. 数据库事务

ACID（原子性、一致性、隔离性、持久性）。

5.1.1. 本地事务

仅限于对单一数据库资源的访问控制，几乎所有的成熟的关系型数据库都提供了对本地事务的原生支持。

5.1.2. 两阶段提交

基于XA协议实现的分布式事务对业务，最大的优势就是对使用方透明，用户可以像使用本地事务一样使用基于XA协议的分布式事务。

在高并发的性能至上场景中，基于XA协议的分布式事务并不是最佳选择。

5.1.3. 柔性事务

如果将实现了 ACID 的事务要素的事务称为刚性事务的话，那么基于BASE事务要素的事务则称为柔性事务。

BASE是基本可用、柔性状态和最终一致性这三个要素的缩写，以下是具体说明：

l 基本可用（Basically Available）保证分布式事务参与方不一定同时在线。

l 柔性状态（Soft state）则允许系统状态更新有一定的延时，这个延时对客户来说不一定能够察觉。

l 而最终一致性（Eventually consistent）通常是通过消息传递的方式保证系统的最终一致性。

5.1.4. 本地事务、两阶段事务、柔性事务的区别

基于ACID的强一致性事务和基于BASE的最终一致性事务都不是银弹，只有在最适合的场景中才能发挥它们的最大长处。

以下是三者的区别：

	本地事务	两（三）阶段事务	柔性事务
业务改造	无	无	实现相关接口
一致性	不支持	支持	最终一致
隔离性	不支持	支持	业务方保证
并发性能	无影响	严重衰退	略微衰退
适合场景	业务方处理不一致	短事务 & 低并发	长事务 & 高并发

5.2. ShardingSphere实现分布式事务原理

5.2.1. XA两阶段事务

XAShardingTransactionManager为Apache ShardingSphere 的分布式事务的XA实现类。它主要负责对多数据源进行管理和适配，并且将相应事务的开启、提交和回滚操作委托给具体的 XA 事务管理器。

参考ShardingSphere官网：https://shardingsphere.apache.org/document/current/cn/features/transaction/principle/2pc-xa-transaction/

整合 Seata AT 事务时，需要将 TM，RM 和 TC 的模型融入 Apache ShardingSphere 的分布式事务生态中。在数据库资源上，Seata 通过对接DataSource接口，让 JDBC 操作可以同 TC 进行远程通信。同样，Apache ShardingSphere 也是面向DataSource接口，对用户配置的数据源进行聚合。因此，将DataSource封装为基于Seata 的DataSource后，就可以将 Seata AT 事务融入到 Apache ShardingSphere的分片生态中。

官网：https://shardingsphere.apache.org/document/current/cn/features/transaction/principle/base-transaction-seata/