Mysql主从复制应对高并发

千万级别，索引优化，SQL查询优化

  这里有我之前写的一篇文章：https://blog.csdn.net/star1210644725/article/details/88615290

 分库分表会用到读写分离，因为使用不同的存储引擎，来分别应对读场景和写场景。

 那用到读写分离，就一定要用到主从复制，比方说我们需要向一个库里边写数据，另外一个库之读，这就考虑到数据同步的问题。

再谈谈高并发的问题 

 顾名思义，高并发就是每秒很多的事要去处理。

  其实所谓的高并发的解决方案，也就是分散压力。单机的物理瓶颈是无法突破的，就像是磁盘的读写速度，一定是有极限的，就像是CPU的处理能力是有极限的。

  那么可行的方案都有什么呢？

  利用缓存redis，redis是基于内存的数据库，它有极高的读写速度。

  利用消息队列的削峰，异步加载。

  读写分离

  除此之外就是解决物理极限的问题，既然单机不行，那就多台机器一起去处理。

今天的重头戏：主从复制

 概念是这样的，我们想要一个机器写，一个机器读（有需求的话可以一批机器读，一批机器写），那么我们需要保证两个数据库里边的数据是一样的，也就是要保证数据的一致性。那就有了一个问题：数据同步的问题，想让两个数据库数据一致，数据怎么同步呢？

 数据同步：

 master主库的写操作都会保存一份binlog（二进制日志），主库写数据的操作，在从库回放一下，就能做到同步数据了。

想自己做一遍案例的话推荐一个帖子（具体操作都有，可以跟着来）：https://www.cnblogs.com/clsn/p/8150036.html

 主从搭建好以后，再说几个坑：

 在从库里边插数据，是一个坑，会导致数据无法同步。

主从复制原理图：

 主库的所有写操作都记录在binlog里边去，从库和主库建立好联系以后，就安排一个线程负责监控binlog的动静，binglog发生改变，立马将变化的地方告诉自己的Realylog（中继日志），然后再安排一个进程负责监控中继日志的变化，一旦变化了立马更新自己的数据库内容。

  监控的线程是单线程的，这是主从复制演示问题的主要来源。mysql5.7以后可以使用多线程。