SQL进阶理论篇（十八）：数据库主从同步的数据一致性问题

简介

想象一下，如果不做读写分离，即读和写都在主库上，从库只是作为一个通过binlog的热备份。这种情况下，主库自然可以通过加锁来保障数据的一致性。如图：

那么读写分离的时候，主从架构是如何解决数据不一致问题的呢？

按照数据一致性的强度，从弱到强，主从架构提供了3种复制方式。
分别是：

• 异步复制
• 半同步复制
• 组复制

异步复制

方法一：异步复制。

异步复制是数据一致性最弱的复制模式。

请求写的客户端在提交了commit之后，不需要从从库得到任何响应，主库就可以直接告知客户端写流程已经结束。

这样的好处是不会影响主库写的效率，但是很难保障一致性。

比如说客户端提交了commit之后，新的binlog还没有同步给从库，这时候主库突然宕机，按流程我们需要推举一个从库来作为新主，但是无论选哪个从库，都缺少了原先主库刚commit的数据。

过程如图：

半同步复制

方法二：半同步复制

MySQL5.5版本之后开始支持半同步复制的方式。

原理是请求写的客户端在提交了commit之后，先不把结果返回给客户端，即先不结束掉写流程，而是等待至少有一个从库接收到了binlog，并且写入到了中继日志之后，才会告知客户端，写流程已经结束。

这样的好处是，确保了至少有一个从库，数据跟主库最新数据已经是同步的了，提高了数据的一致性。当然，相比异步复制，这个过程增加了至少一个网络连接的延迟，降低了主库写的效率（写流程被强行拉长）。

MySQL5.7版本里还增加了一个rpl_semi_sync_master_wait_for_slave_count参数，用来指定应答的从库数量，默认是1，就是说只要有一个从库进行了响应，主库就可以告知客户端结束写流程。这个参数越大，数据一致性的强度越高，但是也会增加主库等待从库响应的时间，有利有弊。

整个流程如图：

组复制

方法3：组复制

组复制技术，简称MGR（MySQL Group Replication）。是MySQL在5.7.17版本中推出的一种新的数据复制技术。这种复制技术是基于Paxos协议的状态机复制。

刚才说的两种复制方式都无法最终保证数据的一致性问题。虽然半同步复制可以保证有一定数量的从库是跟主库同步的，但是仍然无法满足对数据一致性要求极高的场景，比如说金融领域。

而MGR很好的弥补了这两种复制模式的不足。

那么MGR是如何工作的？

如图：

首先，我们将多个节点共同组成一个复制组，在执行读写（RW）事务的时候，需要通过一致性协议层（Consensus）的同意，也就是读写事务想要进行提交的话，必须要经过组里大多数节点的同意。假设有N个节点，那么同意的节点数必须大于（N/2 + 1），这样才能进行提交，不再是原先的单个Master说了算。对于只读事务的话，不需要经过投票，直接commit就可以。

一个复制组由多个节点组成，它们各自维护自己的数据副本，并且在一致性协议层实现了原子消息和全局有序消息，从而保证了组内数据的一致性。（具体原理可以查看MySQL的官方文档，点击这里可以参考。）

至于之前提到的Paxos算法，是1990年提出的一种算法，有兴趣可以看一下原论文。或者简化过后的论文。

事实上，Paxos算法自提出来之后就作为分布式一致性算法被广泛使用，比如Apache的ZooKeeper也是基于Paxos来实现的。

参考文献

1. 35丨数据库主从同步的作用是什么，如何解决数据不一致问题？