读写分离
- 基于主从复制的读写分离，是我们在单机环境下，数据库的性能到瓶颈了，我们进行读写分离，提高后台服务，存储这一块的增删改查的并发的处理能力。
- 有一个库专门写操作，从库专门读取操作，主库的数据更改通过主从复制同步到从库。
读写分离就是在主服务器上修改，数据会同步到从服务器，从服务器只能提供读取数据，不能写入，实现备份的同时也实现了数据库性能的优化，以及提升了服务器安全。（读操作特别多，而且耗时特别大 ）
-
我们把图中的客户端看作：代码 ，作为mysql client的角色，通过mysql 提供的API，用mysql自定义的基于TCP的数据协议，简称mysql协议。我们的一些数据就存在mysql数据库，服务通过操作mysql的API和mysql数据库 进行 通信。双方的数据交互遵守mysql协议。
-
最初，我们只有一台MySQL服务器，所有数据的增删改查都是在一台机器上进行，随着服务越来越多的人使用，流量越来越大，需要并发能力的不断提升，如果数据库的性能到瓶颈了，我们就要进行读写分离的操作。读操作如果特别多，耗时特别大。
图中的MySQL主服务端专门做写操作。
下面连着2个mysql服务器专门做读操作。
1主2从。
在A机器上写，在B, C机器上读
如果我们在客户端上 直接用代码写死，insert update之类的操作，在A上做，show，select操作在B，C上做，相当于代码和主从环境就是强绑定的状态，代码的稳定性不太好，因为和环境强相关了，必须得知道哪个机器是写操作的主库，哪个机器是读操作的从库，由代码来选择， 比如说哪个机器挂掉了也不知道，没人帮忙动态监测。
所以，用代码 肯定是不合适。
所以实际上，读写分离，分库分表都是需要依赖数据库中间件—》mycat
mycat就是代理服务器的角色。
也是遵循mysql通信协议的。
配置读写分离，我们在客户端上的代码不用做任何变更，代码上不需要区分哪个是读，哪个是写，代码直接访问的是mycat
作为客户端来说，实际上区分不出来连的是mycat还是MySQL，因为通信都是遵守的是mysql通信协议。所以不用进行区分。
客户端通过mysql的API发送的所有的增删改查请求都是到mycat，在mycat配置读写分离。
mycat对客户端的请求进行解析，如果是写操作，就把这个操作发到主服务器上，如果发现是读操作，就把这个操作发到从服务器上。（读写分离）
主库上的数据通过主从复制同步到从库。
主从复制是在mysql数据库上配置的。
在mycat上就是要配置主服务器和从服务器的信息。
有3种情况：
我们配置的是1主多从。
- 当写库挂了，配置上还可以立马把一个从库直接变身成一个写库。然后从库和从库还要配置一下主从复制。
多主多从，就是mycat后面挂 了2套环境（1主2从 为1套）。
M1和S1，S2之间要配置主从复制；
M2和S3，S4之间也要配置主从复制；
M1和M2之间也配置成互为主从。（主服务器之间也开启了主从复制）
- 如果其中1套的主库挂了（它对应的从库也就不能用了），此时mycat会自动切到另一套环境。 因为M1和M2之间之前也是配置成互为主从的。
高可用 容灾能力强
-
MySQL（3306端口）
-
mycat有两个比较重要的端口：
数据端口8066，管理端口9066 -
归功于mycat (数据端口（登录上来和登录mysql一样，看到的是库表）：8066（相当于客户端现在连的是8066端口（之前练得是3306），这个端口是可以改的）
-
管理端口 登录这个管理端口可以查看mycat正在工作的所有状态以及和后端服务器的连接，以及连接数据源的状态 9066）
目前较为常见的MySQL读写分离方式有：
- 程序代码内部实现
- 引入中间代理层
- MySQL_proxy
- Mycat
