Zookeeper
2020-07-02 10:17:04 1 举报AI智能生成
ZooKeeper知识点
作者其他创作
大纲/内容
定义
A Distributed Coordination Service for Distributed Applications.
特性
顺序一致性
从同一个客户端发起的事务请求，最终将会严格地按照其发起顺序被应用到ZooKeeper中去。
原子性
数据要么成功，要么失败，不会局部化。
单一视图
无论客户端连接的是哪个ZooKeeper服务器，其看到的数据都是一致的。
可靠性
一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会被一直保留下来，除非有另一个事务又对其进行了变更。
实时性
通常人们看到实时性的第一反应是，一旦一个事务被成功应用，那么客户端能够立即从服务端上读取到这个事务变更后的最新数据状态。这里需要注意的是，ZooKeeper仅仅保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。
设计目标
简单的数据模型
基本数据模型
可以构建集群
顺序访问
高性能
ZooKeeper的基本概念
集群角色
Leader
为客户端提供读写服务
Follower
Follower和Observer都能提供读服务，Observer不参与Leader选举过程，也不参与写操作的“过半写成功”策略，因此Observer可以在不影响写性能的情况下提高集群的读性能。
Observer
Session会话
数据节点ZNode
树形结构
每个节点称为ZNode，可以有子节点
每个节点分为临时节点和永久节点，临时节点在客户端断开后（会话失效）消失
每个节点还有一个属性：SEQUENTIAL，一旦节点被标记上这个属性，那么在这个节点被创建的时候，ZooKeeper会自动在其节点名后面追加上一个整型数字，这个整型数字是一个由父节点维护的自增数字。
每个节点都有各自的版本号，可以通过命令行显示节点信息
每个节点数据发生变化，那么该节点的版本号会累加（乐观锁）
删除/修改过时节点，版本号不匹配会报错
每个节点存储的数据不宜过大，几K即可
节点可以设置权限
版本
每个节点都有一个Stat的数据结构。Stat中记录了这个ZNode的三个数据版本，分别是version（当前ZNode的版本）、cversion（当前ZNode子节点的版本）和aversion（当前ZNode的ACL版本）。
Watcher
针对每个节点的操作，都会有一个监督者watcher
当监控的某个节点发生变化，触发watcher事件
watcher是一次性的，触发后立即销毁
父节点和子节点的增删改都能触发其watcher事件
Watcher事件类型
创建父节点
NodeCreated
修改父节点数据
NodeDataChanged
删除父节点
NodeDeleted
ls为父节点设置watcher，创建子节点
NodeChildrenChanged
ls为父节点设置watcher，删除子节点
NodeChildrenChanged
ls为父节点设置watcher，修改子节点
不触发事件
修改子节点时，如果想要触发事件，需要把子节点当做父节点来修改，即使用相同命令，不用ls
使用场景
统一资源配置
ACL
CREATE：创建子节点的权限。
READ：获取节点数据和子节点列表的权限。
WRITE：更新节点数据的权限。
DELETE：删除子节点的权限。
ADMIN：设置节点ACL的权限。
zk的作用
master节点选举，主节点挂了以后，从节点就会接手工作，并且保证这个节点是唯一的，从而保证集群是高可用的，这就是首脑模式。
统一配置文件管理，即只需要部署一台服务器，则可以把相同的配置文件同步更新到其他所有服务器。
发布与订阅。发布者把数据存在znode上，订阅者读取这个数据。
提供分布式锁。
集群管理，集群中保证数据的强一致性。
ZooKeeper和Eureka的区别
ZooKeeper保证CAP中CP
Eureka保证CAP中AP
领导者选举机制
分布式架构
分布式系统
分布性
对等性
并发性
缺乏全局时钟
故障总是会发生
分布式环境的各种问题
通信异常
网络分区（脑裂）
三态
成功
失败
超时
由于网络原因，该请求（消息）并没有被成功地发送到接收方，而是在发送过程就发生了消息丢失现象。
该请求（消息）成功的被接收方接收后，并进行了处理，但是在将响应反馈给发送方的过程中，发生了消息丢失现象。
节点故障
ACID
原子性（Atomicity）
一致性（Consistency）
隔离性（Isolation）
未提交读（Read Uncommitted）
提交读（Read Committed）
可重复读（Repeatable Read）
串行化（Serializable）
持久性（Durability）
分布式事务
CAP理论
C-Consistency
P-Partition tolerance
A-Availability
CP
AP
BASE理论
Basically Available（基本可用）
Soft state（软状态）
Eventually consistent（最终一致性）
因果一致性
读己之所写
会话一致性
单调读一致性
单调写一致性
一致性协议
3PC
阶段一：CanCommit
事务询问：协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
各参与者向协调者反馈事务询问的响应：参与者在接收到来自协调者的canCommit请求后，正常情况下，如果其自身认为可以顺利执行事务，那么会反馈Yes响应，并进入预备状态，否则反馈No响应。
阶段二：PreCommit
执行事务预提交（Yes）
发送预提交请求：协调者向所有参与者节点发出preCommit的请求，并进入Prepared阶段。
事务预提交：参与者接收到preCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中。
各参与者向协调者反馈事务询问的响应：如果参与者成功执行了事务操作，那么就会反馈给协调者Ack响应，同时等待最终的指令：提交（commit）或中止（abort）。
中断事务（No）
发送中断请求：协调者向所有参与者节点发出abort请求。
中断事务：无论是收到来自协调者的abort请求，或者是在等待协调者请求过程中出现超时，参与者都会中断事务。
阶段三：doCommit
执行提交
发送提交请求：进入这一阶段，假设协调者处于正常工作状态，并且它接收到了来自所有参与者的Ack响应，那么它将从“预提交”状态转换到“提交”状态，并向所有的参与者发送doCommit请求。
事务提交：参与者接收到doCommit 请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源。
反馈事务提交结果：参与者在完成事务提交之后，向协调者发送Ack消息。
完成事务：协调者接收到所有参与者反馈的Ack消息后，完成事务。
中断事务
发送中断请求：协调者向所有参与者节点发出abort请求。
事务回滚：参与者接收到abort请求后，会利用其在阶段二中记录的Undo信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。
反馈事务回滚结果：参与者在完成事务回滚之后，向协调者发送Ack消息。
中断事务：协调者接收到所有参与者反馈的Ack消息后，中断事务。
注意
在doCommit阶段，如果参与者无法及时接收到来自协调者的doCommit或者rebort请求时，会在等待超时之后，会继续进行事务的提交。（其实这个应该是基于概率来决定的，当进入第三阶段时，说明参与者在第二阶段已经收到了PreCommit请求，那么协调者产生PreCommit请求的前提条件是他在第二阶段开始之前，收到所有参与者的CanCommit响应都是Yes。（一旦参与者收到了PreCommit，意味他知道大家其实都同意修改了）所以，一句话概括就是，当进入第三阶段时，由于网络超时等原因，虽然参与者没有收到commit或者abort响应，但是他有理由相信：成功提交的几率很大。 ）
优点
降低了阻塞的范围。协调者在询问的时候并不锁定资源（阶段一），除非所有人都同意了，才开始锁资源（阶段二）。
解决单点问题。即使协调者挂了，参与者也会在超时之后进行提交。
缺点
一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit，而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作，这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。
Paxos
角色
Proposer
Acceptor
Learner
选定提案
阶段一
Proposer选择一个提案编号Mn，然后向Acceptor的某个超过半数的子集成员发送编号为Mn的Prepare请求。
如果一个Acceptor收到一个编号为Mn的Prepare请求，且编号Mn大于该Acceptor已经响应的所有Prepare请求的编号，那么它就会将它已经批准过的最大编号的提案作为响应反馈给Proposer，同时该Acceptor会承诺不会再批准任何编号小于Mn的提案。
阶段二
如果Proposer收到来自半数以上的Acceptor对于其发出的编号为Mn的Prepare请求的响应，那么它就会发送一个针对[Mn，Vn]提案的Accept请求给Acceptor。注意，Vn的值就是收到的响应中编号最大的提案的值，如果响应中不包含任何提案，那么它就是任意值。
如果Acceptor收到这个针对[Mn，Vn]提案的Accept请求，只要该Acceptor尚未对编号大于Mn的Prepare请求做出响应，它就可以通过这个提案。
PS
获取提案
方案一：每个Acceptor逐个通知所有Learner
方案二：每个Acceptor只通知主Learner，由主Learner通知其他Learner
方案三：每个Acceptor只通知Learner集群，由Learner集群通知其他Learner
存在问题
活锁
解决方案
选择一个主Proposer
总结
ZooKeeper的ZAB协议
工作原理
崩溃恢复
消息广播
Leader服务器首先为事务分配一个全局单调递增的唯一ID，我们称为事务ID（ZXID）。
Leader服务器为每个Follower服务器分配一个单独的队列。
Leader服务器为每个事务请求生成对应的Proposal，并把Proposal依次放入队列中，根据FIFO策略来进行消息广播。
每一个Follower服务器在接收到这个事务Proposal之后，都会首先将其以事务日志的形式写入到本地磁盘中去，并且在成功写入后反馈给Leader服务器一个Ack响应。
Leader服务器接收到超过半数Follower的Ack响应后，就会广播一个Commit消息给所有的Follower服务器以通知其进行事务提交，同时Leader自身也会完成对事务的提交，而每一个Follower服务器在接收到Commit消息后，也会完成对事务的提交。
好处
简化的二阶段提交，只要半数以上Follower服务器反馈Ack就可以开始提交事务，不需要全部反馈。
应用场景
数据发布与订阅
命名服务（全局唯一ID）
UUID的缺陷
长度过长
含义不明
ZooKeeper生成全局唯一ID
所有客户端都会根据自己的任务类型，在指定类型的任务下面通过调用create()接口来创建一个顺序节点，例如创建“job-”节点。
节点创建完毕后，create()接口会返回一个完整的节点名，例如“job-0000000003”。
客户端拿到这个返回值后，拼接上type类型，例如“type2-job-0000000003”，这就可以作为一个全局唯一的ID了。
分布式协调通知
心跳检测
工作进度汇报
系统调度
集群管理
同样是Watcher监听机制
Master选举
分布式锁
定义锁的获取与释放
获取锁：创建临时节点成功
释放锁：1.主动删除临时节点 2.获取锁的机器宕机
排它锁
共享锁
羊群效应
问题：分布式锁脑裂
分布式队列
0 条评论
下一页
