前言

前几天老顾与小伙伴们分享了sharding-jdbc的水平分表功能，今天我们继续分享一些水平分库，以及读写分离的功能，以及如何解决读写延迟问题。小伙伴就继续往下看吧。

分库分表业务需求

分片规则

在做分库分表时，首先要定义好我们的分片规则，从业务逻辑上面要思路清晰。我们基于上一篇文章的案例，继续进行分库：

分库规则：根据用户user_id为偶数时将数据添加到course_db1中；为奇数时将数据添加到course_db2中。

分表规则：根据课程cid为偶数时将数据添加到course_1中；为奇数时将数据添加到course_2中

 

创建数据库

创建数据库以及表，和上一篇文章的一样。

 

配置分片

我们在基于上一篇的配置文件中，进行分库的需求改造

定义数据源

 

上图的配置就是配置了2个数据库源，并定义名称m1、m2。

分布节点

 

上面重新定义了course逻辑表的真实的分布节点，根据表达式course分布在m1、m2数据库中，并且表名为course_1、course_2

分库规则

 

上面在原来的基础上面，增加了分库的策略规则。分片配置就此结束。

改造测试代码

 

测试代码对userId进行了改造。

执行测试

我们可以看到执行日志，符合我们之前定义的分片策略

 

 

 

读写分离概念

一般熟知 Mysql 数据库的朋友知道，当表的数据量达到千万级时，SQL 查询会逐渐变的缓慢起来，往往会成为一个系统的瓶颈所在。为了提升程序的性能，除了在表字段建立索引（如主键索引、唯一索引、普通索引等）、优化程序代码以及 SQL 语句等常规手段外，利用数据库主从读写分离（Master/Slave）架构：

就是为了缓解数据库压力，将写入和读取操作分离为不同数据源，写库称为主库，读库称为从库，一主库可配置多从库。

 

上图所表达的：读都落在从库，写落在主库

读写分离配置

mysql的主从配置，这里老顾就不讲了，小伙伴们可以去上网查看。我们这里就给出读写分离的配置

 

上面的spring.shardingsphere.masterslave是核心配置，配置还是相对简单的。

select查询代码测试，走的是slave库

[ main] ShardingSphere-SQL : Rule Type: master-slave
[ main] ShardingSphere-SQL : SQL: SELECT  cid,cname,userId,status  FROM course ::: DataSources: slave

insert新增、update修改、delete删除，走的是master库

[ main] ShardingSphere-SQL : Rule Type: master-slave
[ main] ShardingSphere-SQL : SQL: delete from course where cid=1 ::: DataSources: master

读写分离延迟问题

读写分离架构中经常出现，那就是读延迟的问题如何解决？

刚插入一条数据，然后马上就要去读取，这个时候有可能会读取不到？

归根到底是因为主节点写入完之后数据是要复制给从节点的，读不到的原因是复制的时间比较长，也就是说数据还没复制到从节点，你就已经去从节点读取了，肯定读不到。

mysql5.7 的主从复制是多线程了，意味着速度会变快，但是不一定能保证百分百马上读取到，这个问题我们可以有两种方式解决：

（1）业务层面妥协，是否操作完之后马上要进行读取

（2）对于操作完马上要读出来的，且业务上不能妥协的，我们可以对于这类的读取直接走主库，当然Sharding-JDBC也是考虑到这个问题的存在，所以给我们提供了一个功能，可以让用户在使用的时候指定要不要走主库进行读取。在读取前使用下面的方式进行设置就可以了：

public List<Course> getCourse() {// 强制路由主库HintManager.getInstance().setMasterRouteOnly();return this.list();
}

核心的代码就是

HintManager.getInstance().setMasterRouteOnly();

总结