在互联网系统中，一般情况下，瓶颈都在数据库这边，特别是关系数据库，比如Mysql等，因为关系数据库的设计本身不是为了支撑大高并发和大流量而设计的，所以是无法支撑高并发和大流量的。所以经常需要通过数据库集群的方案去解决压力，通常是因为数据库需要数据备份、负载均衡、读写分离等原因才部署数据库集群。

Mysql常见的复制模式：

1、单向主从复制模式：Master ----> Slave

单向主从模式，就是最基本的主从复制，一主一从的模式。从库的内容从主库复制。业务上可做读写分离，即缓解主库写数据的压力，读数据都让从库做。单向主从模式可以提高数据库的可用性，当主库出现故障时，还可以快速切换到从库上继续提供服务。

2、双向主从复制模式：Master <====> Master

双向主从模式，就是主主复制，在这种模式下，集群中有两个主节点，它们互相成为对方的主从。这种方式适用于对高可用性要求非常高的场景，双主模式有一些比较难处理的问题。从数据一致性的角度来看，这可能不是最佳的。

3、一主多从复制模式：Master ----> Slave1、Slave2

一主多从模式主要是为了缓解读的压力，适用于读大于写的场景，采用多个从库来分担数据库系统的读压力。

4、级联主从复制模式：Master ----> Slave1 ----> Slave2

级联主从模式，中间的数据库既当主库，也当从库，适用于读大于写的场景，级联主从模式会让级联越深的数据库延迟时间更长，除非业务特别需要，一般很少采用。

5、多主无从复制模式：Master1、Master2<====> Master2、Master2

如果主库的写并发比较高或者为了解决主库单点故障，可用做成多个主库，即多个主库相互复制。适用于写大于读的场景，采用多个主库分担写压力，缺点和双主模式类似。

6、多主一从复制模式：Master1、 Master2<====> Master2、Master2----> Slave

多主复制的基础上，新增单个从库承载读压力，缺点和双主模式类似。

7、多主多从复制模式：Master1、 Master2<====> Master2、Master2----> Slave1、Slave2

多主多从模式是在多主一从模式上新增多个从库，来缓解整体读的压力。

每种复制模式都有其优点和缺点，要根据公司的业务场景、访问量、并发量以及技术人员的水平等因素综合考虑，选择最适合的架构模式。

Mysql常见的复制方式：

1.异步方式（Async Replication）

异步复制模式，主库在执行完事务后，只要将执行逻辑写入到binlog后，就立即返回给客户端，并不关心从库是否执行成功，性能最好，存在延迟，有数据一致性的问题

2.全同步方式（Sync Replication）

当主库执行完事务后，需要等到所有从库也都执行完这一事务后，才返回给客户端执行成功。执行过程中会被阻塞，因为所有从库都响应后，主库才响应，所以性能差，但数据能强一致。

3.半同步方式（Semi-Sync Replication）

半同步复制模式，可以说是介于异步和同步之间的一种复制模式，主库在执行完事务后，要等待至少一个从库接收到binlog并将数据写入到relay log中才返回成功结果。只要有一个从库响应，主库就响应。备注：一主一从下与同步复制一致，如果网络超时会就等于异步复制。

4.增强半同步复制方式（lossless Semi-Sync Replication、无损复制）

增强半同步是在MySQL 5.7引入，其实半同步可以看成是一个过渡功能，因为默认的配置就是增强半同步，也就是无损复制。 在半同步复制的基础上，主库收到响应后才提交事务，数据一致性会比半同步好，但性能差一点。

增强半同步和半同步不同是，等待ACK时间不同。半同步的问题是因为等待ACK的点是Commit之后，此时Master已经完成数据变更，用户已经可以看到最新数据，当Binlog还未同步到Slave时，发生主从切换，那么此时从库是没有这个最新数据的，用户又看到老数据。强半同步将等待ACK的点放在提交Commit之前，此时数据还未被提交，外界看不到数据变更，此时如果发送主从切换，新库依然还是老数据，不存在数据不一致的问题。

5.延迟复制方式：这是故意的延迟，从库在主库响应后，故意延迟固定的一段时间后才修改数据和响应，数据一致性难以保证，但是可以在延迟的时间里回滚数据

声明：本文内容版权归原作者所有，未经授权，禁止转载！

声明：本站仅提供内容存储、展示服务，所有内容均由用户发布，不代表本站观点。请注意甄别内容中的虚假信息，谨防诈骗。如发现有害或侵权内容，可联系本站删除！