MySQL读写分离原理详细解析

MySQL读写分离原理详细解析 目录

• 一、读写分离的概念
• 二、引入中间件MyCat
• 三、MyCat服务端口和管理端口

一、读写分离的概念

读写分离是基于主从复制来实现的。在实际的应用环境中，肯定是读 *** 作多，就像我们在电商平台上去购买东西，可能看了100个也就买了一两个。所以读 *** 作永远比写这种更新 *** 作多很多。所以我们基于主从复制的读写分离配置，就是让一个主库专门用来做数据的修改，写的时候专门在主库上写，主库通过主从复制把数据的更改通过binlog同步到从库上去，那么其他的客户端查询的请求都会最终映射到从库上去，而我们一个主库带上两三个从库，主库专门用来做数据的更新（写 *** 作），从库专门用来做读 *** 作这样一来可以很好的分摊读写的压力，不用全部都集中在主库上，对于后端服务的并发处理能力有很大的提高，另外就是它的高可用容灾，当主库挂了以后，可以把指定的从库变成主库。

MySQL client通过mysql 提供的API，用mysql自定义的基于TCP的数据协议（简称mysql协议）与MySQL Server通信，访问MySQL Server数据库。

如果只有一台服务器（单机环境），所有数据的增删改查都是在一台服务器上进行，随着我们的服务被越来越多的人使用，流量逐渐变大，需要并发能力逐渐提升，所以如果我们发现数据库性能到瓶颈了，我们可以做读写分离 *** 作，提高后台服务。

图中的MySQL主服务器专门做写 *** 作，下面连着2个MySQL从服务器专门做读 *** 作，读请求转发到B、C，写请求转发到A。

如果我们在客户端上直接用代码写死，insert、update等写 *** 作在A上做，show、select等读 *** 作在B、C上做，相当于代码和主从环境就是强绑定的。这就导致代码的稳定性不太好，因为和环境强相关了，我们写代码得时候必须得知道哪个机器是负责写 *** 作的主库，哪个机器是负责读 *** 作的从库，由代码来选择。而这时如果有某个机器挂掉了，代码也不会知道，还是按照原来的方式转发请求，通信就会出现问题，所以把读写分离用代码实现肯定不合适。所以在实际的解决方案中，读写分离需要依赖数据库的中间件。

二、引入中间件MyCat

实际上，读写分离，分库分表都是需要依赖数据库中间件（mycat），mycat就是代理服务器的角色。

客户端实际上区分不出来连的是MyCat还是MySQL，因为通信都是遵守的是MySQL通信协议，之前怎么和MySQL通信，现在就怎么和MyCat通信，所以不用进行区分。

在MyCat上配置读写分离，我们在客户端上的代码不用做任何变更，代码上不需要区分哪个请求是读，哪个请求是写，代码直接访问的是MyCat，由MyCat解析请求，根据SQL的读写性质转发到负责相应 *** 作的服务器，实现读写分离。

在MyCat上需要配置主服务器和从服务器的信息，有3种情况：一主一从、一主多从、多主多从

一主多从场景：当写库（master）挂了，MyCat还可以马上把一个从库（slave）直接变成一个写库（master），那相当于又回到一台机器的处理，因为从库和从库之间并没有主从复制的配置，所以我们还需要把变成写库的从库还要和其他从库之间配置一下主从复制。

多主多从：

可以看到图中，MyCat服务器挂了两套环境，如果其中1套的主库宕机了（它对应的从库也就不能用了），此时MyCat会自动切到另一套环境，因为M1和M2之间也是配置成互为主从的，所以M2可以同步M1的数据，提供与M1环境完全相同的服务，所以它的高可用容灾能力是非常不错的。

三、MyCat服务端口和管理端口

MySQL的服务端口是3306，MyCat服务端口是8066（这个端口也是可以改的），也就是MySQL Client连接的是8066端口，登录8066端口看到的界面就和登录MySQL Server的3306端口一样。MyCat还有一个管理端口9066，登录这个管理端口可以查看MyCat正在工作的所有状态以及和后端服务器的连接，以及连接数据源的状态等。

到此这篇关于MySQL读写分离原理详细解析的文章就介绍到这了,更多相关MySQL读写分离 内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！