Zookeeper如何保证数据一致性

Zookeeper如何保证数据一致性

​ 虽说zk是比较老的框架了,但是其一致性的保证放在今天的中间件中依然是很强力的存在。其数据持久化的流程也是非常标准的流程,兼具了性能和一致性的取舍,非常值得我们学习。


1 zk数据同步简述

重要知识点:首先ZK的数据分为两部分,磁盘数据和内存数据

  • 磁盘数据:存储在物理介质上的数据(持久化数据),可能与内存数据不一致。
  • 内存数据:zk在启动时,会从磁盘上加载数据到内存中,加载数据完成、选举完成、数据同步完成才能对外提供服务,运行期间内,客户端访问的数据都是内存中数据,不会访问磁盘数据。

ZK总体上来说,使用事务日志持久化的方式来保障被提交的数据不会丢失(也是很多数据库常用的操作),再通过内存数据与磁盘数据隔离的形式,来避免分布式环境下各种数据丢失、错乱的问题产生。

zk数据写入简要流程
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-adkdMqpg-1649763349906)(/Users/lvqiushi/Library/Application Support/typora-user-images/image-20220329201630980.png)]

结合zk的数据存储以及上述数据写入流程可知,只有当数据被半数以上的zk节点持久化后,ZK的Leader节点才会把该次事务在内存中生效(内存生效才能被客户端访问)。

因为过半数的节点ACK数据就会写到内存中,所以会存在提交过程中,节点1能读到最新的数据,而节点2读不到,这也是唯一的数据不一致情况。而且针对于这种状况,ZK也做了自身的优化,在同一个session内,读写事务顺序是有保证的。总结为,ZK的数据一致性破坏条件为,只有是不同session的客户端,在数据提交过程中,才可能会读不到最新的数据。

2 顺序性保障

zk的leader节点在处理写事务请求时,会额外保留一些中间状态,比方说上次已提交的最大事务id、当前正在等待ack的事务id、当前已经被ack但是还没有写入内存的事务id。

通过以上三种信息,leader可以用来保障事务通过有序的顺序进行处理,其实本质上类似于单线程在执行二阶段提交的操作,与redis的做法基本类似。

举个例子,有两个写事务操作,事务A:zxid=1、事务B:zxid=2。

事务A在等待客户端的ack过半,事务B过来了,则事务B会被阻塞住等待事务A完成。

3 意外场景举例

在理论上,不同zk节点间,数据发生意外情况只有以下三种可能。

  • 场景1:有某个zk A节点与集群断联,导致A节点中的数据少于集群中数据(因为集群还在正常对外提供服务)
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jL1UCpks-1649763349907)(/Users/lvqiushi/Library/Application Support/typora-user-images/image-20220405230258716.png)]

    A节点在重新连接集群时,会触发选举流程,A节点会收到当前集群已经有leader的选票,因为leader目前确实有效(有半数节点认同),所以A节点也认同leader,leader会把follower缺失的数据发送过去跟自己对齐。

  • 场景2:有某个zk-leader A节点刚刚发送完proposal后就与集群断联,而其他的节点选举出了新leader且新的集群没有提交新的事务。
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iXciw3RO-1649763349908)(/Users/lvqiushi/Library/Application Support/typora-user-images/image-20220405230328094.png)]

    当A节点又可以正常连接集群,会导致A节点中的数据多于集群中数据,这时新leader会把旧leader多出的数据删除掉。

  • 场景3:在场景2基础上的特例,当新的leader继续对外服务后,可能会造成之前的leader与现在leader之间的数据有多有少的局面,也可以说是最复杂的场景。
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fIQIPvmr-1649763349908)(/Users/lvqiushi/Library/Application Support/typora-user-images/image-20220405230328094.png)]

    zk对于这种场景用了很粗暴的方式,当发现数据有多有少后,会直接发送snap把新leader的所有数据覆盖掉A节点的数据,这么设计可能是为了避免出现某些问题,但是也埋下了一些坑,因为snap是比较耗费性能的操作(特别是有超时时间的限制)。

以上三种场景每种场景我都debug过代码,可以保证描述正确性。如有更多的场景,欢迎私信找我沟通,互相学习。

评论 10
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值