欢迎关注头条号:老顾聊技术
精品原创技术分享,知识的组装工
前言
前几天老顾与小伙伴们分享了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 getCourse() { // 强制路由主库 HintManager.getInstance().setMasterRouteOnly(); return this.list();}
核心的代码就是
HintManager.getInstance().setMasterRouteOnly();
总结
今天老顾介绍了分库策略,以及读写分离、和主从延迟的问题。希望能够帮助小伙伴;谢谢!!!
---End---