462-MySQL(读写分离原理)

读写分离

基于主从复制的读写分离,是我们在单机环境下,数据库的性能到瓶颈了,我们进行读写分离,提高后台服务,存储这一块的增删改查的并发的处理能力。有一个库专门写操作,从库专门读取操作,主库的数据更改提供主从复制同步到从库。

读写分离就是在主服务器上修改,数据会同步到从服务器,从服务器只能提供读取数据,不能写入,实现备份的同时也实现了数据库性能的优化,以及提升了服务器安全。

462-MySQL(读写分离原理)_第1张图片
我们把图中的客户端看作:代码 ,作为mysql client的角色,通过mysql 提供的API,用mysql自定义的基于TCP的数据协议,简称mysql协议。我们的一些数据就存在mysql数据库,服务通过操作mysql的API和mysql数据库 进行 通信。双方的数据交互遵守mysql协议。

最初,我们只有一台MySQL服务器,所有数据的增删改查都是在一台机器上进行,随着服务越来越多的人使用,流量越来越大,需要并发能力的不断提升,如果数据库的性能到瓶颈了,我们就要进行读写分离的操作。读操作如果特别多,耗时特别大。

图中的MySQL主服务端专门做写操作。
下面连着2个mysql服务器专门做读操作。
1主2从。
在A机器上写,在B, C机器上读
462-MySQL(读写分离原理)_第2张图片

如果我们在客户端上 直接用代码写死,insert update之类的操作,在A上做,show,select操作在B,C上做,相当于代码和主从环境就是强绑定的状态,代码的稳定性不太好,因为和环境强相关了,必须得知道哪个机器是写操作的主库,哪个机器是读操作的从库,由代码来选择, 比如说哪个机器挂掉了也不知道,没人帮忙动态监测。
所以,用代码 肯定是不合适。

所以实际上,读写分离,分库分表都是需要依赖数据库中间件—》mycat
mycat就是代理服务器的角色。
也是遵循mysql通信协议的。
462-MySQL(读写分离原理)_第3张图片
配置读写分离,我们在客户端上的代码不用做任何变更,代码上不需要区分哪个是读,哪个是写,代码直接访问的是mycat

作为客户端来说,实际上区分不出来连的是mycat还是MySQL,因为通信都是遵守的是mysql通信协议。所以不用进行区分。
462-MySQL(读写分离原理)_第4张图片
客户端通过mysql的API发送的所有的增删改查请求都是到mycat,在mycat配置读写分离。
462-MySQL(读写分离原理)_第5张图片
mycat对客户端的请求进行解析,如果是写操作,就把这个操作发到主服务器上,如果发现是读操作,就把这个操作发到从服务器上。(读写分离)
主库上的数据通过主从复制同步到从库。
主从复制是在mysql数据库上配置的。

在mycat上就是要配置主服务器和从服务器的信息。
有3种情况:
462-MySQL(读写分离原理)_第6张图片
我们配置的是1主多从
当写库挂了,配置上还可以立马把一个从库直接变身成一个写库。然后从库和从库还要配置一下主从复制。

多主多从,就是mycat后面挂了2套环境(1主2从 为1套)。
462-MySQL(读写分离原理)_第7张图片

462-MySQL(读写分离原理)_第8张图片

462-MySQL(读写分离原理)_第9张图片
M1和M2之间也配置成互为主从。
如果其中1套的主库挂了(它对应的从库也就不能用了),此时mycat会自动切到另一套环境。 因为M1和M2之间之前也是配置成互为主从的。
高可用 容灾能力强
MySQL(3306端口)
归功于mycat (数据端口(登录上来和登录mysql一样,看到的是库表):8066(相当于客户端现在连的是8066端口,这个端口是可以改的)
管理端口 登录这个管理端口可以查看mycat正在工作的所有状态以及和后端服务器的连接,以及连接数据源的状态 9066

目前较为常见的MySQL读写分离方式有:
程序代码内部实现
引入中间代理层
MySQL_proxy
Mycat

你可能感兴趣的:(MySQL数据库,数据库,mysql,linux)