MySQL 主从复制的原理
MySQL 的主从复制依赖于 binlog ，也就是记录 MySQL 上的所有变化并以二进制形式保存在磁盘上。复制的过程就是将 binlog 中的数据从主库传输到从库上。这个过程一般是异步的
-
写入 Binlog：主库写 binlog 日志，提交事务，并更新本地存储数据。
-
同步 Binlog：把 binlog 复制到所有从库上，每个从库把 binlog 写到暂存日志中。
-
回放 Binlog：回放 binlog，并更新存储数据。
这就是“一主多从”的部署方式，你在垂直电商项目中可以用该方式抵御较高的并发读流量。另外，从库也可以作为一个备库，以避免主库故障导致的数据丢失。
MySQL 一主多从
是不是只要多增加几台从库，就可以抗住大促的并发读请求了？
从库数量增加，从库连接上来的 I/O 线程也比较多，主库也要创建同样多的 log dump 线程来处理复制的请求，对主库资源消耗比较高，同时还受限于主库的网络带宽。所以在实际使用中，一个主库一般跟 2～3 个从库（1 套数据库，1 主 2 从 1 备主），这就是一主多从的 MySQL 集群结构。
MySQL 主从复制过程也能发现，MySQL 默认是异步模式：MySQL 主库提交事务的线程并不会等待 binlog 同步到各从库，就返回客户端结果。这种模式一旦主库宕机，数据就会发生丢失。
-
同步复制：事务线程要等待所有从库的复制成功响应。
-
异步复制：事务线程完全不等待从库的复制成功响应。
-
半同步复制：MySQL 5.7 版本之后增加的一种复制方式，介于两者之间，事务线程不用等待所有的从库复制成功响应，只要一部分复制成功响应回来就行，比如一主二从的集群，只要数据成功复制到任意一个从库上，主库的事务线程就可以返回给客户端。
这种半同步复制的方式，兼顾了异步复制和同步复制的优点，即使出现主库宕机，至少还有一个从库有最新的数据，不存在数据丢失的风险。
从架构上解决主从复制延迟
-
使用数据冗余
-
使用缓存解决
-
直接查询主库
几乎所有的存储系统或数据库，基本都用了这样一套方法来解决数据复制和备份恢复等问题。
标签：主库,binlog,读多,复制,线程,MySQL,写少,从库 From： https://www.cnblogs.com/jiaozg/p/17214987.html