是什么？
主从架构，进行读写分离，让主服务器（Master）处理写请求，从服务器（Slave）处理读请求，这样同样可以提升数据库的并发处理能力。
为什么？
首先不是所有的应用都需要对数据库进行主从架构的设置，毕竟设置架构本身是有成本的，如果我们的目的在于提升数据库高并发访问的效率，那么首先需要考虑的应该是如何优化你的 SQL 和索引，这种方式简单有效。
其次才是采用缓存的策略，比如使用 Redis，通过 Redis 高性能的优势将热点数据保存在内存数据库中，提升读取的效率。
最后才是对数据库采用主从架构，进行读写分离。按照上面的方式进行优化，使用和维护的成本是由低到高的。主从同步设计不仅可以提高数据库的吞吐量，还有以下 3 个方面的作用。
主从同步的优势：
1. 负载均衡，减少了锁表的影响（主表写，不影响从表读）
2. 数据备份
3. 高可用性（主服务器宕机，可以切换到从服务器上）
怎么实现？
主从同步的原理
数据库中有一个重要日志文件，那就是 Binlog 二进制日志（存储的是事件，这些事件分别对应着数据库的更新操作），它记录了对数据库进行更新的事件。实际上主从同步的原理就是基于 Binlog 进行数据同步的。
在主从复制过程中，会基于 3 个线程来操作，一个主库线程，两个从库线程。二进制日志转储线程（Binlog dump thread）是一个主库线程。
当从库线程连接的时候，主库可以将二进制日志发送给从库，当主库读取事件的时候，会在 Binlog 上加锁，读取完成之后，再将锁释放掉。
从库 I/O 线程会连接到主库，向主库发送请求更新 Binlog。这时从库的 I/O 线程就可以读取到主库的二进制日志转储线程发送的 Binlog 更新部分，并且拷贝到本地形成中继日志。从库 SQL 线程会读取从库中的中继日志，并且执行日志中的事件，从而将从库中的数据与主库保持同步。
如何解决主从同步的数据一致性问题
主从之间数据复制方式：
方法 1：异步复制（提交后不等待）
异步模式就是客户端提交 COMMIT 之后不需要等从库返回任何结果，而是直接将结果返回给客户端，这样做的好处是不会影响主库写的效率，但可能会存在主库宕机，而 Binlog 还没有同步到从库的情况，也就是此时的主库和从库数据不一致。
这种复制模式下的数据一致性是最弱的。
方法 2：半同步复制（提交后等待）
MySQL5.5 版本之后开始支持半同步复制的方式。原理是在客户端提交 COMMIT 之后不直接将结果返回给客户端，而是等待至少有一个从库接收到了 Binlog，并且写入到中继日志中，再返回给客户端。这样做的好处就是提高了数据的一致性，当然相比于异步复制来说，至少多增加了一个网络连接的延迟，降低了主库写的效率。
方法 3：组复制（提交前等待）
读写事务想要进行提交，必须要经过组里“大多数人”（对应 Node 节点）的同意，大多数指的是同意的节点数量需要大于（N/2+1），这样才可以进行提交，而不是原发起方一个说了算。而针对只读事务则不需要经过组内同意，直接 COMMIT 即可。
主从复制：是主数据库的数据通过二进制日志自动复制到从数据库中。
读写分离：由原本一个服务器的读写请求转变为现在的主服务器处理写请求，从服务器处理读请求，减少了主服务器的压力。
负载均衡：让不同的读请求按照策略均匀地分发到不同的从服务器中，让读写更加顺畅。