zookeeper
2021-08-02 19:20:04 1 举报AI智能生成
zookeeper关键知识点总结
作者其他创作
大纲/内容
什么是zookeeper
zookeeper 是一个分布式协调服务。它是一个为分布式应用提供一致性服务的软件，分布式应用基本zookeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、分布式锁和分布式队列等功能。
通俗地讲，Zookeeper是一个用于存储少量数据的基于内存的数据库
zookeeper两个核心概念
文件系统数据结构
持久化节点【PERSISTENT】
客户端与zookeeper断开连接后，该节点依旧存在，只要不手动删除该节点，他将永远存在
持久化顺序编号目录节点【PERSISTENT_SEQUENTIAL】
客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
临时目录节点【EPHEMERAL】
客户端与zookeeper断开连接后，该节点被删除
临时顺序编号目录节点【EPHEMERAL_SEQUENTIAL】
客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号
Container 节点
3.5.3 版本新增
如果container节点下面没有子节点，则container节点在未来会被定时任务清除，默认60s检查一次
TTL节点
默认是禁用的
过了TTL指定的时间时，会被服务器删除
监听通知机制
客户端注册监听它关心的任意节点，或者目录节点及递归子目录节点
如果节点发送变更时，会通知监听它的客户端，只会通知一次
Zookeeper的ACL权限控制
权限模式（Scheme）
范围验证
可以针对一个 IP 或者一段 IP 地址授予某种权限
口令验证
可以理解为用户名密码的方式。在 ZooKeeper 中这种验证方 式是 Digest 认证
授权对象（ID）
授权对象就是说我们要把权限赋予谁，而对应于 4 种不同的权限模式来说，如果我们选择采用 IP 方式，使用的授权对象可以是一个 IP 地址或 IP 地址段；而如果使用 Digest 或 Super 方式，则 对应于一个用户名。如果是 World 模式，是授权系统中所有的用户。
权限信息 （Permission）
权限就是指我们可以在数据节点上执行的操作种类
在 ZooKeeper 中已经定义好的权限有 5 种
数据节点（c: create）创建权限，授予权限的对象可以在数据节点下创建子节点；
数据节点（w: wirte）更新权限，授予权限的对象可以更新该数据节点；
数据节点（r: read）读取权限，授予权限的对象可以读取该节点的内容以及子节点的列表信息
数据节点（d: delete）删除权限，授予权限的对象可以删除该数据节点的子节点；
数据节点（a: admin）管理者权限，授予权限的对象可以对该数据节点体进行 ACL 权限设置
zookeeper集群角色
leader
负责进行投票的发起和决议，更新系统状态
follower
用于接收客户端请求并向客户端返回结果以及在选举过程中参与投票
observer
也可以接收客户端连接，将写请求转发给leader节点，但是不参与投票过程，只同步leader的状态。通常对查询操作做负载
zookeeper下Server的工作状态
LOOKING
寻 找 Leader 状态。当服务器处于该状态时，它会认为当前集群中没有 Leader，因此需要进入 Leader 选举状态。
FOLLOWING
跟随者状态。表明当前服务器角色是 Follower。
LEADING
领导者状态。表明当前服务器角色是 Leader。
OBSERVING
观察者状态。表明当前服务器角色是 Observer
zookeeper的应用场景
分布式锁
org.apache.curator -> curator-recipes 中有用zookeeper实现的分布式锁
独享锁、公平锁
InterProcessMutex
共享锁（分读写锁）
InterProcessLock
主要运用了分布式锁的container节点顺序节点来实现
注册中心
服务注册和发现
与dubbo结合实现微服务
springcloud zookeeper
集群选举
分布式队列
分布式配置中心
zookkeeper的leader选举
初始化的时候，所有节点都是looking状态
获取serverId，获取最大的事务ID,发起投票
接受别的机器的选票，进行比较，比较zxid和myid
事务ID最大的优先获得选票，如果事务zxid相同，则serverId越大的优先获得选票
zookeeper一致性协议
zab
zookeeper原子广播协议
ZAB是Paxos算法的一种简化实现
在zab协议中，所有的写入数据，都是写到leader中，然后由leader同步给follower,从而保证数据的一致性
消息广播过程
收到数据变更请求
向follower发送proposal
收到半数以上的follower的ack,则执行数据变更
补充
Leader 在收到客户端请求之后，会将这个请求封装成一个事务，并给这个事务分配一个全局递增的唯一 ID，称为事务 ID（ZXID），ZAB 协议需要保证事务的顺序，因此必须将每一个事务按照 ZXID 进行先后排序然后处理，主要通过消息队列实现。
在 Leader 和 Follwer 之间还有一个消息队列，用来解耦他们之间的耦合，解除同步阻塞。
zookeeper集群中为保证任何所有进程能够有序的顺序执行，只能是 Leader 服务器接受写请求，即使是 Follower 服务器接受到 客户端的写请求，也会转发到 Leader 服务器进行处理，Follower只能处理读请求。
ZAB协议规定了如果一个事务在一台机器上被处理(commit)成功，那么应该在所有的机器上都被处理成功，哪怕机器出现故障 崩溃。
崩溃恢复
两大原则
ZAB 协议确保丢弃那些只在 Leader 提出/复制，但没有提交的事务。
ZAB 协议确保那些已经在 Leader 提交的事务最终会被所有服务器提交。
场景一：Leader 在复制数据给所有 Follwer 之后，还没来得及收到Follower的ack返回就崩溃
本次数据丢弃
场景二：Leader 在收到 ack 并提交了自己，同时发送了部分 commit 出去之后崩溃
本次数据视为有效
0 条评论
下一页
