开足码力,码动人生,微信搜索【 程序员大帝 】,关注这个一言不合就开车的的代码界老司机
本文 GitHub上已经收录 https://github.com/BeKingCoding/JavaKing , 一线大厂面试核心知识点、我的联系方式和技术交流群,欢迎Star和完善
前言
如果主库只负责所有的读写操作,而从库只实现备份功能,这样的主从架构看起来性价比似乎不是很高。
我们所希望的主从架构是,当我们在写数据时,请求全部发到Master节点上,当我们需要读数据时,请求全部发到Slave节点上。
并且多个Slave节点最好可以存在负载均衡,那么这样的架构就能够让集群的效率最大化。
实现读写分离,实际上有两种经典方式
第一种方式即我们在代码层实现逻辑,对到达的读/写请求进行解析,针对性地分发到不同的数据库中,从而实现读写分离;
第二种方式是基于类似MyCat中间件来帮助我们实现读写分离的效果;
最简单的主从架构
代码层来实现读写分离
默认大家对MyBatis和Spring都有所了解,最简单的实现方式:
(1)Spring注入数据源,包括Master-Slave;
(2)手写MyBatis拦截器,判断一个SQL语句是读还是写;
(3)选择对应的数据源进行执行
实现的方式很直观,但弊端也显而易见,这样对代码的侵入性太强,当需要对数据源进行增删时,一定会对代码造成影响。这不但会给开发人员造成很大的困扰,而且不符合软件设计的开闭原则。
专业的事情交给专业的人,这也是像MyCat这样的中间件出现的原因。
通过MyCat来实现读写分离
这种方式最主要的特点就是我们在整体架构中新建了一个虚拟节点,所有的请求先到达这个虚拟节点上,由这个虚拟节点来转发读写请求到相应的数据库。
通过MyCat这样的专业中间件,可以更加有效率地实现读写分离、故障转移等功能。
优劣分析
关于这两种方式的优劣,相信如果仔细看完这篇文章的同学都会有一个深刻的体会。
使用MyCat中间件实现读写分离,优点十分明显,我们只需要进行配置就可以享受读写分离带来的效率的提升,不用写一行代码,并且当主库宕机时,我们还可以通过配置的方式进行主从库的自动切换,这样即使主库宕机我们的整个集群也不会丧失写的功能。
其缺点当然是需要我们维护这样一个虚拟节点,增加了运维成本,但相比较它所带来的好处而言,这完全是可以接受的。
《Offer收割机》系列持续更新,也会定期分享互联网常用技术栈相关的文章,GitHub 上已经收录 https://github.com/BeKingCoding/JavaKing ,讲解一线大厂面试要求的核心知识点、并有对标阿里P7级别的成长体系脑图,欢迎加入技术交流群,我们一起有点东西。
我是一言不合就开车的代码界老司机无忌。创作不易,各位的支持和认可,就是我创作的最大动力,我们下篇文章见!