MySQL 读写分离原理

读写分离概念

基于主从复制的读写分离，是我们在单机环境下，数据库的性能到瓶颈了，可以通过读写分离，提高后台服务性能。存储这一块的增删改查的并发的处理能力，主库专门负责相对少的写操作，从库专门负责相对多的读操作，主库的数据更改通过主从复制同步到从库

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

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

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

图中的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正在工作的所有状态以及和后端服务器的连接，以及连接数据源的状态等