zookeeper知识点
2021-11-09 19:20:56 24 举报AI智能生成
zookeeper知识点
作者其他创作
大纲/内容
简介
数据模型类似于文件夹的树状结构，每一个节点都叫做znode
每个节点都带有版本号，数据变更时，版本号(乐观锁)变更。
客户端向服务端ping包请求的心跳机制来检查session是否过期，<br>session过期的时候，该session创建的所有临时节点都会被抛弃。
myid
服务器server id，通过配置文件配置，集群内唯一
epoch
选举周期，每次选举最终确定完leader结束选举流程时会自增
zxid
zxid是一个64位数字。高32位为epoch，低32位自增计数器
每个新leader都有新的epoch
节点
分类
persistent
持久化节点
persistent_sequential
持久化顺序节点
ephemeral
临时节点
ephemeral_sequential
临时顺序节点
说明
临时节点在创建者超时或失去连接后节点就会被删除，临时节点下面没有子节点
持久化节点只能主动调用detele方法删除
顺序节点在创建后会自动在后面添加序列号
ACL
访问控制列表 Access Control List
每个节点都有一个访问控制列表
Watch
<span style="font-size: inherit;">客户端可以再znode上设置监视，znode更改时，将触发并删除监视并通知客户端</span><br>
<b><font color="#c41230">3.6.0开始支持永久性Watch</font></b>
API
create
在树中创建节点
delete
删除节点
exists
位置是否存在节点
get data
读节点
set data
写节点
get children
获取子节点列表
会话（Session）
概念：客户端和服务端的一个连接就是一个会话
结构
会话ID（SessionID）
会话 ID 作为一个会话的标识符，当我们创建一次会话的时候，ZooKeeper 会自动为其分配一个唯一的 ID 编码。
会话超时时间（TimeOut）
一个会话的超时时间就是指一次会话从发起后到被服务器关闭的时长。<br>而设置会话超时时间后，服务器会参考设置的超时时间，最终计算一个服务端自己的超时时间。<br>而这个超时时间则是最终真正用于 ZooKeeper 中服务端用户会话管理的超时时间。<br>
ZooKeeper 服务端收到 Ping 操作的请求时，会根据服务端的当前时间重置与客户端的 Session 时间，更新该会话的请求延迟时间等。<br>进而保持客户端与服务端连接状态。<br>
会话关闭状态（isClosing）
会话关闭 isClosing 状态属性字段表示一个会话是否已经关闭。<br>如果服务器检查到一个会话已经因为超时等原因失效时， ZooKeeper 会在该会话的 isClosing 属性值标记为关闭，再之后就不对该会话进行操作了。<br>
状态：
正在连接（CONNECTING）、已经连接（CONNECTIED）、正在重新连接（RECONNECTING）、已经重新连接（RECONNECTED）、会话关闭（CLOSE）
会话管理：分桶策略
将过期时间相近的会话放在一个桶中 backet，这样的话，在检查的时候和在执行过期的时候以backet为单位，会提高检查的效率，不用一个个的检查了。
Watcher监控机制
集群
节点角色
leader
一个集群只有一个leader，处理读写请求，负责进行发起投票和决议，更新系统状态，并管理协调集群中的 Follower 角色服务器。
follower
处理读请求，将写请求转发给leader，具有投票权和选举权
observer
没有投票和选举资格，用来处理读请求，用以增加吞吐量<br>
随着集群规模的变大，集群处理事务性会话的性能反而下降
ZooKeeper 集群无法做到跨域部署
同步逻辑
时机
在完成leader选举后，接收客户端请求前
新加入节点
follower将自己最大zxid发送给leader
leader根据follower的zxid来确定同步点
leader向follower发送proposal消息，并且紧跟着一条commit消息，标识该事物已经被提交
同步完成后follower状态变为update，提供服务
ZAB（Zookeeper Atomic Broadcast ，Zookeeper 原子广播协议）
消息广播
leader将写请求以proposal(提议)的形式发送给所有follower,生成一个zxid，并等待ACK（应答）
follower接收到proposal后先写事务日志到磁盘，再返回ACK
leader得到过半数的ACK（自己算一个ack）后，向所有的follower和observer发送commit
leader将处理结果返回给客户端
崩溃恢复
leader选举
选举过程
判断Leader失效
Follow 服务器会定期向 Leader 服务器发送 网络请求，在接收到请求后，Leader 服务器会返回响应数据包给 Follow 服务器，而在 Follow 服务器接收到 Leader 服务器的响应后，如果判断 Leader 服务器运行正常，则继续进行数据同步和服务转发等工作，反之，则进行 Leader 服务器的重新选举操作。
重新选举<br>
如果是集群中个别的 Follow 服务器发现返回错误，并不会导致 ZooKeeper 集群立刻重新选举 Leader 服务器，而是将该 Follow 服务器的状态变更为 LOOKING 状态，并向网络中发起投票，当 ZooKeeper 集群中有更多的机器发起投票，最后当投票结果满足多数原则的情况下。ZooKeeper 会重新选举出 Leader 服务器。
Follower角色变更
数据同步
挂起客户端会话，且Leader选举期间的时间窗口不计入会话过期时间内
选举标准
根据服务器自身的服务器 ID（SID）、最新的 ZXID、和当前的服务器 epoch （currentEpoch）这三个参数来生成一个选举标准
选举算法
描述：根据 zoo.cfg 配置文件中的参数，选择参数文件中规定的 Leader 选举算法，进行 Leader 头节点的选举操作
算法：zoo.cfg 配置文件中使用 electionAlg 参数
LeaderElection
FastLeaderElection
<b><font color="#c41230">3.4.0开始，只支持这一种算法</font></b>
AuthFastLeaderElection
选举细节
服务器状态
<ul><li>LOOKING：寻找Leader状态。当服务器处于该状态时，它会认为当前集群中没有Leader，因此需要进入Leader选举状态。</li><li>FOLLOWING：跟随者状态。表明当前服务器角色是Follower。</li><li>LEADING：领导者状态。表明当前服务器角色是Leader。</li><li>OBSERVING：观察者状态。表明当前服务器角色是Observer。</li></ul>
Vote数据结构
每个投票中包含了两个最基本的信息，所推举服务器的SID和ZXID，投票（Vote）在Zookeeper中包含字段如下<br><br><ul><li>id：被推举的Leader的SID。</li><li>zxid：被推举的Leader事务ID。</li><li>electionEpoch：逻辑时钟，用来判断多个投票是否在同一轮选举周期中，该值在服务端是一个自增序列，每次进入新一轮的投票后，都会对该值进行加1操作。</li><li>peerEpoch：被推举的Leader的epoch。</li><li>state：当前服务器的状态。</li></ul>
0 条评论
下一页
