1
、
LOOKING
:寻找
Leader
状态。当服务器处于该状态时,它会认为当前集群中没有 Leader
,因此需要进入
Leader
选举状态。
2
、
FOLLOWING
:跟随者状态。表明当前服务器角色是
Follower
。
3
、
LEADING
:领导者状态。表明当前服务器角色是
Leader
。
4
、
OBSERVING
:观察者状态。表明当前服务器角色是
Observer
。
15. 数据同步
整个集群完成
Leader
选举之后,
Learner
(
Follower
和
Observer
的统称)回向Leader 服务器进行注册。当
Learner
服务器想
Leader
服务器完成注册后,进入数据同步环节。
数据同步流程:(均以消息传递的方式进行)
Learner
向
Learder
注册
数据同步
同步确认
Zookeeper
的数据同步通常分为四类:
1
、直接差异化同步(
DIFF
同步)
2
、先回滚再差异化同步(
TRUNC+DIFF
同步)
3
、仅回滚同步(
TRUNC
同步)
4
、全量同步(
SNAP
同步)
在进行数据同步前,
Leader
服务器会完成数据同步初始化:
peerLastZxid
:
从 learner 服务器注册时发送的 ACKEPOCH 消息中提取 lastZxid(该Learner 服务器最后处理的 ZXID)
minCommittedLog
:
Leader
服务器
Proposal
缓存队列
committedLog
中最小
ZXID
maxCommittedLog
:
Leader
服务器
Proposal
缓存队列
committedLog
中最大
ZXID
直接差异化同步(
DIFF
同步)
场景:
peerLastZxid
介于
minCommittedLog
和
maxCommittedLog 之间
先回滚再差异化同步(
TRUNC+DIFF
同步)
场景:当新的
Leader
服务器发现某个
Learner
服务器包含了一条自己没有的事务记录,那么就需要让该 Learner
服务器进行事务回滚
--
回滚到
Leader服务器上存在的,同时也是最接近于 peerLastZxid
的
ZXID
仅回滚同步(
TRUNC
同步)
场景:
peerLastZxid
大于
maxCommittedLog
全量同步(
SNAP
同步)
场景一:
peerLastZxid
小于
minCommittedLog
场景二:
Leader
服务器上没有
Proposal
缓存队列且
peerLastZxid
不等于 lastProcessZxid
16. zookeeper 是如何保证事务的顺序一致性的?
zookeeper
采用了全局递增的事务
Id
来标识,所有的
proposal
(提议)都在被提出的时候加上了 zxid
,
zxid
实际上是一个
64
位的数字,高
32
位是
epoch
(时期;
纪元
;
世
;
新时代)用来标识
leader
周期,如果有新的
leader
产生出来,
epoch会自增,低 32
位用来递增计数。当新产生
proposal
的时候,会依据数据库的两阶段过程,首先会向其他的 server
发出事务执行请求,如果超过半数的机器都能执行并且能够成功,那么就会开始执行。
在分布式环境中,有些业务逻辑只需要集群中的某一台机器进行执行,其他的机 器可以共享这个结果,这样可以大大减少重复计算,提高性能,于是就需要进行 leader 选举。
Zookeeper
本身也是集群,推荐配置不少于
3
个服务器。
Zookeeper
自身也要保证当一个节点宕机时,其他节点会继续提供服务。
如果是一个
Follower
宕机,还有
2
台服务器提供访问,因为
Zookeeper
上的数据是有多个副本的,数据并不会丢失;
如果是一个
Leader
宕机,
Zookeeper
会选举出新的
Leader
。
ZK
集群的机制是只要超过半数的节点正常,集群就能正常提供服务。只有在
ZK节点挂得太多,只剩一半或不到一半节点能工作,集群才失效。
所以
3
个节点的
cluster
可以挂掉
1
个节点
(leader
可以得到
2
票
>1.5)
2
个节点的
cluster
就不能挂掉任何
1
个节点了
(leader
可以得到
1
票
<=1)
19. zookeeper 负载均衡和 nginx 负载均衡区别
zk
的负载均衡是可以调控,
nginx
只是能调权重,其他需要可控的都需要自己写
插件;但是
nginx
的吞吐量比
zk
大很多,应该说按业务选择用哪种方式。
20. Zookeeper 有哪几种几种部署模式?
部署模式:单机模式、伪集群模式、集群模式。
集群规则为
2N+1
台,
N>0
,即
3
台。
其实就是水平扩容了,
Zookeeper
在这方面不太好。两种方式:
全部重启:关闭所有
Zookeeper
服务,修改配置之后启动。不影响之前客户端的会话。
逐个重启:在过半存活即可用的原则下,一台机器重启不影响整个集群对外提供服务。这是比较常用的方式。
3.5
版本开始支持动态扩容。
23. Zookeeper 对节点的 watch监听通知是永久的吗?为什么不是永久的?
不是。官方声明:一个
Watch
事件是一个一次性的触发器,当被设置了
Watch 的数据发生了改变的时候,则服务器将这个改变发送给设置了 Watch
的客户端,以便通知它们。
为什么不是永久的,举个例子,如果服务端变动频繁,而监听的客户端很多情况下,每次变动都要通知到所有的客户端,给网络和服务器造成很大压力。
一般是客户端执行
getData(“/
节点
A”,true)
,如果节点
A
发生了变更或删除,客户端会得到它的 watch
事件,但是在之后节点
A
又发生了变更,而客户端又没有设置 watch
事件,就不再给客户端发送。
在实际应用中,很多情况下,我们的客户端不需要知道服务端的每一次变动,我只要最新的数据即可。
24. Zookeeper 的 java 客户端都有哪些?
java
客户端:
zk
自带的
zkclient
及
Apache
开源的
Curator
。
25. chubby 是什么,和 zookeeper 比你怎么看?
chubby
是
google
的,完全实现
paxos
算法,不开源。
zookeeper
是
chubby的开源实现,使用 zab
协议,
paxos
算法的变种。
常用命令:
ls get set create delete
等。
27. ZAB 和 Paxos 算法的联系与区别?
相同点:
1
、两者都存在一个类似于
Leader
进程的角色,由其负责协调多个
Follower
进程的运行
2
、
Leader
进程都会等待超过半数的
Follower
做出正确的反馈后,才会将一个提案进行提交
3
、
ZAB
协议中,每个
Proposal
中都包含一个
epoch
值来代表当前的
Leader周期,Paxos
中名字为
Ballot
不同点:
ZAB
用来构建高可用的分布式数据主备系统(
Zookeeper
),
Paxos
是用来构建
分布式一致性状态机系统。
Zookeeper
是一个典型的发布
/
订阅模式的分布式数据管理与协调框架,开发人员可以使用它来进行分布式数据的发布和订阅。
通过对
Zookeeper
中丰富的数据节点进行交叉使用,配合
Watcher
事件通知机制,可以非常方便的构建一系列分布式应用中年都会涉及的核心功能,如:
1
、数据发布
/
订阅
2
、负载均衡
3
、命名服务
4
、分布式协调
/
通知
5
、集群管理
6
、
Master
选举
7
、分布式锁
8
、分布式队列