mysql读写分离实现方式_MySQL实现读写分离的两种经典方案

前言

如果主库只负责所有的读写操作，而从库只实现备份功能，这样的主从架构看起来性价比似乎不是很高。

我们所希望的主从架构是，当我们在写数据时，请求全部发到Master节点上，当我们需要读数据时，请求全部发到Slave节点上。

并且多个Slave节点最好可以存在负载均衡，那么这样的架构就能够让集群的效率最大化。

实现读写分离，实际上有两种经典方式

第一种方式即我们在代码层实现逻辑，对到达的读/写请求进行解析，针对性地分发到不同的数据库中，从而实现读写分离；

第二种方式是基于类似MyCat中间件来帮助我们实现读写分离的效果；

最简单的主从架构

代码层来实现读写分离

默认大家对MyBatis和Spring都有所了解，最简单的实现方式：

(1)Spring注入数据源，包括Master-Slave；

(2)手写MyBatis拦截器，判断一个SQL语句是读还是写；

(3)选择对应的数据源进行执行

实现的方式很直观，但弊端也显而易见，这样对代码的侵入性太强，当需要对数据源进行增删时，一定会对代码造成影响。这不但会给开发人员造成很大的困扰，而且不符合软件设计的开闭原则。

专业的事情交给专业的人，这也是像MyCat这样的中间件出现的原因。

通过MyCat来实现读写分离

这种方式最主要的特点就是我们在整体架构中新建了一个虚拟节点，所有的请求先到达这个虚拟节点上，由这个虚拟节点来转发读写请求到相应的数据库。

通过MyCat这样的专业中间件，可以更加有效率地实现读写分离、故障转移等功能。

优劣分析

关于这两种方式的优劣，相信如果仔细看完这篇文章的同学都会有一个深刻的体会。

使用MyCat中间件实现读写分离，优点十分明显，我们只需要进行配置就可以享受读写分离带来的效率的提升，不用写一行代码，并且当主库宕机时，我们还可以通过配置的方式进行主从库的自动切换，这样即使主库宕机我们的整个集群也不会丧失写的功能。

其缺点当然是需要我们维护这样一个虚拟节点，增加了运维成本，但相比较它所带来的好处而言，这完全是可以接受的。

Ending

我是无忌，Stay Tuned ！！各位的喜爱是对我最大的鼓励，下篇文章再见~