Zookeeper技术
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
3. EPHEMERAL-临时目录节点 客户端与zookeeper断开连接后，该节点被删除 。
4. EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点 客户端与zookeeper断开连接后，节点被删除，只是Zookeeper给该节点名称进行顺序编号 。
8
Zookeeper创建节点示范
1. 创建持久化目录节点 create /zookeeper/demo/persistentNodeDemo 2. 创建持久化顺序编号目录节点 create -s /zookeeper/demo/persistentSequenceDemo 3. 创建临时目录节点 create -e /zookeeper/demo/ephemeralDemo 4. 创建临时顺序目录节点 create -e -s /zookeeper/demo/ephemeralSequenceDemo
4
目录
1. 什么是Zookeeper
2. Zookeeper提供什么
3. Paxos 4. FastLeaderElection原理 5. Zookeeper可以做什么
5
Zookeeper提供什么
1. 文件系统 2. 通知机制：客户端注册监听它关心的目录节点，当目录节点发生变化 （数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户 端。
7
Zookeeper节点类型
1. PERSISTENT-持久化目录节点 客户端与zookeeper断开连接后，节点依旧存在 。
2. PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点 客户端与zookeeper断开连接后，节点依旧存在，只是Zookeeper给该节点名称进行顺序编号 。
26
FastLeaderElection原理
1. myid
每个ZooKeeper服务器，都需要在数据文件夹下创建一个名为myid的文件， 该文件包含整个ZooKeeper集群唯一的ID（整数）。
例如，某ZooKeeper集群包含三台服务器，hostname分别为zoo1、zoo2和 zoo3，其myid分别为1、2和3，则在配置文件中其ID与hostname必须一一对应， 如下所示。在该配置文件中，server.后面的数据即为myid
server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888
27
FastLeaderElection原理
2. ZXID(Zookeeper Transaction Id)
用于标识一次更新操作的Proposal ID。为了保证顺序性，该zkid必须单调递 增。因此ZooKeeper使用一个64位的数来表示，高32位是Leader的epoch，从1开 始，每次选出新的Leader，epoch加一。低32位为该epoch内的序号，每次epoch 变化，都将低32位的序号重置。这样保证了zxid的全局递增性。
10
Zookeeper角色分类
11
写Leader
注意： •Leader 并 不 需 要 得 到 Observer 的 ACK ， 即 Observer无投票权 •Leader 不 需 要 得 到 所 有 Follower 的 ACK ， 只 要收到过半的ACK即可，同时Leader本身对自 己 有 一 个 ACK 。 上 图 中 有 4 个 Follower ， 只 需 其中两个返回ACK即可，因为(2+1) / (4+1) > 1/2 •Observer虽然无投票权，但仍须同步Leader 的数据从而在处理读请求时可以返回尽可能新 的数据
17
Paxos介绍-实例
接下来以两个假设的场景来演绎BasicPaxos；参谋和将军需要遵循一些基 本的规则 1） 参谋以两阶段提交（prepare/commit）的方式来发起提议，在prepare 阶段需要给出一个编号； 2） 在prepare阶段产生冲突，将军以编号大小来裁决，编号大的参谋胜出； 3） 参谋在prepare阶段如果收到了将军返回的已接受进攻时间，在 commit阶段必须使用这个返回的进攻时间；
Zookeeper 介绍
1
目录
1. 什么是Zookeeper 2. Zookeeper提供什么 3. Paxos 4. FastLeaderElection原理 5. Zookeeper可以做什么
2
目录
1. 什么是Zookeeper
2. Zookeeper提供什么 3. Paxos 4. FastLeaderElection原理 5. Zookeeper可以做什么
决方案要能适应分布式环境下的不可靠性（系统如何就一个值达到统一）
16
Paxos介绍-实例
1） 1支红军在山谷里扎营，在周围的山坡上驻扎着3支蓝军； 2） 红军比任意1支蓝军都要强大；如果1支蓝军单独作战，红军胜；如果 2支或以上蓝军同时进攻，蓝军胜； 3） 三支蓝军需要同步他们的进攻时间；但他们惟一的通信媒介是派通信 兵步行进入山谷，在那里他们可能被俘虏，从而将信息丢失； 4） 每支军队有1个参谋负责提议进攻时间；每支军队也有1个将军批准参 谋提出的进攻时间；很明显，1个参谋提出的进攻时间需要获得至少2个将 军的批准才有意义； 问题：是否存在一个协议，能够使得蓝军同步他们的进攻时间？
更新自己的选票并广播出去，并将合适的选票存入 自己的票箱
34
一、集群启动领导选举
3.根据选票确定角色 三个服务器一致认为此时服务器3应该是Leader。
因此服务器1和2都进入FOLLOWING状态，而服务 器3进入LEADING状态。之后Leader发起并维护与 Follower间的心跳。
35
二、Follower重启选举
21
Paxos介绍-两个原则
1. 安全原则---保证不能做错的事 a） 针对某个实例的表决只能有一个值被批准，不能出现一个被批准的值 被另一个值覆盖的情况；(假设有一个值被多数Acceptor批准了，那么这个 值就只能被学习) b） 每个节点只能学习到已经被批准的值，不能学习没有被批准的值。 2. 存活原则---只要有多数服务器存活并且彼此间可以通信，最终都要做到 的下列事情： a）最终会批准某个被提议的值； b）一个值被批准了，其他服务器最终会学习到这个值。
12
写Follower/Observer
13Baidu Nhomakorabea
读操作
14
目录
1. 什么是Zookeeper 2. Zookeeper提供什么
3. Paxos
4. FastLeaderElection原理 5. Zookeeper可以做什么
15
Paxos介绍-目的
Paxos算法的目的是为了解决分布式环境下一致性的问题。 多个节点并发操纵数据，如何保证在读写过程中数据的一致性，并且解
Leader选举时，如果服务器不是同时启动，而是顺序启 动，投票是如何进行的？
37
三、Leader重启选举
1. Follower发起新投票 Leader（服务器3）宕机后，Follower（服务器1和2）
发现Leader不工作了，因此进入LOOKING状态并发起 新的一轮投票，并且都将票投给自己。
否则继续接收其它服务器的投票。 3）更新服务器状态
投票终止后，服务器开始更新自身状态。若过半的票投给了自己，则将自己的服务器 状态更新为LEADING，否则将自己的状态更新为FOLLOWING。
32
一、集群启动领导选举
1.初始投票给自己 集群刚启动时，所有服务器的logicClock都为1，zxid
18
Paxos介绍-实例
19
Paxos介绍-实例
20
Paxos介绍-两个组件
1.Proposer 提议发起者，处理客户端请求，将客户端的请求发送到集群中，以便决定 这个值是否可以被批准。 2.Acceptor 提议批准者，负责处理接收到的提议，他们的回复就是一次投票。会存储 一些状态来决定是否接收一个值
都为0。各服务器初始化后，都投票给自己，并将自己的 一票存入自己的票箱。 (1, 1, 0) 第一位数代表投出该选票的服务器的logicClock 第二位数代表被推荐的服务器的myid 第三位代表被推荐的服务器的最大的zxid。
33
一、集群启动领导选举
2.更新选票 服务器收到外部投票后，进行选票PK，相应
22
Paxos介绍-原理
23
Paxos介绍-原理
24
目录
1. 什么是Zookeeper
2. Zookeeper提供什么
3. Paxos
4. FastLeaderElection原理
5. Zookeeper可以做什么
25
zookeeper支持的领导选举算法
到3.4.10版本为止，可选项有： 0 基于UDP的LeaderElection 1 基于UDP的FastLeaderElection 2 基于UDP和认证的FastLeaderElection 3 基于TCP的FastLeaderElection（默认）
28
FastLeaderElection原理
3.服务器状态
LOOKING 不确定Leader状态。 FOLLOWING 跟随者状态。 LEADING 领导者状态。 OBSERVING 观察者状态。
29
FastLeaderElection原理
4.选票数据结构
每个服务器在进行领导选举时，会发送如下关键信息： 1) logicClock 每个服务器会维护一个自增的整数，名为logicClock，它表示这是该 服务器发起的第多少轮投票 2) state 当前服务器的状态 3) self_id 当前服务器的myid 4) self_zxid 当前服务器上所保存的数据的最大zxid 5) vote_id 被推举的服务器的myid 6) vote_zxid 被推举的服务器上所保存的数据的最大zxid
6
Zookeeper体系结构
类似文件系统目录结构，节点路径唯一，而且能存储少量数 据。
图中的每个节点称为一个znode. 每个znode由3部分组成:
State：此为状态信息, 描述该znode的版本, 权限等信息. Data：与该znode关联的数据. Children：该znode下的子节点.
31
FastLeaderElection原理
1) 选票PK (self_id, self_zxid)与(vote_id, vote_zxid) pk 后更新(self_id, self_zxid) 优先级 logicClock > zxid > myid
2）统计选票 如果已经确定有过半服务器认可了自己的投票（可能是更新后的投票），则终止投票。
1. Follower重启投票给自己 Follower重启，或者发生网络分区后找不到Leader，
会进入LOOKING状态并发起新的一轮投票。
36
二、Follower重启选举
2. 发现已有Leader后为Follower Follower重启，或者发生网络分区后找不到Leader，
会进入LOOKING状态并发起新的一轮投票。
3
什么是zookeeper
Zookeeper是Googel的Chubby的一个开源实现，是Hadoop的分布式 协调服务，它包好了一个简单的原语，是一个典型的分布式数据一致性解决方
案。设计目的是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高 效可靠的系统，并以一系列简单易用的原子操作提供给用户使用。
9
Zookeeper节点watches
Zookeeper对Node的增、删、改都可触发监听。 Watch事件是一次性触发器，当watch监视的发生变化时，通知 设置了该watch的client。
Watch事件是异步发送给观察者。 Watch是一次性触发的,并且在获取watch事件和设置新的watch 事件之间有延迟。延迟为毫秒级别
30
FastLeaderElection原理
自增选举轮次 ZooKeeper规定所有有效的投票都必须在同一轮次中。每个服务器在开始新一轮投票
时，会先对自己维护的logicClock进行自增操作。 初始化选票
每个服务器最开始都是通过广播把票投给自己。 每个服务器在广播自己的选票前，会将自己的投票箱清空。 接收外部投票 服务器会尝试从其它服务器获取投票，并记入自己的投票箱内。(有可能获取不到)
4. EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点 客户端与zookeeper断开连接后，节点被删除，只是Zookeeper给该节点名称进行顺序编号 。
8
Zookeeper创建节点示范
1. 创建持久化目录节点 create /zookeeper/demo/persistentNodeDemo 2. 创建持久化顺序编号目录节点 create -s /zookeeper/demo/persistentSequenceDemo 3. 创建临时目录节点 create -e /zookeeper/demo/ephemeralDemo 4. 创建临时顺序目录节点 create -e -s /zookeeper/demo/ephemeralSequenceDemo
4
目录
1. 什么是Zookeeper
2. Zookeeper提供什么
3. Paxos 4. FastLeaderElection原理 5. Zookeeper可以做什么
5
Zookeeper提供什么
1. 文件系统 2. 通知机制：客户端注册监听它关心的目录节点，当目录节点发生变化 （数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户 端。
7
Zookeeper节点类型
1. PERSISTENT-持久化目录节点 客户端与zookeeper断开连接后，节点依旧存在 。
2. PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点 客户端与zookeeper断开连接后，节点依旧存在，只是Zookeeper给该节点名称进行顺序编号 。
26
FastLeaderElection原理
1. myid
每个ZooKeeper服务器，都需要在数据文件夹下创建一个名为myid的文件， 该文件包含整个ZooKeeper集群唯一的ID（整数）。
例如，某ZooKeeper集群包含三台服务器，hostname分别为zoo1、zoo2和 zoo3，其myid分别为1、2和3，则在配置文件中其ID与hostname必须一一对应， 如下所示。在该配置文件中，server.后面的数据即为myid
server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888
27
FastLeaderElection原理
2. ZXID(Zookeeper Transaction Id)
用于标识一次更新操作的Proposal ID。为了保证顺序性，该zkid必须单调递 增。因此ZooKeeper使用一个64位的数来表示，高32位是Leader的epoch，从1开 始，每次选出新的Leader，epoch加一。低32位为该epoch内的序号，每次epoch 变化，都将低32位的序号重置。这样保证了zxid的全局递增性。
10
Zookeeper角色分类
11
写Leader
注意： •Leader 并 不 需 要 得 到 Observer 的 ACK ， 即 Observer无投票权 •Leader 不 需 要 得 到 所 有 Follower 的 ACK ， 只 要收到过半的ACK即可，同时Leader本身对自 己 有 一 个 ACK 。 上 图 中 有 4 个 Follower ， 只 需 其中两个返回ACK即可，因为(2+1) / (4+1) > 1/2 •Observer虽然无投票权，但仍须同步Leader 的数据从而在处理读请求时可以返回尽可能新 的数据
17
Paxos介绍-实例
接下来以两个假设的场景来演绎BasicPaxos；参谋和将军需要遵循一些基 本的规则 1） 参谋以两阶段提交（prepare/commit）的方式来发起提议，在prepare 阶段需要给出一个编号； 2） 在prepare阶段产生冲突，将军以编号大小来裁决，编号大的参谋胜出； 3） 参谋在prepare阶段如果收到了将军返回的已接受进攻时间，在 commit阶段必须使用这个返回的进攻时间；
Zookeeper 介绍
1
目录
1. 什么是Zookeeper 2. Zookeeper提供什么 3. Paxos 4. FastLeaderElection原理 5. Zookeeper可以做什么
2
目录
1. 什么是Zookeeper
2. Zookeeper提供什么 3. Paxos 4. FastLeaderElection原理 5. Zookeeper可以做什么
决方案要能适应分布式环境下的不可靠性（系统如何就一个值达到统一）
16
Paxos介绍-实例
1） 1支红军在山谷里扎营，在周围的山坡上驻扎着3支蓝军； 2） 红军比任意1支蓝军都要强大；如果1支蓝军单独作战，红军胜；如果 2支或以上蓝军同时进攻，蓝军胜； 3） 三支蓝军需要同步他们的进攻时间；但他们惟一的通信媒介是派通信 兵步行进入山谷，在那里他们可能被俘虏，从而将信息丢失； 4） 每支军队有1个参谋负责提议进攻时间；每支军队也有1个将军批准参 谋提出的进攻时间；很明显，1个参谋提出的进攻时间需要获得至少2个将 军的批准才有意义； 问题：是否存在一个协议，能够使得蓝军同步他们的进攻时间？
更新自己的选票并广播出去，并将合适的选票存入 自己的票箱
34
一、集群启动领导选举
3.根据选票确定角色 三个服务器一致认为此时服务器3应该是Leader。
因此服务器1和2都进入FOLLOWING状态，而服务 器3进入LEADING状态。之后Leader发起并维护与 Follower间的心跳。
35
二、Follower重启选举
21
Paxos介绍-两个原则
1. 安全原则---保证不能做错的事 a） 针对某个实例的表决只能有一个值被批准，不能出现一个被批准的值 被另一个值覆盖的情况；(假设有一个值被多数Acceptor批准了，那么这个 值就只能被学习) b） 每个节点只能学习到已经被批准的值，不能学习没有被批准的值。 2. 存活原则---只要有多数服务器存活并且彼此间可以通信，最终都要做到 的下列事情： a）最终会批准某个被提议的值； b）一个值被批准了，其他服务器最终会学习到这个值。
12
写Follower/Observer
13Baidu Nhomakorabea
读操作
14
目录
1. 什么是Zookeeper 2. Zookeeper提供什么
3. Paxos
4. FastLeaderElection原理 5. Zookeeper可以做什么
15
Paxos介绍-目的
Paxos算法的目的是为了解决分布式环境下一致性的问题。 多个节点并发操纵数据，如何保证在读写过程中数据的一致性，并且解
Leader选举时，如果服务器不是同时启动，而是顺序启 动，投票是如何进行的？
37
三、Leader重启选举
1. Follower发起新投票 Leader（服务器3）宕机后，Follower（服务器1和2）
发现Leader不工作了，因此进入LOOKING状态并发起 新的一轮投票，并且都将票投给自己。
否则继续接收其它服务器的投票。 3）更新服务器状态
投票终止后，服务器开始更新自身状态。若过半的票投给了自己，则将自己的服务器 状态更新为LEADING，否则将自己的状态更新为FOLLOWING。
32
一、集群启动领导选举
1.初始投票给自己 集群刚启动时，所有服务器的logicClock都为1，zxid
18
Paxos介绍-实例
19
Paxos介绍-实例
20
Paxos介绍-两个组件
1.Proposer 提议发起者，处理客户端请求，将客户端的请求发送到集群中，以便决定 这个值是否可以被批准。 2.Acceptor 提议批准者，负责处理接收到的提议，他们的回复就是一次投票。会存储 一些状态来决定是否接收一个值
都为0。各服务器初始化后，都投票给自己，并将自己的 一票存入自己的票箱。 (1, 1, 0) 第一位数代表投出该选票的服务器的logicClock 第二位数代表被推荐的服务器的myid 第三位代表被推荐的服务器的最大的zxid。
33
一、集群启动领导选举
2.更新选票 服务器收到外部投票后，进行选票PK，相应
22
Paxos介绍-原理
23
Paxos介绍-原理
24
目录
1. 什么是Zookeeper
2. Zookeeper提供什么
3. Paxos
4. FastLeaderElection原理
5. Zookeeper可以做什么
25
zookeeper支持的领导选举算法
到3.4.10版本为止，可选项有： 0 基于UDP的LeaderElection 1 基于UDP的FastLeaderElection 2 基于UDP和认证的FastLeaderElection 3 基于TCP的FastLeaderElection（默认）
28
FastLeaderElection原理
3.服务器状态
LOOKING 不确定Leader状态。 FOLLOWING 跟随者状态。 LEADING 领导者状态。 OBSERVING 观察者状态。
29
FastLeaderElection原理
4.选票数据结构
每个服务器在进行领导选举时，会发送如下关键信息： 1) logicClock 每个服务器会维护一个自增的整数，名为logicClock，它表示这是该 服务器发起的第多少轮投票 2) state 当前服务器的状态 3) self_id 当前服务器的myid 4) self_zxid 当前服务器上所保存的数据的最大zxid 5) vote_id 被推举的服务器的myid 6) vote_zxid 被推举的服务器上所保存的数据的最大zxid
6
Zookeeper体系结构
类似文件系统目录结构，节点路径唯一，而且能存储少量数 据。
图中的每个节点称为一个znode. 每个znode由3部分组成:
State：此为状态信息, 描述该znode的版本, 权限等信息. Data：与该znode关联的数据. Children：该znode下的子节点.
31
FastLeaderElection原理
1) 选票PK (self_id, self_zxid)与(vote_id, vote_zxid) pk 后更新(self_id, self_zxid) 优先级 logicClock > zxid > myid
2）统计选票 如果已经确定有过半服务器认可了自己的投票（可能是更新后的投票），则终止投票。
1. Follower重启投票给自己 Follower重启，或者发生网络分区后找不到Leader，
会进入LOOKING状态并发起新的一轮投票。
36
二、Follower重启选举
2. 发现已有Leader后为Follower Follower重启，或者发生网络分区后找不到Leader，
会进入LOOKING状态并发起新的一轮投票。
3
什么是zookeeper
Zookeeper是Googel的Chubby的一个开源实现，是Hadoop的分布式 协调服务，它包好了一个简单的原语，是一个典型的分布式数据一致性解决方
案。设计目的是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高 效可靠的系统，并以一系列简单易用的原子操作提供给用户使用。
9
Zookeeper节点watches
Zookeeper对Node的增、删、改都可触发监听。 Watch事件是一次性触发器，当watch监视的发生变化时，通知 设置了该watch的client。
Watch事件是异步发送给观察者。 Watch是一次性触发的,并且在获取watch事件和设置新的watch 事件之间有延迟。延迟为毫秒级别
30
FastLeaderElection原理
自增选举轮次 ZooKeeper规定所有有效的投票都必须在同一轮次中。每个服务器在开始新一轮投票
时，会先对自己维护的logicClock进行自增操作。 初始化选票
每个服务器最开始都是通过广播把票投给自己。 每个服务器在广播自己的选票前，会将自己的投票箱清空。 接收外部投票 服务器会尝试从其它服务器获取投票，并记入自己的投票箱内。(有可能获取不到)