1.概念
sharding jdbc是放到我们应用中的，作为一种jar包的形式。
上图中我们也可以看到，他希望有一个注册中心，他是希望可以通过统一的配置来完成数据库的快速伸缩，不需要重启应用的方式。
也就是说它和我们的应用整合在了一起，在应用中完成分库分表
shardingJDBC定位为轻量级Java框架，在Java的JDBC层提供的额外服务。它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。
shardingProxy是部署一个独立的应用，来代理我们的mysql集群，我们应用通过和这个代理通通信来完成分库分表。
上图中，我们可以看到，proxy的方式还需要一个注册中心，他统一服务化的管理，这里不仅仅是希望能够实现在线数据块的伸缩，也是希望提高可用性
ShardingProxy定位为透明化的数据库代理端，提供封装了数据库二进制协议的服务端版本，用于完成对异构语言的支持。目前提供 MySQL和PostgreSQL 版本，它可以使用任何兼容MySQL/PostgreSQL协议的访问客户端。
两者之间的区别如下：
很显然，ShardingJDBC只是客户端的一个工具包，可以理解为一个特殊的JDBC驱动包，所有分库分表逻辑均由业务方自己控制，所以他的功能相对灵活，支持的数据库也非常多，但是对业务侵入大，需要业务方自己定制所有的分库分表逻辑。而ShardingProxy是一个独立部署的服务，对业务方无侵入，业务方可以像用一个普通的MySQL服务一样进行数据交互，基本上感觉不到后端分库分表逻辑的存在，但是这也意味着功能会比较固定，能够支持的数据库也比较少。这两者各有优劣。
2.Sharding JDBC 实战
shardingjdbc的核心功能是数据分片和读写分离，通过ShardingJDBC，应用可以透明的使用JDBC访问已经分库分表,读写分离的多个数据源，而不用关心数据源的数量以及数据如何分布。
1.核心概念
1.分库分表的作用
分库分表就是为了解决由于数据量过大而导致数据库性能降低的问题，将原来独立的数据库拆分成若干数据库组成
，将数据大表拆分成若干数据表组成，使得单一数据库、单—数据表的数据量变小，从而达到提升数据库性能的目
的。
例如:微服务架构中，每个服务都分配一个独立的数据库，这就是分库。而对一些业务日志表，按月拆分成不同的表，这就是分表。
所以分库就是：把一个数据库中的表，拆分到多个数据库。分表就是：把一个表中的数据拆分到多个表
2.分库分表的方式
分库分表包含分库和分表两个部分，而这两个部分可以统称为数据分片，其目的都是将数据拆分成不同的存储单元。另外，从分拆的角度上，可以分为垂直分片和水平分片。
- 垂直分片: 按照业务来对数据进行分片，又称为纵向分片。他的核心理念就是转库专用。在拆分之前，一个数据库由多个数据表组成，每个表对应不同的业务。而拆分之后，则是按照业务将表进行归类，分布到不同的数据库或表中，从而将压力分散至不同的数据库或表。例如，下图将用户表和订单表垂直分片到不同的数据库:
垂直分片往往需要对架构和设计进行调整。通常来讲，是来不及应对业务需求快速变化的。而且，他也无法真正的解决单点数据库的性能瓶颈。垂直分片可以缓解数据量和访问量带来的问题，但无法根治。如果垂直分片之后，表中的数据量依然超过单节点所能承载的阈值，则需要水平分片来进一步处理。
一般来说，我们的t_order表的数据增长是快与t_user表的。我们将他们放在不同的库，方便后续做优化。一般来说，分库都是基于业务来进行的。把不同的模块的业务需要的表放到不同的库中，方便不同的团队进行维护
但是分库是无法解决单表数据量大的问题的。想要解决单表数据量大的问题，就需要进行分表。
- 水平分片: 又称横向分片。相对于垂直分片，它不再将数据根据业务逻辑分类,而是通过某个字段(或某几个字段)，根据某种规则将数据分散至多个库或表中，每个分片仅包含数据的一部分。例如，像下图根据主键机构分片。
上图是根据id%2（2是分表的数量）进行的分片（表的水平分片）
常用的分片策略有:
取余\取模: 优点均匀存放数据，缺点扩容非常麻烦
按照范围分片（id 1-100000的在一个库，100001-200000的在一个库）∶ 比较好扩容，数据分布不够均匀，删除数据后，腾出来的空间也无法在被使用。而且容易出现热点问题，插入的时候只能用到一个数据库
按照时间分片∶ 比较容易将热点数据区分出来。
- 按照枚举值分片∶ 例如按地区分片
- 按照目标字段前缀指定进行分区: 自定义业务规则分片
3.分表之-双倍扩容
这是一个秒级扩容的方案，这个方案能将原本的N个数据库秒级扩容为2N个数据库
- 我们假设我们目前是以2个库来进行分表设计的， id/2=0的放到一个0号库的0号表中，id%2=1的放到1号库的1号表汇总。
- .不过我们此时准备四个库，这多准备的两个分别是0号库的从库和1号库的从库，此时看起来一切都很正常。mysql主从配置，高可用。
- 此时假设我们需要对数据块进行扩容，但是我们这种扩容方式是有个前提条件的，就是他只能变成2N个数据库。此时我们只需要把从库提上来。比如我们之前是按照2来取模的，此时我们就需要按照4来取模，然后把原本的0号主库依然作为0号主库，但是0号从库变成2号主库。1号库也是如此。之所以这样是因为：虽然我们把取模的值从2变成了4，但是对2取模为偶数的，对4取模也一定为偶数。比如,6，原本对2取模的时候为0，那么对4取模为2。也就是说：此时我们刚刚做好的2N的扩容数据块，在没有删除旧数据的情况下。0号库中包含了2号库中的数据，同时2号库中也包含了0号库中的数据，我们过后只需要把每个库中多余的这一部分数据，删除就可以了。
然后为了保持高可用，再给每个库配一个新的从库，也是为了方便以后继续扩容的时候使用。
4.分库分表的缺点：
虽然数据分片解决了性能、可用性以及单点备份恢复等问题，但是分布式的架构在获得收益的同时，也引入了非常多新的问题。
●事务一致性问题
原本单机数据库有很好的事务机制能够帮我们保证数据一致性。但是分阵分衣后，由于数据分布在不同库甚至不同服务器，不可避免会带来分布式事务问题。
●跨节点关联查询问题
在没有分库时，我们可以进行很容易的进行跨表的关联查询。但是仕分厍石，衣似分散到了不同的数据库，就无法进行关联查询了。
这时就需要将关联查询拆分成多次查询，然后将获得的结果进行拼装。
·●跨节点分页、排序函数
跨节点多库进行查询时，limit分页、 order by排序等问题，就变得比较复杂了。需要先在不同的分片节点中将数据
进行排序并返回，然后将不同分片返回的结果集进行汇总和再次排序。
这时非常容易出现内存崩溃的问题。
●主键避重问题
在分库分表环境中，由于表中数据同时存在不同数据库中，主键值平时使用的自增长将无用武之地，某个分区数据
库生成的ID无法保证全局唯一。因此需要单独设计全局主键，以避免跨库主键重复问题。
●公共表处理
实际的应用场景中，参数表、数据字典表等都是数据量较小，变动少，而且属于高频联合查询的依赖表。这一类表一般就需要在每个数据库中都保存一份，并且所有对公共表的操作都要分发到所有的分库去执行。
●运维工作量
面对散乱的分库分表之后的数据，应用开发工程师和数据库管理员对数据库的操作都变得非常繁重。对于每一次数据读写操作，他们都需要知道要往哪个具体的数据库的分表去操作，这也是其中重要的挑战之一。
这些问题也是shardingsphere要帮我们解决的问题。
5.什么时候需要分库分表
在阿里巴巴公布的开发手册中，建议MySQL单表记录如果达到500W这个级别，或者单表容量达到2GB，一般就建议进行分库分表。而考虑到分库分表需要对数据进行再平衡，所以如果要使用分库分表，就要在系统设计之初就详细考虑好分库分表的方案，这里要分两种情况。
一般对于用户数据这一类后期增长比较缓慢的数据，一般可以按照三年左右的业务量来预估使用人数，按照标准预设好分库分表的方案。
而对于业务数据这一类增长快速且稳定的数据，一般则需要按照预估量的两倍左右预设分库分表方案。并且由于分库分表的后期扩容是非常麻烦的，所以在进行分库分表时，尽量根据情况，多分一些表。最好是计算一下数据增量，永远不用增加更多的表。
另外，在设计分库分表方案时，要尽量兼顾业务场景和数据分布。在支持业务场景的前提下，尽量保证数据能够分得更均匀。
最后，一旦用到了分库分表，就会表现为对数据查询业务的灵活性有一定的影响，例如如果按userld进行分片，那按age来进行查询，就必然会增加很多麻烦。如果再要进行排序、分页、聚合等操作，很容易就扛不住了。这时候，都要尽量在分库分表的同时，再补充设计一个降级方案，例如将数据转存一份到ES，ES可以实现更灵活的大数据聚合查询。
6.shardingsphere中分库分表的基础概念
- ·逻辑表:水平拆分的数据库的相同逻辑和数据结构表的总称·。就是我们在sql中写的表名
- 真实表:在分片的数据库中真实存在的物理表。就是对我们隐藏的，真正的数据库的表名
- ·数据节点:数据分片的最小单元。由数据源名称（库）和数据表组成·
- 绑定表:分片规则一致的主表和子表。
- ·广播表:也叫公共表，指素有的分片数据源中都存在的表，表结构和表中的数据在每个数据库中都完全一致。例如字典表。
- ·分片键:用于分片的数据库字段，是将数据库(表)进行水平拆分的关键字段。SQL中若没有分片字段，将会执行全路由，性能会很差。
- ·分片算法:通过分片算法将数据进行分片，支持通过=、BETWEEN和IN分片。分片算法需要由应用开发者自行实现，可实现的灵活度非常高。
- ·分片策略:真正用于进行分片操作的是分片键+分片算法，也就是分片策略。在ShardingJDBC中一般采用基于Groovy表达式的inline分片策略，通过一个包含分片键的算法表达式来制定分片策略，如
t_user_$->{fu_id%8}fu_id就是分片键，fu_id%8就是分片算法。 标识根据u_id模8，分成8张表，表名称为t_user_0到t_user_7。
2.实战代码-分表
首先我们准备好我们的pom
<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"><modelVersion>4.0.0</modelVersion><parent><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-parent</artifactId><version>2.5.13</version><relativePath/> <!-- lookup parent from repository --></parent><groupId>com.roy</groupId><artifactId>ShardingSphereDemo</artifactId><version>0.0.1-SNAPSHOT</version><name>ShardingSphereDemo</name><description>Demo project for Spring Boot</description><properties><java.version>1.8</java.version></properties><dependencies><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency><dependency><groupId>org.mybatis.spring.boot</groupId><artifactId>mybatis-spring-boot-starter</artifactId><version>2.2.2</version></dependency><dependency><groupId>com.baomidou</groupId><artifactId>mybatis-plus-boot-starter</artifactId><version>3.0.5</version></dependency><dependency><groupId>org.mybatis.spring.boot</groupId><artifactId>mybatis-spring-boot-starter</artifactId><version>2.2.2</version></dependency><!--这里就是我们的重点，引入的sharding sphere--><dependency><groupId>org.apache.shardingsphere</groupId><artifactId>sharding-jdbc-spring-boot-starter</artifactId><version>4.1.1</version></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-jdbc</artifactId></dependency><dependency><groupId>mysql</groupId><artifactId>mysql-connector-java</artifactId><scope>runtime</scope></dependency><dependency><groupId>org.projectlombok</groupId><artifactId>lombok</artifactId><optional>true</optional></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-test</artifactId><scope>test</scope></dependency></dependencies><build><plugins><plugin><groupId>org.springframework.boot</groupId><artifactId>spring-boot-maven-plugin</artifactId><configuration><excludes><exclude><groupId>org.projectlombok</groupId><artifactId>lombok</artifactId></exclude></excludes></configuration></plugin></plugins></build></project>
然后准备我我们的表：
CREATE TABLE `course_1` (
`cid` bigint(20) NOT NULL,
`cname` varchar(50) NOT NULL,
`user_id` bigint(20) NOT NULL,
`cstatus` varchar(10) DEFAULT NULL,
PRIMARY KEY (`cid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
在准备好我们的实体类：
@Data
public class Course {
/**
* 一定要注意这里指定ID，否则sharding插入数据时候，不会吧这行当做主键，插入的时候就没有这行字段
*/
@TableId
private Long cid;
private String cname;
private Long userId;
private String cstatus;
}
同样准备好我们的Mapper
@Mapper
public interface CourseMapper extends BaseMapper<Course> {
}
最最最重要的配置文件：
#注意我们既然要使用shardingsphere，那么就必须如下的这种配置
#指定一个我们数据源的名称
spring.shardingsphere.datasource.names=m1
spring.shardingsphere.datasource.m1.driver-class-name=com.mysql.jdbc.Driver
#指定使用的数据源
spring.shardingsphere.datasource.m1.type=com.zaxxer.hikari.HikariDataSource
#指定好我们必要的配置类
spring.shardingsphere.datasource.m1.jdbc-url=jdbc:mysql://localhost:3306/coursedb?autoReconnect=true&useUnicode=true&characterEncoding=utf-8&allowMultiQueries=true
spring.shardingsphere.datasource.m1.username=root
spring.shardingsphere.datasource.m1.password=123456
#这句话的意思是，我们配置了一个逻辑表course，这个逻辑表对应的真实表为：
#m1.course_$->{1..2} 这是我们真实表的分配规则
#这个表达式的含义就是我们真实表的为 m1.course_1和m2.course_2。用数字替代前面的$
#这样我们就制定好了真实表
#course是我们逻辑表的表名
#注意不一定非要写这样的表达式，这样的表达式，他就是笛卡尔积的结果，不一定是好事
#w我们可以通过m1.course_1和m2.course_2这样固定的指定方式。因为
#当我们进行非分片键查询的时候，如果我们用m$_>{1..2}.course_$_>{1..2}那么
#他回去m1.course_1 m2.course_2 m1.course_2 m2.course_1 这四个表去查询
#显然其中m1.course_2 m2.course_1这两个是不存在的，就会报错
#但是如果我们写成m1.course_1和m2.course_2 这种形式，就可以保证不会读取到不存在的表了
spring.shardingsphere.sharding.tables.course.actual-data-nodes=m1.course_$->{1..2}
#这里是指定了主键列
spring.shardingsphere.sharding.tables.course.key-generator.column=cid;
#制定我们的主键生成的算法。这个SNOWFLAKE是它默认提供的一种主键生成算法（雪花算法）
spring.shardingsphere.sharding.tables.course.key-generator.type=SNOWFLAKE
#这个worker.id是雪花算法需要的一种属性
spring.shardingsphere.sharding.tables.course.key-generator..props.worker.id=1
#配置我们的分片策略需要的分片键.table-strategy有很多种分表策略。这里我们选inline .为啥选inline呢？
spring.shardingsphere.sharding.tables.course.table-strategy.inline.sharding-column=cid
#配置我们的分片策略需要的分片算法
spring.shardingsphere.sharding.tables.course.table-strategy.inline.algorithm-expression=course_$->{cid%2+1}
#配置如下这个属性，我们可以看到我们实际执行的一个sql
spring.shardingsphere.props.sql.show=true
#配置一个允许bean定义覆盖的配置,spring中他默认为false
spring.main.allow-bean-definition-overriding=true
1.分表插入
然后再写我们的测试代码：
@Test
void addCourse() {
for(int i = 0 ; i < 10 ; i++) {
Course c = new Course();
c.setCstatus("1");
c.setCname("shardingSphere");
c.setUserId(Long.valueOf(""+(1000+i)));
courseMapper.insert(c);
}
}
我们准备的两个真实表为：
我们执行代码，查看插入的数据，对于course_1表来说，结果如下：
能看到cid值结尾都是偶数
再来看course_2:
可以看到cid的值都是奇数结尾。
这样，我们基础的分表就实现了
2.分表查询
我们准备好查询的代码：
@Test
void queryCourse() {
List<Course> courses = courseMapper.selectList(null);
courses.forEach(System.out::println);
}
可以发现，和平时写的没有什么不同
然后执行代码查看结果：
可以看到，十条数据都查出来了。
这就是我们的sharding真正执行的sql。他帮我们去两个表查了
那么如果我们只查其中的一个数据，结果会怎么样呢：
可以看到，成功的输出了
然后我们再看看sharding实际执行的sql：
可以看到，他精确的知道去哪里获取这个数据
但是当我们用的不是分片主键查询的时候，效果如何呢？
@Test
void queryCourse() {
QueryWrapper<Course> wrapper = new QueryWrapper();
wrapper.eq("cname","shardingSphere1");
List<Course> courses = courseMapper.selectList(wrapper);
courses.forEach(System.out::println);
}
可以看到，他虽然能成功查询到数据。但是他需要在多个分表中同时进行查询。同样当们执行in查询的时候，也是这个效果
3.范围查询
当我们执行范围查询的时候，会有什么结果呢？
@Test
void queryCourse() {
QueryWrapper<Course> wrapper = new QueryWrapper();
wrapper.between(true,"cid",1520071129182556161L,1520071131506200577L);
List<Course> courses = courseMapper.selectList(wrapper);
courses.forEach(System.out::println);
}
当我们执行这个范围查询的时候，会得到如下的一个结果：
可以看到，他说inline这种模式不支持范围查询
因此我们就需要换一种策略。不过我们先来看看如何用sharding实现分库
4.实战代码-分库分表
首先我们还是需要准备好我们的配置文件：
#指定我们需要的所有的数据源的名称
spring.shardingsphere.datasource.names=m1,m2
#指定我们的第一个数据源
spring.shardingsphere.datasource.m1.driver-class-name=com.mysql.jdbc.Driver
#指定使用的数据源
spring.shardingsphere.datasource.m1.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.m1.jdbc-url=jdbc:mysql://localhost:3306/coursedb?autoReconnect=true&useUnicode=true&characterEncoding=utf-8&allowMultiQueries=true
spring.shardingsphere.datasource.m1.username=root
spring.shardingsphere.datasource.m1.password=123456
#指定我们的第二个数据源
spring.shardingsphere.datasource.m2.driver-class-name=com.mysql.jdbc.Driver
#指定使用的数据源
spring.shardingsphere.datasource.m2.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.m2.jdbc-url=jdbc:mysql://localhost:3306/coursedb2?autoReconnect=true&useUnicode=true&characterEncoding=utf-8&allowMultiQueries=true
spring.shardingsphere.datasource.m2.username=root
spring.shardingsphere.datasource.m2.password=123456
#这里我们不仅仅是真实表参加运算了，我们的库名称也要参加运算
spring.shardingsphere.sharding.tables.course.actual-data-nodes=m$->{1..2}.course_$->{1..2}
#这里是指定了主键列
spring.shardingsphere.sharding.tables.course.key-generator.column=cid;
#制定我们的主键生成的算法。这个SNOWFLAKE是它默认提供的一种主键生成算法（雪花算法）
spring.shardingsphere.sharding.tables.course.key-generator.type=SNOWFLAKE
#这个worker.id是雪花算法需要的一种属性
spring.shardingsphere.sharding.tables.course.key-generator..props.worker.id=1
#配置我们的分片策略需要的分片键.table-strategy有很多种分表策略。这里我们选inline .为啥选inline呢？
spring.shardingsphere.sharding.tables.course.table-strategy.inline.sharding-column=cid
#配置我们的分片策略需要的分片算法，
spring.shardingsphere.sharding.tables.course.table-strategy.inline.algorithm-expression=course_$->{cid%2+1}
#####这里我们还需要指定一个分库的策略，上边指定的都是分表的策略
spring.shardingsphere.sharding.tables.course.database-strategy.inline.sharding-column=cid
#####这里因为我们之前分库了，所以这里进行分库的匹配计算
spring.shardingsphere.sharding.tables.course.database-strategy.inline.algorithm-expression=m$->{cid%2+1}
#配置如下这个属性，我们可以看到我们实际执行的一个sql
spring.shardingsphere.props.sql.show=true
#配置一个允许bean定义覆盖的配置,spring中他默认为false
spring.main.allow-bean-definition-overriding=true
注意看配置文件上的详细说明.
然后我们依然用之前的我们的那个插入测试代码测试：
@Test
void addCourse() {
for(int i = 0 ; i < 10 ; i++) {
Course c = new Course();
c.setCstatus("1");
c.setCname("shardingSphere");
c.setUserId(Long.valueOf(""+(1000+i)));
courseMapper.insert(c);
}
}
在看我们准备好的两个数据块
当我们执行插入后，就能发现course_1中多了5条数据，course_2中也多了五条：
这样我们就完成了分库分表的配置。
3.table-strategy和database-strategy属性
关于这个配置的属性，之前我们已经用过了inline这个值，但是我们也知道这个值不能进行范围查询，但是table-stragegy除了这个inline属性外，还有很多其他的属性
1.standard
standard的类型一共需要指定六个配置，分别是库的和表的：
#--------------------------------------------------------------------------------------------------------------
#这里我们配置的分片算法，只用我们再用分片键去查询的时候，才会走这个分片算法。如果我们查询的时候没有分片键
#那么他就不会走这些分片算法，同时如果我们的查询条件中同时带有分片键和非分片键，那么只有分片键才会
#进入到这些算法中,非分片键不会进入，所以我们继承的类才可以指定泛型为分片键类型
#所以，下边的算法都是用来确定怎么走库和表的，
spring.shardingsphere.sharding.tables.course.table-strategy.standard.sharding-column=cid
#这个就是，当查询是范围查询的时候，他要确定走那些表（全走，或者直走其中某个），就会调用这个配置指定的算法
spring.shardingsphere.sharding.tables.course.table-strategy.standard.range-algorithm-class-name=com.roy.ShardingSphereDemo.algorithm.table.MyRangeDataBaseShardingAlgorithm
#这个就是，当分片键的查询是非范围查询的时候，他要确定要走那个指定的表，这个表必须是指定的，只能有一个
spring.shardingsphere.sharding.tables.course.table-strategy.standard.precise-algorithm-class-name=com.roy.ShardingSphereDemo.algorithm.table.MyPreciseDataBaseShardingAlgorithm
spring.shardingsphere.sharding.tables.course.database-strategy.standard.sharding-column=cid
#这个就是，当查询是范围查询的时候，他要确定走那些库（全走，或者直走其中某个），就会调用这个配置指定的算法
spring.shardingsphere.sharding.tables.course.database-strategy.standard.range-algorithm-class-name=com.roy.ShardingSphereDemo.algorithm.database.MyRangeDataBaseShardingAlgorithm
#这个就是，当分片键的查询是非范围查询的时候，他要确定要走那个指定的库，这个库必须是指定的，只能有一个
spring.shardingsphere.sharding.tables.course.database-strategy.standard.precise-algorithm-class-name=com.roy.ShardingSphereDemo.algorithm.database.MyPreciseDataBaseShardingAlgorithm
#--------------------------------------------------------------------------------------------------------------
然后我们在看一下整体的配置，上边有更详细的说明：
#指定我们需要的所有的数据源的名称
spring.shardingsphere.datasource.names=m1,m2
#指定我们的第一个数据源
spring.shardingsphere.datasource.m1.driver-class-name=com.mysql.jdbc.Driver
#指定使用的数据源
spring.shardingsphere.datasource.m1.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.m1.jdbc-url=jdbc:mysql://localhost:3306/coursedb?autoReconnect=true&useUnicode=true&characterEncoding=utf-8&allowMultiQueries=true
spring.shardingsphere.datasource.m1.username=root
spring.shardingsphere.datasource.m1.password=123456
#指定我们的第二个数据源
spring.shardingsphere.datasource.m2.driver-class-name=com.mysql.jdbc.Driver
#指定使用的数据源
spring.shardingsphere.datasource.m2.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.m2.jdbc-url=jdbc:mysql://localhost:3306/coursedb2?autoReconnect=true&useUnicode=true&characterEncoding=utf-8&allowMultiQueries=true
spring.shardingsphere.datasource.m2.username=root
spring.shardingsphere.datasource.m2.password=123456
#这里我们不仅仅是真实表参加运算了，我们的库名称也要参加运算
#重点是看看这里
spring.shardingsphere.sharding.tables.course.actual-data-nodes=m1.course_1,m2.course_2
#这里是指定了主键列
spring.shardingsphere.sharding.tables.course.key-generator.column=cid;
#制定我们的主键生成的算法。这个SNOWFLAKE是它默认提供的一种主键生成算法（雪花算法）
spring.shardingsphere.sharding.tables.course.key-generator.type=SNOWFLAKE
#这个worker.id是雪花算法需要的一种属性
spring.shardingsphere.sharding.tables.course.key-generator..props.worker.id=1
#--------------------------------------------------------------------------------------------------------------
#这里我们配置的分片算法，只用我们再用分片键去查询的时候，才会走这个分片算法。如果我们查询的时候没有分片键
#那么他就不会走这些分片算法，同时如果我们的查询条件中同时带有分片键和非分片键，那么只有分片键才会
#进入到这些算法中,非分片键不会进入，所以我们继承的类才可以指定泛型为分片键类型
#所以，下边的算法都是用来确定怎么走库和表的，
spring.shardingsphere.sharding.tables.course.table-strategy.standard.sharding-column=cid
#这个就是，当查询是范围查询的时候，他要确定走那些表（全走，或者直走其中某个），就会调用这个配置指定的算法
spring.shardingsphere.sharding.tables.course.table-strategy.standard.range-algorithm-class-name=com.roy.ShardingSphereDemo.algorithm.table.MyRangeTableShardingAlgorithm
#这个就是，当分片键的查询是非范围查询的时候，他要确定要走那个指定的表，这个表必须是指定的，只能有一个
spring.shardingsphere.sharding.tables.course.table-strategy.standard.precise-algorithm-class-name=com.roy.ShardingSphereDemo.algorithm.table.MyPreciseTableShardingAlgorithm
spring.shardingsphere.sharding.tables.course.database-strategy.standard.sharding-column=cid
#这个就是，当查询是范围查询的时候，他要确定走那些库（全走，或者直走其中某个），就会调用这个配置指定的算法
spring.shardingsphere.sharding.tables.course.database-strategy.standard.range-algorithm-class-name=com.roy.ShardingSphereDemo.algorithm.database.MyRangeDataBaseShardingAlgorithm
#这个就是，当分片键的查询是非范围查询的时候，他要确定要走那个指定的库，这个库必须是指定的，只能有一个
spring.shardingsphere.sharding.tables.course.database-strategy.standard.precise-algorithm-class-name=com.roy.ShardingSphereDemo.algorithm.database.MyPreciseDataBaseShardingAlgorithm
#--------------------------------------------------------------------------------------------------------------
#配置如下这个属性，我们可以看到我们实际执行的一个sql
spring.shardingsphere.props.sql.show=true
#配置一个允许bean定义覆盖的配置,spring中他默认为false
spring.main.allow-bean-definition-overriding=true
然后我们看table-strategy.standard.range-algorithm-class-name和table-strategy.standard.precise-algorithm-class-name这两个后边的算法的具体实现类：
table-strategy.standard.range-algorithm-class-name:
package com.roy.ShardingSphereDemo.algorithm.table;
import org.apache.shardingsphere.api.sharding.standard.RangeShardingAlgorithm;
import org.apache.shardingsphere.api.sharding.standard.RangeShardingValue;
import java.util.Collection;
/**
* 这个RangeShardingAlgorithm的作用就是，当我们的sql的分片键是范围查询的时候，他会调用这个我们
* 自己的实现类，他好确定，我们每个分片键的范围查询，都要走那些表。
* 默认情况下，我们只需要把 doSharding 的第一个入参 就是 Collection<String> collection返回去就好
* 如果某些分片键范围查询的sql需要特殊处理，再根据下边这个函数的入参进行指定的处理
* 这里接口的泛型类型就是我们分片键的类型RangeShardingAlgorithm<Long>
*/
public class MyRangeDataBaseShardingAlgorithm implements RangeShardingAlgorithm {
/**
*
*
* @param collection 这个是我们传入的库名，因为我们分库了，所以这里需要传入哪些真实表的表名
* @param rangeShardingValue 这个参数是我们指定的分片键和他的值
* @return 这里就是我们要查询那些库，可以全部，也可以我们根据特定的sql来指定查询那些库
*/
@Override
public Collection<String> doSharding(Collection collection, RangeShardingValue rangeShardingValue) {
System.out.println(collection);
System.out.println("------------table----------------------");
System.out.println(rangeShardingValue);
System.out.println("----------------------------------");
return collection;
}
}
table-strategy.standard.precise-algorithm-class-name
package com.roy.ShardingSphereDemo.algorithm.table;
import org.apache.shardingsphere.api.sharding.standard.PreciseShardingAlgorithm;
import org.apache.shardingsphere.api.sharding.standard.PreciseShardingValue;
import java.util.Collection;
/**
* 这里是，当我们的分片键是非范围查询的时候，他就会调用这个算法
* 因为我们的分片键是非范围查询，他要根据这个算法判断，确定到底去哪个真实库查询。
* 这里接口的泛型类型就是我们分片键的类型PreciseShardingAlgorithm<Long>
*/
public class MyPreciseDataBaseShardingAlgorithm implements PreciseShardingAlgorithm {
/**
*
* @param collection 这个参数是传进来的数据库的名字，就是我们在配置文件中指定的那个m1和m2
* @param preciseShardingValue 这个参数是我们指定的分片键和他的值
* @return 返回的就是我们要查询那个数据库，因为是单条查询，必须要指定要走的库
*/
@Override
public String doSharding(Collection collection, PreciseShardingValue preciseShardingValue) {
System.out.println(collection);
System.out.println("----------------------------------");
System.out.println(preciseShardingValue);
System.out.println("----------------------------------");
//这里就是拿到我们的分片键的值，因为是但条件查询，所以可以直接获取传入的值
Long value = preciseShardingValue.getValue();
value=value%2;
//注意这里，我们是写死的，其实可以通过配置文件的引入进来，因为我们默认我们的表名为course_开头
String tablePre ="course_";
//这样我们就拿到了我们的精确的要访问的表名了。
String tableName = tablePre+value;
return tableName;
}
}
然后我们看database-strategy.standard.range-algorithm-class-name和database-strategy.standard.precise-algorithm-class-name这两个后边的算法的具体实现类：
database-strategy.standard.range-algorithm-class-name
package com.roy.ShardingSphereDemo.algorithm.database;
import org.apache.shardingsphere.api.sharding.standard.RangeShardingAlgorithm;
import org.apache.shardingsphere.api.sharding.standard.RangeShardingValue;
import java.util.ArrayList;
import java.util.Collection;
import java.util.List;
/**
* 这个RangeShardingAlgorithm的作用就是，当我们的sql的分片键是范围查询的时候，他会调用这个我们
* 自己的实现类，他好确定，我们每个分片键的范围查询，都要走那些库。
* 默认情况下，我们只需要把 doSharding 的第一个入参 就是 Collection<String> collection返回去就好
* 如果某些分片键范围查询的sql需要特殊处理，再根据下边这个函数的入参进行指定的处理
* 这里接口的泛型类型就是我们分片键的类型RangeShardingAlgorithm<Long>
*/
public class MyRangeDataBaseShardingAlgorithm implements RangeShardingAlgorithm<Long> {
/**
*
*
* @param collection 这个是我们传入的库名，因为我们分库了，所以这里需要传入哪些真实表的表名
* @param rangeShardingValue 这个参数是我们指定的分片键和他的值
* @return 这里就是我们要查询那些库，可以全部，也可以我们根据特定的sql来指定查询那些库
*/
@Override
public Collection<String> doSharding(Collection<String> collection, RangeShardingValue<Long> rangeShardingValue) {
System.out.println(collection);
System.out.println("-------------database---------------------");
System.out.println(rangeShardingValue);
System.out.println("----------------------------------");
return c;
}
}
database-strategy.standard.precise-algorithm-class-name：
package com.roy.ShardingSphereDemo.algorithm.database;
import org.apache.shardingsphere.api.sharding.standard.PreciseShardingAlgorithm;
import org.apache.shardingsphere.api.sharding.standard.PreciseShardingValue;
import java.util.Collection;
/**
* 这里是，当我们的分片键查询条件是单条数据查询的时候，他就会调用这个算法
* 因为我们的分片键不是范围查询，他要根据这个算法判断，到底去哪个真实库查询。
* 这里接口的泛型类型就是我们分片键的类型PreciseShardingAlgorithm<Long>
*/
public class MyPreciseDataBaseShardingAlgorithm implements PreciseShardingAlgorithm<Long> {
/**
*
* @param collection 这个参数是传进来的数据库的名字，就是我们在配置文件中指定的那个m1和m2
* @param preciseShardingValue 这个参数是我们指定的分片键和他的值
* @return 返回的就是我们要查询那个数据库，因为是单条查询，必须要指定要走的库
*/
@Override
public String doSharding(Collection<String> collection, PreciseShardingValue<Long> preciseShardingValue) {
System.out.println(collection);
System.out.println("----------------------------------");
System.out.println(preciseShardingValue);
System.out.println("----------------------------------");
//这里就是拿到我们的分片键的值，因为是但条件查询，所以可以直接获取传入的值
Long value = preciseShardingValue.getValue();
value=value%2;
//注意这里，我们是写死的，其实可以通过配置文件的引入进来，因为我们默认我们的库名为m开头
String databasePre ="m";
//这样我们就拿到了我们的精确的要访问的库名了。
String databaseName = databasePre+value;
return databaseName;
}
}
然后我们执行如下范围查询测试代码：
@Test
void queryCourse() {
QueryWrapper<Course> wrapper = new QueryWrapper();
wrapper.between(true,"cid",1,100).between(true,"cname","233223","xdfsdf");
List<Course> courses = courseMapper.selectList(wrapper);
courses.forEach(System.out::println);
}
然后再看看执行效果
可以看到，只能看到分片键，但是看不见我们传入的cname，因为他不是分片键
然后我们在看看单条查询的测试代码
@Test
void queryCourseDan() {
QueryWrapper<Course> wrapper = new QueryWrapper();
wrapper.eq("cid",1520071131371982849L);
List<Course> courses = courseMapper.selectList(wrapper);
courses.forEach(System.out::println);
}
在来看看执行结果：
确实是精确查询
2.关于order
order不管是分片键还是非分片键都是可以使用的。应该是shardingsphere帮我们聚合了。
这事 以cid就是我们分片键来排序的
如下是以非分片键进行的排序
3.complex
这是一个复杂的分片策略，就是之前我们的stand只能使用单个分片键。但是如果是complex就能配置多个分片键
这里我们先看个东西。所有的分片算法都是继承自同一个父类接口：
我们可以看看他的继承树
然后我们在看看table-strategy和database-strategy后边跟的几个参数
都可以看到以这些属性开头的哪些接口
然后我们以ComplexKeysShardingAlgorithm为例，看看他的实现：
public interface ComplexKeysShardingAlgorithm<T extends Comparable<?>> extends ShardingAlgorithm {
Collection<String> doSharding(Collection<String> var1, ComplexKeysShardingValue<T> var2);
}
可以看到 他的泛型要求是，只要是继承了Comparable的类就可以。
因此，当我们使用complex属性指定多个分片键的时候，我可以将他们封装成一个对象。如下我们将cid和cname作为分片键：如下所示：
package com.roy.ShardingSphereDemo.key;
import lombok.Data;
/*
这里我们继承了Comparable接口
*/
@Data
public class Key implements Comparable<Key>{
private Long cid;
private String cname;
@Override
public int compareTo(Key that) {
if (this.getCid() == null && that.getCid() == null) {
// pass
} else if (this.getCid() == null) {
return -1;
} else if (that.getCid() == null) {
return 1;
} else {
int cidComparison = this.getCid().compareTo(that.getCid());
if (cidComparison != 0) {
return cidComparison < 0 ? -1 : 1;
}
}
if (this.getCname() == null && that.getCname() == null) {
return 0;
} else if (this.getCname() == null) {
return -1;
} else if (that.getCname() == null) {
return 1;
} else {
return this.getCname().compareTo(that.getCname());
}
}
}
这样我们这个封装类就能作为我们算法的泛型了：
/**
* 多分片键的库的匹配实现算法
*/
public class MyComplexDataBaseShardingAlgorithm implements ComplexKeysShardingAlgorithm<Key> {
@Override
public Collection<String> doSharding(Collection<String> collection, ComplexKeysShardingValue<Key> complexKeysShardingValue) {
System.out.println("------------------------database------------------------------------");
System.out.println(collection);
System.out.println(complexKeysShardingValue);
//这里就是返回的我们所有的分片键和对应的分片值。可以看到他是个map结构
Map<String, Range<Key>> columnNameAndRangeValuesMap = complexKeysShardingValue.getColumnNameAndRangeValuesMap();
//这样我们就能根据这个map来确定我们要怎么匹配我们的数据库了。通过那种方式
//我们这里没做特殊处理，意思就是匹配所有的库，因为我们直接返回的collection
return collection;
}
}
我们表的算法实现和上边的这个一样，只不过改一下类的名字就好了
package com.roy.ShardingSphereDemo.algorithm.complex;
import com.google.common.collect.Range;
import com.roy.ShardingSphereDemo.key.Key;
import org.apache.shardingsphere.api.sharding.complex.ComplexKeysShardingAlgorithm;
import org.apache.shardingsphere.api.sharding.complex.ComplexKeysShardingValue;
import java.util.Collection;
import java.util.Map;
/**
* 复杂分片的表计算算法
*/
public class MyComplexTableShardingAlgorithm implements ComplexKeysShardingAlgorithm<Key> {
@Override
public Collection<String> doSharding(Collection<String> collection, ComplexKeysShardingValue<Key> complexKeysShardingValue) {
System.out.println("------------------------table------------------------------------");
System.out.println(collection);
System.out.println(complexKeysShardingValue);
//这里就是返回的我们所有的分片键和对应的分片值。可以看到他是个map结构
Map<String, Range<Key>> columnNameAndRangeValuesMap = complexKeysShardingValue.getColumnNameAndRangeValuesMap();
//这样我们就能根据这个map来确定我们要怎么匹配我们的数据库的表了。通过那种方式
return collection;
}
}
然后修改我们的配置文件，将之前的spring.shardingsphere.sharding.tables.course.database-strategy.stand去掉，增加我们的spring.shardingsphere.sharding.tables.course.database-strategy.complex
spring.shardingsphere.sharding.tables.course.database-strategy.complex.sharding-columns=cid,cname
spring.shardingsphere.sharding.tables.course.database-strategy.complex..algorithm-class-name=com.roy.ShardingSphereDemo.algorithm.complex.MyComplexDataBaseShardingAlgorithm
spring.shardingsphere.sharding.tables.course.table-strategy.complex.sharding-columns=cid,name
spring.shardingsphere.sharding.tables.course.table-strategy.complex.algorithm-class-name=com.roy.ShardingSphereDemo.algorithm.complex.MyComplexTableShardingAlgorithm
测试代码如下：
@Test
void queryCourse() {
QueryWrapper<Course> wrapper = new QueryWrapper();
//指定了两个分片键
wrapper.ge("cid",1).between("cname","shardingSphere1","shardingSphere6");
List<Course> courses = courseMapper.selectList(wrapper);
courses.forEach(System.out::println);
}
4.hint
最后一个属性就是hint，他的作用就是，当我们要进行分片的键不是表中的属性的时候，比如我们要将进行分片的键是user_id，但是order表中却没有这个字段的时候，我们就要使用hint的分片类型了。
其中关于算法的实现，就是继承HintShardingAlgorithm这个接口，这个接口除了名字，其他的和上边没啥区别。
public class MyHintShardingAlgorithm implements HintShardingAlgorithm<Long> {
/*
对这个方法做以下说明：
第一个参数：Collection<String>中方的是每个库中，所有的分片表。比如：
我们有m1和m2两个库，course_1,course_2,course_3，三个分片表。他们之间
的关系如下：
spring.shardingsphere.sharding.tables.course.actual-data-nodes=m1.course_1,m2.course_2,m1.course_3
我们通过这个配置文件来指定。
那么这个方法就会被调用两次，因为我们有两个库，其中第一次传入的是m1库的course_1和course_3
第二次传入的是m2.course_2。
第二个参数为： 我们通过hitManager的addTableShardingValue这个方法传入进来的参数
这样我们就可以根据库-表-参数，来指定去哪里插入或者搜索我们想要的数据了
*/
@Override
public Collection<String> doSharding(Collection<String> collection, HintShardingValue<Long> hintShardingValue) {
System.out.println("----------------------------------------------hint----tables-------------------------");
System.out.println(hintShardingValue);
System.out.println(collection);
//获取我们测试代码中传入的值，我们就可以根据这个值来分片
hintShardingValue.getValues();
return collection;
}
}
我们的测试代码如下：
@Test
void addCourseHint() {
for(int i = 0 ; i < 10 ; i++) {
//我们要通过这个类，把我们想要的不在表中的参数传进来
HintManager hintManager = HintManager.getInstance();
//这里是指定逻辑库，以及要进行分库判断的值
hintManager.addDatabaseShardingValue("m",1);
//这里是指定逻辑表，以及要进行表判断的值
hintManager.addTableShardingValue("course",System.currentTimeMillis());
Course c = new Course();
c.setCstatus("1");
c.setCname("shardingSphere");
c.setUserId(Long.valueOf(""+(1000+i)));
courseMapper.insert(c);
//记得关闭，因为他把数据放到的是localThread中的，所以要清理
hintManager.close();
}
}
我们先看看我们MyHintShardingAlgorithm这个算法中的我们打印的输出：
正好可以印证我们MyHintShardingAlgorithm中的代码注释说明。我们这样就能根据传入的值和表名来进行判断是否要使用这个表了
4.绑定表
指分片规则一致的主表和子表。例如： t_order 表和 t_order_item 表，均按照 order_id 分片,绑定表之间的分区键完全相同，则此两张表互为绑定表关系（也就是当我们链表t_order和t_order_item的时候，t_order_1的只会去关联t_order_item_1，不会去关联t_order_item_2）。绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将大大提升。举例说明，如果SQL为：
SELECT i.* FROM t_order o JOIN t_order_item i ON o.order_id=i.order_id WHERE o.order_id in (10,11);
在不配置绑定表关系时，假设分片键 order_id 将数值10路由至第0片，将数值11路由至第1片，那么路由后的SQL应该为4条，它们呈现为笛卡尔积：
SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in(10, 11);
SELECT i.* FROM t_order_0 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in(10, 11);
SELECT i.* FROM t_order_1 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in(10, 11);
SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in(10, 11);
在配置绑定表关系后，路由的SQL应该为2条：
SELECT i.* FROM t_order_0 o JOIN t_order_item_0 i ON o.order_id=i.order_id WHERE o.order_id in(10, 11);
SELECT i.* FROM t_order_1 o JOIN t_order_item_1 i ON o.order_id=i.order_id WHERE o.order_id in(10, 11);
也就是t_order_0绑定t_order_item_0。t_order_1绑定t_order_item_1。不会再出现笛卡尔积了。
配置方式如下：
# 设置绑定表
spring.shardingsphere.sharding.binding-tables[0] = t_order,t_order_item
当我们有多个绑定关系表的时候，就可以通过如下的方式进行配置：
spring.shardingsphere.rules.sharding.binding-tables[0]= # 绑定表规则列表
spring.shardingsphere.rules.sharding.binding-tables[1]= # 绑定表规则列表
spring.shardingsphere.rules.sharding.binding-tables[x]= # 绑定表规则列表
对于没有分片的表，我们也不需要做这些设置
5.公共表也叫广播表
公共表属于系统中数据量较小，变动少，而且属于高频联合查询表的依赖表（这句话很重要，阐明了广播表的作用）。参数表、数据字典表等属于此类型。可以将这类表在每个数据库都保存一份，所有更新操作都同时发送到所有分库执行。接下来看一下如何使用Sharding-JDBC实现公共表
广播表的配置策略如下：
spring.shardingsphere.rules.sharding.broadcast-tables[0]= # 广播表规则列表
spring.shardingsphere.rules.sharding.broadcast-tables[1]= # 广播表规则列表
spring.shardingsphere.rules.sharding.broadcast-tables[x]= # 广播表规则列表
对于广播表我们没有必要设置哪些费劲的策略。
这里，对于那些非分片表，但是需要关联查询的，都要在广播表中配置一下，否则会报错，找不到分片策略
如果我们使用了如下的配置：
#配置我们的m1为默认的数据库。
spring.shardingsphere.sharding.default-data-source-name=m1
这样，对于分分片的表的操作，都只会取我们的m1来进行读取了。我们也不需要在每个库中都弄一个一样的表
5.主从配置
我们使用shardingSphere可以实现我们的主从配置，也就是读写分离。
具体的配置如下：
#指定数据库的名称
spring.shardingsphere.datasource.names=master0,slave1,slave2,master1,slave3,slave4
#配置我们的第一个主库
spring.shardingsphere.datasource.master0.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.master0.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.master0.jdbc-url=jdbc:mysql://ip:port/order1?useSSL=false
spring.shardingsphere.datasource.master0.username=root
spring.shardingsphere.datasource.master0.password=root
#配置我们的第儿二个主库
spring.shardingsphere.datasource.master1.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.master1.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.master1.jdbc-url=jdbc:mysql://ip:port/order2?useSSL=false
spring.shardingsphere.datasource.master1.username=root
spring.shardingsphere.datasource.master1.password=root
#配置我们的第一个从库
spring.shardingsphere.datasource.slave1.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.slave1.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.slave1.jdbc-url=jdbc:mysql://ip:port/order1?useSSL=false
spring.shardingsphere.datasource.slave1.username=root
spring.shardingsphere.datasource.slave1.password=root
#配置我们的第二个从库
spring.shardingsphere.datasource.slave2.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.slave2.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.slave2.jdbc-url=jdbc:mysql://ip:port/order1?useSSL=false
spring.shardingsphere.datasource.slave2.username=root
spring.shardingsphere.datasource.slave2.password=root
#配置我们的第三个从库
spring.shardingsphere.datasource.slave3.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.slave3.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.slave3.jdbc-url=jdbc:mysql://ip:port/order2?useSSL=false
spring.shardingsphere.datasource.slave3.username=root
spring.shardingsphere.datasource.slave3.password=root
#配置我们的第四个从库
spring.shardingsphere.datasource.slave4.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.slave4.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.slave4.jdbc-url=jdbc:mysql://ip:port/order2?useSSL=false
spring.shardingsphere.datasource.slave4.username=root
spring.shardingsphere.datasource.slave4.password=root
#master-slave，如果我们是一主多从，可以这么配置
#spring.shardingsphere.masterslave.name=datasource
#spring.shardingsphere.masterslave.master-data-source-name=master0
#spring.shardingsphere.masterslave.slave-data-source-names=slave1,slave2
#spring.shardingsphere.masterslave.load-balance-algorithm-type=ROUND_ROBIN
#spring.shardingsphere.masterslave.name=datasource
#spring.shardingsphere.masterslave.master-data-source-name=master1
#spring.shardingsphere.masterslave.slave-data-source-names=slave3,slave4
#spring.shardingsphere.masterslave.load-balance-algorithm-type=ROUND_ROBIN
spring.shardingsphere.sharding.tables.c_order.key-generator.column=id
spring.shardingsphere.sharding.tables.c_order.key-generator.type=SNOWFLAKE
#分库分表
spring.shardingsphere.sharding.tables.c_order.actual-data-nodes=master$->{0..1}.c_order$->{0..1}
spring.shardingsphere.sharding.tables.c_order.database-strategy.inline.sharding-column=id
spring.shardingsphere.sharding.tables.c_order.database-strategy.inline.algorithm-expression=master$->{id % 2}
spring.shardingsphere.sharding.tables.c_order.table-strategy.inline.sharding-column=user_id
spring.shardingsphere.sharding.tables.c_order.table-strategy.inline.algorithm-expression=c_order$->{user_id % 2}
#读写分离，这里就是我们主从库之间的关联关系配置
spring.shardingsphere.sharding.master-slave-rules.master0.master-data-source-name=master0
spring.shardingsphere.sharding.master-slave-rules.master0.slave-data-source-names=slave1,slave2
# 配置从库选择策略，提供轮询与随机，这里选择用轮询
spring.shardingsphere.sharding.master-slave-rules.master0.load-balance-algorithm-type=round_robin
#这里是配置我们规则的名字
spring.shardingsphere.sharding.master-slave-rules.master0.name=ms1
spring.shardingsphere.sharding.master-slave-rules.master1.master-data-source-name=master1
spring.shardingsphere.sharding.master-slave-rules.master1.slave-data-source-names=slave3,slave4
注意，读写分离要基于mysql的主从架构来设置的
6、ShardingSphere的SQL使用限制
参见官网文档: https://shardingsphere.apache.org/document/current/cn/features/sharding/use-norms/sql/文档中详细列出了非常多ShardingSphere目前版本支持和不支持的SQL类型。这些东西要经常关注。
当然一些不支持的sql，我们可以用hint来进行处理，但是hint也不是能处理所有的sql
7.分库分表带来的问题
1、分库分表，其实围绕的都是一个核心问题，就是单机数据库容量的问题。我们要了解，在面对这个问题时，解决方案是很多的，并不止分库分表这一种但是ShardingSphere的这种分库分表，是希望在软件层面对硬件资源进行管理，从而便于对数据库的横向扩展，这无疑是成本很小的一种方式。
大家想想还有哪些比较好的解决方案?
2、一般情况下，如果单机数据库容量撑不住了，应先从缓存技术着手降低对数据库的访问压力。如果缓存使用过后，数据库访问量还是非常大，可以考虑数据库读写分离策略。如果数据库压力依然非常大，且业务数据持续增长无法估量，最后才考虑分库分表，单表拆分数据应控制在1000万以内。
当然，随着互联网技术的不断发展，处理海量数据的选择也越来越多。在实际进行系统设计时，最好是用MySQL数据库只用来存储关系性较强的热点数据，而对海量数据采取另外的一些分布式存储产品。例如PostGreSQL、VoltDB甚至HBase、Hive、ES等这些大数据组件来存储。
3、从上一部分ShardingJDBC的分片算法中我们可以看到，由于SQL语句的功能实在太多太全面了，所以分库分表后，对SQL语句的支持，其实是步步为艰的，稍不小心，就会造成SQL语句不支持、业务数据混乱等很多很多问题。所以，实际使用时，我们会建议这个分库分表，能不用就尽量不要用。
如果要使用优先在OLTP场景下使用，优先解决大量数据下的查询速度问题。而在OLAP场景中，通常涉及到非常多复杂的SQL，分库分表的限制就会更加明显。当然，这也是ShardingSphere以后改进的一个方向。
4、如果确定要使用分库分表，就应该在系统设计之初开始对业务数据的耦合程度和使用情况进行考量，尽量控制业务SQL语句的使用范围，将数据库往简单的增删改查的数据存储层方向进行弱化。并首先详细规划垂直拆分的策略，使数据层架构清晰明了。而至于水平拆分，会给后期带来非常非常多的数据问题，所以应该谨慎、谨慎再谨慎。一般也就在日志表、操作记录表等很少的一些边缘场景才偶尔用用。
若有收获，就点个赞吧
0 人点赞
