一、背景介绍
Mysql作为 DB持久化层的组件，一般采用的是的架构模式，在分布式，高可用的微服务背景下，那么
是如何实现数据同步的一致性？
Mysql有三种主从复制同步方式：
- 全同步复制模式（组复制 MGR）
- 异步复制模式
- 半同步复制模式（version>5.5)。
值得注意的是，，目前我司用的是半同步复制模式，下面来看看几种主从复制同步方式的不同之处。
二、异步复制模式
MySQL异步复制是主从复制过程中默认的复制模式。主从复制涉及三个线程，master I/O线程、slave I/O线程、slave sql线程。因为是异步复制，所以master事务的提交，不需要经过slave的确认，即master I/O线程提交事务后，不需要等待slave I/O线程的回复确认，master并不保证binlog一定写入到了relay log中；而slave I/O把binlog写入relay log后，由slave sql线程异步执行应用到slave mysql中，slave I/O也不需要slave sql的回复确认，并不保证relay log日志完整写入到了mysql中。
三、半同步复制模式
在异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到 relay log 中才返回成功信息给客户端（只能保证主库的 Binlog 至少传输到了一个从节点上），否则需要等待直到超时时间然后切换成异步模式再提交。
相对于异步复制，半同步复制提高了数据的安全性，一定程度的保证了数据能成功备份到从库，同时它也造成了一定程度的延迟，但是比全同步模式延迟要低，这个延迟最少是一个 TCP/IP 往返的时间。所以，半同步复制最好在低延时的网络中使用。
半同步模式不是 MySQL 内置的，从 MySQL 5.5 开始集成，需要 master 和 slave 安装插件开启半同步模式，如图Master节点接收到客户端的细节Commit部分。
但是存在一个问题：若主库的事务已经提交了，但是等到从库 ack的消息时，主库宕机了，那么将无法返回给客户端提交的信息。
此时，可能的情况有两种：
事务还没发送到从库上
此时，客户端会收到事务提交失败的信息，客户端会重新提交该事务到新的主上，当宕机的主库重新启动后，以从库的身份重新加入到该主从结构中，会发现，该事务在从库中被提交了两次，一次是之前作为主的时候，一次是被新主同步过来的。
事务已经发送到从库上
此时，从库已经收到并应用了该事务，但是客户端仍然会收到事务提交失败的信息，重新提交该事务到新的主上。
针对上述潜在问题，Mysql5.7引入了一种新的半同步方案：Loss-Less半同步复制如下图调整了Commit与Watting Slave dump的位置。
四、全同步复制模式
指当主库执行完一个事务，然后所有的从库都复制了该事务并成功执行完才返回成功信息给客户端。因为需要等待所有从库执行完该事务才能返回成功信息，所以全同步复制的模式的Mysql性能必然会受到严重的影响。
MySQL官方在5.7.17版本正式推出组复制（MySQL Group Replication，简称MGR）
由若干个节点共同组成一个复制组，。如下图所示，由3个节点组成一个复制组，Consensus层为一致性协议层，在事务提交过程中，发生组间通讯，由2个节点决议(certify)通过这个事务，事务才能够最终得以提交并响应。
引入组复制，主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。组复制依靠分布式一致性协议(Paxos协议的变体)，实现了分布式下数据的最终一致性，提供了真正的数据高可用方案(是否真正高可用还有待商榷)。其提供的多写方案，给我们实现多活方案带来了希望。
基于传统异步复制和半同步复制的。
。
