首先看官网介绍:
ZooKeeper: A Distributed Coordination Service for Distributed Applications
Zookeeper是一个开源的分布式协调服务,由雅虎公司创建,由于最初雅虎公司的内部研究小组的项目大多以动物的名字命名,所以后来就以Zookeeper(动物管理员)来命名了,而就是由Zookeeper来负责这些分布式组件环境的协调工作。
他的目标是可以提供高性能、高可用和顺序访问控制的能力,同时也是为了解决分布式环境下数据一致性的问题。
应用场景
命名服务Name Service,依赖Zookeeper可以生成全局唯一的节点ID,来对分布式系统中的资源进行管理。
分布式协调,这是Zookeeper的核心使用了。利用Wather的监听机制,一个系统的某个节点状态发生改变,另外系统可以得到通知。
集群管理,分布式集群中状态的监控和管理,使用Zookeeper来存储。
Master选举,利用Zookeeper节点的全局唯一性,同时只有一个客户端能够创建成功的特点,可以作为Master选举使用,创建成功的则作为Master。
分布式锁,利用Zookeeper创建临时顺序节点的特性。
ZooKeeper的数据结构,跟Unix文件系统非常类似,可以看做是一颗树,每个节点叫做ZNode。每一个节点可以通过路径来标识,结构图如下:
那ZooKeeper这颗"树"有什么特点呢??ZooKeeper的节点我们称之为Znode,Znode分为两种类型:
短暂/临时(Ephemeral):当客户端和服务端断开连接后,所创建的Znode(节点)会自动删除
持久(Persistent):当客户端和服务端断开连接后,所创建的Znode(节点)不会删除
ZooKeeper和Redis一样,也是C/S结构(分成客户端和服务端)
Zookeeper中数据存储于内存之中,这个数据节点就叫做Znode
我特么,这样问的么?可是我面试只看了分布式锁,我得好好想想!!!
还好我之前在自己的服务器搭建了一个zk的集群,我刚好跟大家回忆一波。
#首先使用docker安装 然后docker exec -it zookeeper zkCli.sh 进入zookeeper的cli控制台
create /test a // 创建永久节点 路径在根目录下叫test(就像一个文件) 值为a
create -e /test/tmp b // 创建临时节点 退出后,重新连接,创建的所有临时节点都没了
create -e /test/tmp c #Node already exists: /test/tmp会报错
get /test #输出a
[zk: localhost:2181(CONNECTED) 7] ls /
[test, zookeeper] #zookeeper是默认存在的节点
[zk: localhost:2181(CONNECTED) 8] ls /test
[tmp]
create -s /test // 创建顺序节点
//临时顺序节点呢?我想聪明的老公都会抢答了
create -e -s /test // 创建临时顺序节点
常见的监听场景有以下两项:
Zookeeper可以提供分布式数据的发布/订阅功能,依赖的就是Wather监听机制。
客户端可以向服务端注册Wather监听,服务端的指定事件触发之后,就会向客户端发送一个事件通知。
他有几个特性:
一次性:一旦一个Wather触发之后,Zookeeper就会将它从存储中移除
客户端串行:客户端的Wather回调处理是串行同步的过程,不要因为一个Wather的逻辑阻塞整个客户端
轻量:Wather通知的单位是WathedEvent,只包含通知状态、事件类型和节点路径,不包含具体的事件内容,具体的时间内容需要客户端主动去重新获取数据
主要流程如下:
客户端向服务端注册Wather监听
保存Wather对象到客户端本地的WatherManager中
服务端Wather事件触发后,客户端收到服务端通知,从WatherManager中取出对应Wather对象执行回调逻辑
会话自然就是指Zookeeper客户端和服务端之间的通信,他们使用TCP长连接的方式保持通信,通常,肯定会有心跳检测的机制,同时他可以接受来自服务器的Watch事件通知。
Zookeeper使用ACL来进行权限的控制,包含以下5种:
CREATE,创建子节点权限
DELETE,删除子节点权限
READ,获取节点数据和子节点列表权限
WRITE,更新节点权限
ADMIN,设置节点ACL权限
所以,Zookeeper通过集群的方式来做到高可用,通过内存数据节点Znode来达到高性能,但是存储的数据量不能太大,通常适用于读多写少的场景。
下面我们来看看用ZooKeeper怎么来做:统一配置管理、统一命名服务、分布式锁、集群管理。
比如我们现在有三个系统A、B、C,他们有三份配置,分别是ASystem.yml、BSystem.yml、CSystem.yml,然后,这三份配置又非常类似,很多的配置项几乎都一样。
此时,如果我们要改变其中一份配置项的信息,很可能其他两份都要改。并且,改变了配置项的信息很可能就要重启系统
于是,我们希望把ASystem.yml、BSystem.yml、CSystem.yml相同的配置项抽取出来成一份公用的配置common.yml,并且即便common.yml改了,也不需要系统A、B、C重启。
做法:我们可以将common.yml这份配置放在ZooKeeper的Znode节点中,系统A、B、C监听着这个Znode节点有无变更,如果变更了,及时响应。
统一命名服务的理解其实跟域名一样,是我们为这某一部分的资源给它取一个名字,别人通过这个名字就可以拿到对应的资源。
比如说,现在我有一个域名www.java3y.com,但我这个域名下有多台机器:
192.168.1.1
192.168.1.2
192.168.1.3
192.168.1.4
别人访问www.java3y.com即可访问到我的机器,而不是通过IP去访问。
锁的概念在这我就不说了,如果对锁概念还不太了解的同学,可参考下面的文章
我们可以使用ZooKeeper来实现分布式锁,那是怎么做的呢??下面来看看:
系统A、B、C都去访问/locks节点
访问的时候会创建带顺序号的临时/短暂(EPHEMERAL_SEQUENTIAL)节点,比如,系统A创建了id_000000节点,系统B创建了id_000002节点,系统C创建了id_000001节点。
接着,拿到/locks节点下的所有子节点(id_000000,id_000001,id_000002),判断自己创建的是不是最小的那个节点
如果是,则拿到锁。
执行完操作后,把创建的节点给删掉,释放锁:
如果不是,则监听比自己要小1的节点变化
举个例子:
系统A拿到/locks节点下的所有子节点,经过比较,发现自己(id_000000),是所有子节点最小的。所以得到锁
系统B拿到/locks节点下的所有子节点,经过比较,发现自己(id_000002),不是所有子节点最小的。所以监听比自己小1的节点id_000001的状态
系统C拿到/locks节点下的所有子节点,经过比较,发现自己(id_000001),不是所有子节点最小的。所以监听比自己小1的节点id_000000的状态
……
等到系统A执行完操作以后,将自己创建的节点删除(id_000000)。通过监听,系统C发现id_000000节点已经删除了,发现自己已经是最小的节点了,于是顺利拿到锁
….系统B如上
经过上面几个例子,我相信大家也很容易想到ZooKeeper是怎么"感知"节点的动态新增或者删除的了。
还是以我们三个系统A、B、C为例,在ZooKeeper中创建临时节点即可:
只要系统A挂了,那/groupMember/A这个节点就会删除,通过监听groupMember下的子节点,系统B和C就能够感知到系统A已经挂了。(新增也是同理)
除了能够感知节点的上下线变化,ZooKeeper还可以实现动态选举Master的功能。(如果集群是主从架构模式下)
原理也很简单,如果想要实现动态选举Master的功能,Znode节点的类型是带顺序号的临时节点(EPHEMERAL_SEQUENTIAL)就好了。
Zookeeper会每次选举最小编号的作为Master,如果Master挂了,自然对应的Znode节点就会删除。然后让新的最小编号作为Master,这样就可以实现动态选举的功能了。
锁我想不需要我过多的去说,大家都知道是怎么一回事了吧?
在多线程环境下,由于上下文的切换,数据可能出现不一致的情况或者数据被污染,我们需要保证数据安全,所以想到了加锁。
所谓的加锁机制呢,就是当一个线程访问该类的某个数据时,进行保护,其他线程不能进行访问,直到该线程读取完,其他线程才可使用。
还记得我之前说过Redis在分布式的情况下,需要对存在并发竞争的数据进行加锁,老公们十分费解,Redis是单线程的嘛?为啥还要加锁呢?
看来老公们还是年轻啊,你说的不需要加锁的情况是这样的:
单个服务去访问Redis的时候,确实因为Redis本身单线程的原因是不用考虑线程安全的,但是,现在有哪个公司还是单机的呀?肯定都是分布式集群了嘛。
老公们你看下这样的场景是不是就有问题了:
你们经常不是说秒杀嘛,拿到库存判断,那老婆告诉你分布式情况就是会出问题的。
我们为了减少DB的压力,把库存预热到了KV,现在KV的库存是1。
服务A去Redis查询到库存发现是1,那说明我能抢到这个商品对不对,那我就准备减一了,但是还没减。
同时服务B也去拿发现也是1,那我也抢到了呀,那我也减。
C同理。
等所有的服务都判断完了,你发现诶,怎么变成-2了,超卖了呀,这下完了。
是不是发现问题了,这就需要分布式锁的介入了,我会分三个章节去分别介绍分布式锁的三种实现方式(Zookeeper,Redis,MySQL),说出他们的优缺点,以及一般大厂的实践场景。
正常线程进程同步的机制有哪些?
互斥:互斥的机制,保证同一时间只有一个线程可以操作共享资源 synchronized,Lock等。
临界值:让多线程串行话去访问资源
事件通知:通过事件的通知去保证大家都有序访问共享资源
信号量:多个任务同时访问,同时限制数量,比如发令枪CDL,Semaphore等
那分布式锁你了解过有哪些么?
分布式锁实现主要以Zookeeper(以下简称zk)、Redis、MySQL这三种为主。
先跟我聊一下zk吧,你能说一下他常见的使用场景么?
他主要的应用场景有以下几个:
服务注册与订阅(共用节点)
分布式通知(监听znode)
服务命名(znode特性)
数据订阅、发布(watcher)
分布式锁(临时节点)
zk是啥?
他是个数据库,文件存储系统,并且有监听通知机制(观察者模式)
存文件系统,他存了什么?
节点,节点名称都是唯一的,zk的节点类型有4大类
持久化节点(zk断开节点还在)
持久化顺序编号目录节点
临时目录节点(客户端断开后节点就删除了)
临时目录编号目录节点
接下来 首先用aobing的例子展示,完整代码见https://mp.weixin.qq.com/s/ZqQHWLfVD1Rz1agmH3LWrg
https://github.com/AobingJava/Thanos
我定义了一个库存inventory值为1,还用到了一个CountDownLatch发令枪,等10个线程都就绪了一起去扣减库存。
是不是就像10台机器一起去拿到库存,然后扣减库存了?
所有机器一起去拿,发现都是1,那大家都认为是自己抢到了,都做了减一的操作,但是等所有人都执行完,再去set值的时候,发现其实已经超卖了,我打印出来给大家看看。
是吧,这还不是超卖一个两个的问题,超卖7个都有,代码里面明明判断了库存大于0才去减的,怎么回事开头我说明了。
那怎么解决这个问题?
sync,lock也只能保证你当前机器线程安全,这样分布式访问还是有问题。
zk节点有个唯一的特性,就是我们创建过这个节点了,你再创建zk是会报错的,那我们就利用一下他的唯一性去实现一下。
怎么实现呢?
上面不是10个线程嘛?
我们全部去创建,创建成功的第一个返回true他就可以继续下面的扣减库存操作,后续的节点访问就会全部报错,扣减失败,我们把它们丢一个队列去排队。
那怎么释放锁呢?
删除节点咯,删了再通知其他的人过来加锁,依次类推。
我们实现一下,zk加锁的场景。
但是你发现问题没有,你加了锁了,你得释放啊,你不释放后面的报错了就不重试了。
那简单,删除锁就释放掉了,Lock在finally里面unLock,现在我们在finally删除节点。
加锁我们知道创建节点就够了,但是你得实现一个阻塞的效果呀,那咋搞?
死循环,递归不断去尝试,直到成功,一个伪装的阻塞效果。
怎么知道前面的老哥删除节点了嗯?
监听节点的删除事件
但是你发现你这样做的问题没?
是的,会出现死锁。
第一个仔加锁成功了,在执行代码的时候,机器宕机了,那节点是不是就不能删除了?
你要故作沉思,自问自答,时而看看远方,时而看看面试官,假装自己什么都不知道。
哦我想起来了,创建临时节点就好了,客户端连接一断开,别的就可以监听到节点的变化了。
嗯还不错,那你发现还有别的问题没?
好像这种监听机制也不好。
怎么个不好呢?
你们可以看到,监听,是所有服务都去监听一个节点的,节点的释放也会通知所有的服务器,如果是900个服务器呢?
这对服务器是很大的一个挑战,一个释放的消息,就好像一个牧羊犬进入了羊群,大家都四散而开,随时可能干掉机器,会占用服务资源,网络带宽等等。
这就是羊群效应。
那怎么解决这个问题?
继续故作沉思,啊啊啊,好难,我的脑袋。。。。
你TM别装了好不好?
好的,临时顺序节点,可以顺利解决这个问题。
怎么实现老公你先别往下看,先自己想想。
之前说了全部监听一个节点问题很大,那我们就监听我们的前一个节点,因为是顺序的,很容易找到自己的前后。
和之前监听一个永久节点的区别就在于,这里每个节点只监听了自己的前一个节点,释放当然也是一个个释放下去,就不会出现羊群效应了。
你说了这么多,挺不错的,你能说说ZK在分布式锁中实践的一些缺点么?
Zk性能上可能并没有缓存服务那么高。
因为每次在创建锁和释放锁的过程中,都要动态创建、销毁瞬时节点来实现锁功能。
ZK中创建和删除节点只能通过Leader服务器来执行,然后将数据同步到所有的Follower机器上。(这里涉及zk集群的知识,我就不展开了,以后zk章节跟老公们细聊)
还有么?
使用Zookeeper也有可能带来并发问题,只是并不常见而已。
由于网络抖动,客户端可ZK集群的session连接断了,那么zk以为客户端挂了,就会删除临时节点,这时候其他客户端就可以获取到分布式锁了。
就可能产生并发问题了,这个问题不常见是因为zk有重试机制,一旦zk集群检测不到客户端的心跳,就会重试,Curator客户端支持多种重试策略。
多次重试之后还不行的话才会删除临时节点。
Tip:所以,选择一个合适的重试策略也比较重要,要在锁的粒度和并发之间找一个平衡。
有更好的实现么?
基于Redis的分布式锁
总结
zk通过临时节点,解决掉了死锁的问题,一旦客户端获取到锁之后突然挂掉(Session连接断开),那么这个临时节点就会自动删除掉,其他客户端自动获取锁。
zk通过节点排队监听的机制,也实现了阻塞的原理,其实就是个递归在那无限等待最小节点释放的过程。
我上面没实现锁的可重入,但是也很好实现,可以带上线程信息就可以了,或者机器信息这样的唯一标识,获取的时候判断一下。
zk的集群也是高可用的,只要半数以上的或者,就可以对外提供服务了。
Zab(Zookeeper Atomic Broadcast)是为ZooKeeper协设计的崩溃恢复原子广播协议,它保证zookeeper集群数据的一致性和命令的全局有序性。
首先,Zookeeper集群中有几个关键的概念,Leader、Follower和Observer,Zookeeper中通常只有Leader节点可以写入,Follower和Observer都只是负责读,但是Follower会参与节点的选举和过半写成功,Observer则不会,他只是单纯的提供读取数据的功能。
通常这样设置的话,是为了避免太多的从节点参与过半写(在集群部署下,leader将事务请求(例如create指令)发送给大多数(一半以上)的follower且成功执行后,则算作该事务请求成功执行。)的过程,导致影响性能,这样Zookeeper只要使用一个几台机器的小集群就可以实现高性能了,如果要横向扩展的话,只需要增加Observer节点即可。
Zookeeper建议集群节点个数为奇数,只要超过一半的机器能够正常提供服务,那么整个集群都是可用的状态。
集群角色
服务状态
可以知道Zookeeper是通过自身的状态来区分自己所属的角色,来执行自己应该的任务。
ZAB状态:Zookeeper还给ZAB定义的4中状态,反应Zookeeper从选举到对外提供服务的过程中的四个步骤。状态枚举定义:
public enum ZabState {
ELECTION,
DISCOVERY,
SYNCHRONIZATION,
BROADCAST
}
ZXID
Zxid是极为重要的概念,它是一个long型(64位)整数,分为两部分:纪元(epoch)部分和计数器(counter)部分,是一个全局有序的数字。
epoch代表当前集群所属的哪个leader,leader的选举就类似一个朝代的更替,你前朝的剑不能斩本朝的官,用epoch代表当前命令的有效性,counter是一个递增的数字。
基础概念介绍完了,下面开始介绍zab协议是怎么支持leader选举的。
进行leader有三个问题,什么时候进行?选举规则?选择流程?
下面我会一一解答这三个问题:
选举发生的时机Leader发生选举有两个时机,一个是服务启动的时候当整个集群都没有leader节点会进入选举状态,如果leader已经存在就会告诉该节点leader的信息,自己连接上leader,整个集群不用进入选举状态。
还有一个就是在服务运行中,可能会出现各种情况,服务宕机、断电、网络延迟很高的时候leader都不能再对外提供服务了,所有当其他几点通过心跳检测到leader失联之后,集群也会进入选举状态。
选举规则进入投票选举流程,怎么才能选举出leader?或者说按照什么规则来让其他节点都能选举你当leader。
zab协议是按照几个比较规则来进行投票的筛选,如果你的票比我更好,就修改自身的投票信息,改投你当leader。
下面代码是zookeeper投票比较规则:
/*
* We return true if one of the following three cases hold:
* 1- New epoch is higher
* 2- New epoch is the same as current epoch, but new zxid is higher
* 3- New epoch is the same as current epoch, new zxid is the same
* as current zxid, but server id is higher.
*/
return ((newEpoch > curEpoch)
|| ((newEpoch == curEpoch)
&& ((newZxid > curZxid)
|| ((newZxid == curZxid)
&& (newId > curId)))));
当其他节点的纪元比自身高投它,如果纪元相同比较自身的zxid的大小,选举zxid大的节点,这里的zxid代表节点所提交事务最大的id,zxid越大代表该节点的数据越完整。
最后如果epoch和zxid都相等,则比较服务的serverId,这个Id是配置zookeeper集群所配置的,所以我们配置zookeeper集群的时候可以把服务性能更高的集群的serverId配置大些,让性能好的机器担任leader角色。
举例
上图来自《ZooKeeper:分布式过程协同技术详解》,整体流程还是比较简单,这里就不具体分析了。
集群在经过leader选举之后还会有连接leader和同步两个步骤,这里就不具体分析这两个步骤的流程了,主要介绍集群对外提供服务如何保证各个节点数据的一致性。
zab在广播状态中保证以下特征
可靠传递: 如果消息m由一台服务器传递,那么它最终将由所有服务器传递。
全局有序: 如果一个消息a在消息b之前被一台服务器交付,那么所有服务器都交付了a和b,并且a先于b。
因果有序: 如果消息a在因果上先于消息b并且二者都被交付,那么a必须排在b之前。
有序性是zab协议必须要保证的一个很重要的属性,因为zookeeper是以类似目录结构的数据结构存储数据的,必须要求命名的有序性。
比如一个命名a创建路径为/test,然后命名b创建路径为/test/123,如果不能保证有序性b命名在a之前,b命令会因为父节点不存在而创建失败。
如上图所示,整个写请求类似一个二阶段的提交。
当收到客户端的写请求的时候会经历以下几个步骤:
Leader收到客户端的写请求,生成一个事务(Proposal),其中包含了zxid;
Leader开始广播该事务,需要注意的是所有节点的通讯都是由一个FIFO的队列维护的;
Follower接受到事务之后,将事务写入本地磁盘,写入成功之后返回Leader一个ACK;
Leader收到过半的ACK之后,开始提交本事务,并广播事务提交信息
从节点开始提交本事务。
有以上流程可知,zookeeper通过二阶段提交来保证集群中数据的一致性,因为只需要收到过半的ACK就可以提交事务,所以zookeeper的数据并不是强一致性。
zab协议的有序性保证是通过几个方面来体现的,第一是,服务之前用TCP协议进行通讯,保证在网络传输中的有序性;第二,节点之前都维护了一个FIFO的队列,保证全局有序性;第三,通过全局递增的zxid保证因果有序性。
前面介绍了zookeeper服务状态有四种,ZAB状态也有四种。这里就简单介绍一个他们之间的状态流转,更能加深对zab协议在zookeeper工作流程中的作用。
服务在启动或者和leader失联之后服务状态转为LOOKING;
如果leader不存在选举leader,如果存在直接连接leader,此时zab协议状态为ELECTION;
如果有超过半数的投票选择同一台server,则leader选举结束,被选举为leader的server服务状态为LEADING,其他server服务状态为FOLLOWING/OBSERVING;
所有server连接上leader,此时zab协议状态为DISCOVERY;
leader同步数据给learner,使各个从节点数据和leader保持一致,此时zab协议状态为SYNCHRONIZATION;
同步超过一半的server之后,集群对外提供服务,此时zab状态为BROADCAST。
可以知道整个zookeeper服务的工作流程类似一个状态机的转换,而zab协议就是驱动服务状态流转的关键,理解了zab就理解了zookeeper工作的关键原理
Zookeeper通过ZAB原子广播协议来实现数据的最终顺序一致性,他是一个类似2PC两阶段提交的过程。
由于Zookeeper只有Leader节点可以写入数据,如果是其他节点收到写入数据的请求,则会将之转发给Leader节点。
主要流程如下:
Leader收到请求之后,将它转换为一个proposal提议,并且为每个提议分配一个全局唯一递增的事务ID:zxid,然后把提议放入到一个FIFO的队列中,按照FIFO的策略发送给所有的Follower
Follower收到提议之后,以事务日志的形式写入到本地磁盘中,写入成功后返回ACK给Leader
Leader在收到超过半数的Follower的ACK之后,即可认为数据写入成功,就会发送commit命令给Follower告诉他们可以提交proposal了
ZAB包含两种基本模式,崩溃恢复和消息广播。
整个集群服务在启动、网络中断或者重启等异常情况的时候,首先会进入到崩溃恢复状态,此时会通过选举产生Leader节点,当集群过半的节点都和Leader状态同步之后,ZAB就会退出恢复模式。之后,就会进入消息广播的模式。
Leader的选举可以分为两个方面,同时选举主要包含事务zxid和myid,节点主要包含LEADING\FOLLOWING\LOOKING3个状态。
服务启动期间的选举
服务运行期间的选举
服务启动期间的选举
首先,每个节点都会对自己进行投票,然后把投票信息广播给集群中的其他节点
节点接收到其他节点的投票信息,然后和自己的投票进行比较,首先zxid较大的优先,如果zxid相同那么则会去选择myid更大者,此时大家都是LOOKING的状态
投票完成之后,开始统计投票信息,如果集群中过半的机器都选择了某个节点机器作为leader,那么选举结束
最后,更新各个节点的状态,leader改为LEADING状态,follower改为FOLLOWING状态
服务运行期间的选举
如果开始选举出来的leader节点宕机了,那么运行期间就会重新进行leader的选举。
leader宕机之后,非observer节点都会把自己的状态修改为LOOKING状态,然后重新进入选举流程
生成投票信息(myid,zxid),同样,第一轮的投票大家都会把票投给自己,然后把投票信息广播出去
接下来的流程和上面的选举是一样的,都会优先以zxid,然后选择myid,最后统计投票信息,修改节点状态,选举结束
那实际上Zookeeper在选举之后,Follower和Observer(统称为Learner)就会去向Leader注册,然后就会开始数据同步的过程。
数据同步包含3个主要值和4种形式。
PeerLastZxid:Learner服务器最后处理的ZXID
minCommittedLog:Leader提议缓存队列中最小ZXID
maxCommittedLog:Leader提议缓存队列中最大ZXID
直接差异化同步 DIFF同步
如果PeerLastZxid在minCommittedLog和maxCommittedLog之间,那么则说明Learner服务器还没有完全同步最新的数据。
首先Leader向Learner发送DIFF指令,代表开始差异化同步,然后把差异数据(从PeerLastZxid到maxCommittedLog之间的数据)提议proposal发送给Learner
发送完成之后发送一个NEWLEADER命令给Learner,同时Learner返回ACK表示已经完成了同步
接着等待集群中过半的Learner响应了ACK之后,就发送一个UPTODATE命令,Learner返回ACK,同步流程结束
先回滚再差异化同步 TRUNC+DIFF同步
这个设置针对的是一个异常的场景。
如果Leader刚生成一个proposal,还没有来得及发送出去,此时Leader宕机,重新选举之后作为Follower,但是新的Leader没有这个proposal数据。
举个栗子:
假设现在的Leader是A,minCommittedLog=1,maxCommittedLog=3,刚好生成的一个proposal的ZXID=4,然后挂了。
重新选举出来的Leader是B,B之后又处理了2个提议,然后minCommittedLog=1,maxCommittedLog=5。
这时候A的PeerLastZxid=4,在(1,5)之间。
那么这一条只存在于A的提议怎么处理?
A要进行事务回滚,相当于抛弃这条数据,并且回滚到最接近于PeerLastZxid的事务,对于A来说,也就是PeerLastZxid=3。
流程和DIFF一致,只是会先发送一个TRUNC命令,然后再执行差异化DIFF同步。
仅回滚同步 TRUNC同步
针对PeerLastZxid大于maxCommittedLog的场景,流程和上述一致,事务将会被回滚到maxCommittedLog的记录。
这个其实就更简单了,也就是你可以认为TRUNC+DIFF中的例子,新的Leader B没有处理提议,所以B中minCommittedLog=1,maxCommittedLog=3。
所以A的PeerLastZxid=4就会大于maxCommittedLog了,也就是A只需要回滚就行了,不需要执行差异化同步DIFF了。
全量同步 SNAP同步
适用于两个场景:
PeerLastZxid小于minCommittedLog
Leader服务器上没有提议缓存队列,并且PeerLastZxid不等于Leader的最大ZXID
这两种场景下,Leader将会发送SNAP命令,把全量的数据都发送给Learner进行同步。
还是会存在的,我们可以分成3个场景来描述这个问题。
查询不一致
因为Zookeeper是过半成功即代表成功,假设我们有5个节点,如果123节点写入成功,如果这时候请求访问到4或者5节点,那么有可能读取不到数据,因为可能数据还没有同步到4、5节点中,也可以认为这算是数据不一致的问题。
解决方案可以在读取前使用sync命令。
leader未发送proposal宕机
这也就是数据同步说过的问题。
leader刚生成一个proposal,还没有来得及发送出去,此时leader宕机,重新选举之后作为follower,但是新的leader没有这个proposal。
这种场景下的日志将会被丢弃。
leader发送proposal成功,发送commit前宕机
如果发送proposal成功了,但是在将要发送commit命令前宕机了,如果重新进行选举,还是会选择zxid最大的节点作为leader,因此,这个日志并不会被丢弃,会在选举出leader之后重新同步到其他节点当中。
Nacos Eureka Consul Zookeeper
一致性协议 CP+AP AP CP CP
健康检查 TCP/HTTP/MYSQL/Client Beat Client Beat TCP/HTTP/gRPC/Cmd Keep Alive
负载均衡策略 权重/ metadata/Selector Ribbon Fabio —
雪崩保护 有 有 无 无
自动注销实例 支持 支持 不支持 支持
访问协议 HTTP/DNS HTTP HTTP/DNS TCP
监听支持 支持 支持 支持 支持
多数据中心 支持 支持 支持 不支持
跨注册中心同步 支持 不支持 支持 不支持
SpringCloud集成 支持 支持 支持 不支持
Dubbo集成 支持 不支持 不支持 支持
K8S集成 支持 不支持 支持 不支持
CAP是一个分布式系统设计的定理,他包含3个部分,并且最多只能同时满足其中两个。
Consistency一致性,因为在一个分布式系统中,数据肯定需要在不同的节点之间进行同步,就比如Zookeeper,所以一致性就是指的是数据在不同的节点之间怎样保证一致性,对于纯理论的C而言,默认的规则是忽略掉延迟的,因为如果考虑延迟的话,因为数据同步的过程无论如何都会有延迟的,延迟的过程必然会带来数据的不一致。
Availability可用性,这个指的是对于每一个请求,节点总是可以在合理的时间返回合理的响应,比如Zookeeper在进行数据同步时,无法对外提供读写服务,不满足可用性要求。这里常有的一个例子是说Zookeeper选举期间无法提供服务不满足A,这个说法并不准确,因为CAP关注的是数据的读写,选举可以认为不在考虑范围之内。所以,可以认为对于数据的读写,无论响应超时还是返回异常都可以认为是不满足A。
Partition-tolerance分区容错性,因为在一个分布式系统当中,很有可能由于部分节点的网络问题导致整个集群之间的网络不连通,所以就产生了网络分区,整个集群的环境被分隔成不同的的子网,所以,一般说网络不可能100%的不产生问题,所以P一定会存在。
为什么只能同时满足CAP中的两个呢?
以A\B两个节点同步数据举例,由于P的存在,那么可能AB同步数据出现问题。
如果选择AP,由于A的数据未能正确同步到B,所以AB数据不一致,无法满足C。
如果选择CP,那么B就不能提供服务,就无法满足A。