1、常用命令

ls、get、create、delete

2、Paxos算法和ZAB协议(扩展)

待进一步解释!!!

3、讲一讲什么是CAP法则?Zookeeper符合了这个法则的哪两个?(扩展)

CAP法则:

CAP理论告诉我们,一个分布式系统不可能同时满足以下三种:

一致性(C:Consistency)

可用性(A:Available)

分区容错性(P:Partition Tolerance)

这三个基本需求,最多只能同时满足其中的两项,因为P是必须的,因此往往选择就在CP或者AP中。

(1)一致性(C:Consistency)

在分布式环境中,一致性是指数据在多个副本之间是否能够保持数据一致的特性。在一致性的需求下,当一个系统在数据一致的状态下执行更新操作后,应该保证系统的数据仍然处于一致的状态。

(2)可用性(A:Available)

可用性是指系统提供的服务必须一直处于可用的状态,对于用户的每一个操作请求总是能够在有限的时间内返回结果。

(3)分区容错性(P:Partition Tolerance)

分布式系统在遇到任何网络分区故障的时候,仍然需要能够保证对外提供满足一致性和可用性的服务,除非是整个网络环境都发生了故障。

ZooKeeper保证的是CP

(1)ZooKeeper不能保证每次服务请求的可用性。(注:在极端环境下,ZooKeeper可能会丢弃一些请求,消费者程序需要重新请求才能获得结果)。所以说,ZooKeeper不能保证服务可用性。

(2)进行Leader选举时集群都是不可用。

4、选举机制

半数机制:2n + 1,安装奇数台

10台服务器:3台

20台服务器:5台

100台服务器:11台

台数多,好处:提高可靠性;坏处:影响通信延时

(1)第一次启动

zookeeper ACL 递归权限 zookeeper符合cap_面试

<1>服务器1启动,发起一次选举。服务器1投自己一票。此时服务器1票数一票,不够半数以上(3票),选举无法完成,服务器1状态保持为LOOKING;

<2>服务器2启动,再发起一次选举。服务器1和2分别投自己一票并交换选票信息:此时服务器1发现服务器2的myid比自己目前投票推举的(服务器1)大,更改选票为推举服务器2。此时服务器1票数0票,服务器2票数2票,没有半数以上结果,选举无法完成,服务器1,2状态保持LOOKING;

<3>服务器3启动,发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果:服务器1为0票,服务器2为0票,服务器3为3票。此时服务器3的票数已经超过半数,服务器3当选Leader。服务器1,2更改状态为FOLLOWING,服务器3更改状态为LEADING;

<4>服务器4启动,发起一次选举。此时服务器1,2,3已经不是LOOKING状态,不会更改选票信息。交换选票信息结果:服务器3为3票,服务器4为1票。此时服务器4服从多数,更改选票信息为服务器3,并更改状态为FOLLOWING;

<5>服务器5启动,同4一样当小弟。

(2)非第一次启动

zookeeper ACL 递归权限 zookeeper符合cap_面试_02

 

<1>当ZooKeeper集群中的一台服务器出现以下两种情况之一时,就会开始进入Leader选举:

①服务器初始化启动。

②服务器运行期间无法和Leader保持连接。

<2>而当一台机器进入Leader选举流程时,当前集群也可能会处于以下两种状态:

 ①集群中本来就已经存在一个Leader。

 对于第一种已经存在Leader的情况,机器试图去选举Leader时,会被告知当前服务器的Leader信息,对于该机器来说,仅仅需要和Leader机器建立连接,并进行状态同步即可。

 ②集群中确实不存在Leader。

假设ZooKeeper由5台服务器组成,SID分别为1、2、3、4、5,ZXID分别为8、8、8、7、7,并且此时SID为3的服务器是Leader。某一时刻,3和5服务器出现故障,因此开始进行Leader选举。

(EPOCH,ZXID,SID )

(EPOCH,ZXID,SID )

(EPOCH,ZXID,SID )

SID为1、2、4的机器投票情况:

(1,8,1)

(1,8,2)

(1,7,4)

选举Leader规则:

①EPOCH大的直接胜出

②EPOCH相同,事务id大的胜出

③事务id相同,服务器id大的胜出