（1）回顾：
    上面说到，搭建一套MySQL主从复制架构之后，可以实现高可用的效果，也就是说主节点宕机，可以切换去读写从节点，因为主从节点基本是一致的，当然暂时也就只能说基本一致，如果 做了MySQL这个主从复制架构后，除了高可用之外，还有什么作用呢？其实这就得说到读写分离架构了，这个读写分离结构，也是依赖于MySQL的主从复制架构的。
    读写分离架构的意思是，Java业务系统可以往主节点写入数据，但是去从节点查询数据，把读写操作做一个分离，分离到两台MySQL服务器上去，一台服务器专门写从数据，然后复制到从节点， 另一台服务器专门查询数据。


    （2）为什么做读写分离？
    假设MySQL单机服务器配置是8核16G，每秒最多能抗4000读写请求，现在假设真实的业务负载已经达到，每秒有2500写请求+2500读请求，也就是5000读写请求，觉得如果都放一台MySQL服务器 是扛不住的，所以此时利用主从复制架构，搭建起来读写分离架构，就可以让每秒2500写请求落到主节点那台服务器，2500读请求落到从节点那台服务器，用2台服务器扛下来每秒5000的读写请求。
    现在问题来了，大部分Java业务系统都是读多写少，读请求远远多于写请求，接着随着业务系统日益发展，读请求越来越多，每秒可能有6000读请求，一个从节点服务器也坑不下来，怎么办？ MySQL的主从复制架构，是支持一主多从的，所以此时可以再在一台服务器部署一个从节点，去主节点复制数据过来，此时就有2个从节点了，然后每秒6000读请求就可以落到2个从节点上去了，每台服务器主要接收每秒3000的读请求。
    Java业务系统每秒以2500的TPS写入主库，然后主库会复制数据到从库，接着每秒6000QPS的读请求分散在两个从库上，这就是主从复制架构的另一个经典应用场景，就是读写分离，通过读写分离 ，可以扛下很高的读请求。
    而且上述架构下，还可以融合高可用架构进去，因为有多个从库，当主库宕机的时候，可以通过中间件把一个从库切换为主库，此时Java业务系统可以继续运行，在实现读写分离的场景下，还可以 同时实现高可用，不过其实一般在项目中，高可用架构是必须做的，但是读写分离架构并不是必须的，因为大多数公司来说，读请求QPS并没那么高，远远达不到每秒几千那么夸张，但是高可用是必须得做得， 因为必须保证主库宕机后，有另外一个从库可以接管提供服务，避免Java业务系统中断运行。
    除此之外，这个从库其实还有很多其他应用场景，比如可以挂一个从库，专门用来跑一些报表SQL语句，那种SQL语句往往有上百行之多，运行要好几秒，所以可以专门给他一个从库来跑，也可以专门 部署一个从库，去进行数据同步之类的操作。

    （3）MySQL主从复制的一个基本工作原理：
    MySQL自己在执行增删改的时候会记录binlog日志，所以binlog日志里就记录了所有数据增删改的操作，然后从库有一个IO线程，这个IO线程会负责跟主库建立一个tcp连接，接着请求主库传输binlog日志给自己，这个时候主库上有一个IO dump线程，就会负责通过这个TCP连接把binlog日志传输给从库的IO线程，接着从库的IO线程会把读取到的binlog日志数据写入到自己本地的relay日志文件中去， 然后从库上另外有一个SQL线程会读取relay日志里的内容，进行日志重做，把所有在主库执行过的增删改操作，在从库做一遍，达到一个还原数据的过程。
    到此为止，对MySQL主从复制的原理也就有一个基本的了解了，简单来说，只要给主节点挂上一个从节点，从节点的IO线程就会给主节点建立网络连接，然后请求主节点传输binlog日志，主节点的 IO dump线程就负责传输binlog日志给从节点，从节点收到日志后就可以回放增删改操作恢复数据。

    知识点1：IO dump线程是单线程， 一个主库理论上能支撑无穷个从库，但一般2-5个从节点。
    知识点2：一个dump线程和多个从库的io线程建立连接。