Zookeeper学习笔记

疑问

• 每当你自己学习一个新的知识点,学完后,你反问自己几个问题,如果你能答出个所以然来,或者在心中不在迷茫,说明这学习是有作用的。
• Zookeeper 是什么?
• Zookeeper的存储结构是什么?
• Zookeeper的角色有哪些?
• Zookeeper有哪些节点类型?
• Zookeeper怎么保持数据的一致性?
• Zookeeper如何进行数据同步的?

Zookeeper是什么?

• 标准答案:是一个分布式协调服务，可用于服务发现，分布式锁，分布式领导选举，配置管理等。
• 个人理解：是一个分布式服务,可以用于增删改查,一个客户端像服务端发送消息,如果是写请求,服务端的领班就会给它的小弟发送一个提议,这个提议就是该不该写,如果有一半的小弟是同意的,那么就返回给领班,领班就开始写入,然后同步给所有的小弟,这个效果在分布式里面就可以做到数据的强一致性.如果是读的请求,就直接返回消息给我们就好了.(这是站在客户端的角度上,我其实只用发送增删改查给服务端就好了)。

Zookeeper的存储结构是什么?

• zookkeeper 提供的名称空间非常类似于标准文件系统，key-value 的形式存储。名称 key 由斜线 / 分割的一系列路径元素，zookeeper 名称空间中的每个节点都是由一个路径标识。

Zookeeper的角色有哪些?

• Leader(领导者)
• 一个集群同一时间只有一个实际工作的leader,它会发起并维护各个Follower和Observer之间的心跳.
• 所有的写操作都必须通过leader来完成,再由leader把写操作广播给其他服务器,只要有超过半数的follower写入成功,该写请求就会被提交.
• Follower(随从)
• 一个集群可以有多个Follower,它会响应leader的心跳.
• 它可以直接处理并返回客户端的读请求,并将写请求转发给leader，处理.
• 它可以在leader处理写请求时对该请求进行投票.
• Observer(观察)
• 角色跟Follower类似,但是没有投票权.主要处理客户端传上来的请求,并将写请求转发给leader.因为它没有投票权,可以专心处理客户端传上来的请求,提高吞吐量.

Zookeeper有哪些节点类型?

• 持久化节点(PERSISTENT)
• 持久化节点,就是说,只要你不主动删除,就一直存在,包括zookeeper与客户端连接断开.
• 命令:create /节点名称
• 持久化顺序节点(PERSISTENT_SEQUENTIAL)
• 这个就是持久化的基础上,给node节点名称增加了顺序编号
• 命令:create -s /节点名称
• 临时节点(EPHEMERAL)
• 只要zookeeper与客户端连接断开,这节点就删除.
• 命令:create -e /节点名称
• 临时顺序节点(EPHEMERAL_SEQUENTIAL)
• 这个也是在临时节点的基础上,给node节点名称增加了顺序编号.
• 命令:create -e -s /节点名称

zookeeper节点有哪些重要信息呢，怎么进行查看？

• zookeeper节点可以通过stat命令来查看主要信息，其中信息有：
1. cZxid：创建znode的事务id（Zxid的值）。
2. mZxid：最后修改znode的事务id。
3. pZxid：最后添加或删除子节点的事务id（子节点列表发生变化才会发生改变）。
4. ctime：znode创建时间。
5. mtime：znode最近修改时间。
6. dataVersion：znode的当前数据版本。
7. cversion：znode的子节点结果集版本（一个节点的子节点增加、删除都会影响这个版本）。
8. aclVersion：表示对此znode的acl版本。
9. ephemeralOwner：znode是临时znode时，表示znode所有者的sessionid，如果znode不是临时节点，则该字段设置为零。
10. dataLength：znode数据字段的长度。
11. numChildren：该节点拥有子节点的数量（只统计直接子节点的数量）
• 命令: stat [path] 例: stat /runbo

Zookeeper怎么保持数据的一致性?

• ZooKeeper 是通过 Zab 协议来保证分布式事务的最终一致性.
• 正常情况下,客户端传一个写请求上来,都是由leader节点进行处理,然后生成一个Proposal提议给其他的follower,只要超过半数的follower通过该Proposal提议,那么leader就会提交commit,并向所有的follower发送commit消息,follower接收到后,就会把上一条事务提交.
• 详细流程:
1. 客户端发起一个写操作请求。
2. Leader 服务器将客户端的请求转化为事务 Proposal 提案，同时为每个 Proposal 分配一个全局的ID，即Zxid,Zxid 是单调递增的，以保证每个消息的先后顺序。
3. Leader 服务器为每个 Follower 服务器分配一个单独的队列，然后将需要广播的 Proposal 依次放到队列中取，并且根据 FIFO 策略进行消息发送(可以做到异步解耦)
4. Follower 接收到 Proposal 后，会首先将其以事务日志的方式写入本地磁盘中，写入成功后向 Leader 反馈一个 Ack 响应消息
5. Leader 接收到超过半数以上 Follower 的 Ack 响应消息后，即认为消息发送成功，可以发送 commit 消息。
6. Leader 向所有 Follower 广播 commit 消息，同时自身也会完成事务提交。Follower 接收到 commit 消息后，会将上一条事务提交。
• 这就是一个正常的消息广播具体步骤,只让leader进行写请求的处理,保证所有的服务器都能正确提交,保证了事务的强一致性.

那如果leader突然崩溃了,还能保证数据的一致性嘛?

• 能. leader崩溃一般有几种情况:
1. leader服务器将消息commit发出后,立刻崩溃.
2. leader服务器刚刚提出proposal后,立刻崩溃.
3. 半数follower突然宕机,使leader服务器崩溃.
• 针对这几种情况,我们进行崩溃恢复模式,主要分为三步 选举-数据同步-消息广播
• 选举: 因为leader服务器崩溃了,第一时间肯定要重新选取一个leader,要不然都运行不了.
• 优先比较epoch
• 然后比较zxid
• 最后比较myid
1. 首先各个follower节点变更状态为Looking,然后开始进入选举过程.
2. 每个follower首先会把投票投给自己,然后将自己的投票发送给集群的其他机器.
3. 对比规则如下:
4. epoch(名为逻辑时钟,用来区分leader的变化周期)：刚开始的每个follower都会给自己投一票,这个时候epoch会加一,每个服务器接收到投票后,首先会去判断投票的有效性,判断是否是本轮投票(用epoch来判断),是否来自状态为Looking的服务器.
5. 对比完epoch,就是对比zxid,zxid最大的优先作为leader 6.如果epoch和zxid都一样,则比较myid,myid大的优先,就是配置 zoo.cfg 中的 myid.
6. 只要有节点获得超过半数的投票,则该节点选为leader,改变服务器的状态为leader,其他服务器状态改为follower.
• 数据同步：leader选举出来了,就开始数据同步了.因为选举出来的leader的zxid是最大的,那么leader会根据自己服务器上最后一次提交的提议(Proposal)和follower服务器上的Proposal进行对比，比对的结果肯定是leader服务器让follower服务器回退到确实已经被集群中过半机器 Commit 的最新 Proposal
• 消息广播 就是按正常的流程走,上面已经说过.

zookeeper 端口

• zookeeper三个端口的作用
• 2181:对客户端提供服务的端口
• 2888:集群内机器通信使用的端口
• 3888:选举Leader使用的端口