为什么需要主从同步
如果我们的目的在于提升数据库高并发访问的效率，
- 首先需要考虑的应该是如何优化你的 SQL 和索引，这种方式简单有效。
- 其次才是采用缓存的策略，比如使用 Redis，通过 Redis 高性能的优势将热点数据保存在内存数据库中，提升读取的效率。
- 最后才是对数据库采用主从架构，进行读写分离。
主从同步作用：
- 读写分离
- 数据备份
- 高可用
原理
在主从复制过程中，会基于 3 个线程来操作，一个主库线程，两个从库线程。
- 二进制日志转储线程（Binlog dump thread）是一个主库线程。当从库线程连接的时候，主库可以将二进制日志发送给从库，当主库读取事件的时候，会在 Binlog 上加锁，读取完成之后，再将锁释放掉。
- 从库 I/O 线程会连接到主库，向主库发送请求更新 Binlog。这时从库的 I/O 线程就可以读取到主库的二进制日志转储线程发送的 Binlog 更新部分，并且拷贝到本地形成中继日志（Relay log）。
- 从库 SQL 线程会读取从库中的中继日志，并且执行日志中的事件，从而将从库中的数据与主库保持同步。
主从同步的内容就是二进制日志（Binlog），它虽然叫二进制日志，实际上存储的是一个又一个事件（Event），这些事件分别对应着数据库的更新操作。
如何解决主从同步的数据一致性问题
- 异步复制 客户端提交 COMMIT 之后不需要等从库返回任何结果，而是直接将结果返回给客户端。 好处：不影响主库写的效率， 坏处：主从数据会不一致。
- 半同步复制 客户端提交 COMMIT 之后不直接将结果返回给客户端，而是等待至少有一个从库接收到了 Binlog，并且写入到中继日志中，再返回给客户端。 好处：提高了数据的一致性， 坏处：相比于异步复制来说，至少多增加了一个网络连接的延迟，降低了主库写的效率。
3. 组复制
首先我们将多个节点共同组成一个复制组，在执行读写（RW）事务的时候，需要通过一致性协议层（Consensus 层）的同意，也就是读写事务想要进行提交，必须要经过组里“大多数人”（对应 Node 节点）的同意，大多数指的是同意的节点数量需要大于（N/2+1），这样才可以进行提交，而不是原发起方一个说了算。而针对只读（RO）事务则不需要经过组内同意，直接 COMMIT 即可。
此文章为4月Day27学习笔记，内容来源于极客时间《SQL必知必会》
