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丨数据库主从同步的作用是什么,如何解决数据不一致问题?
  • 5
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值