ZooKeeper学习

亦凉 2023-06-02 09:20 20阅读 0赞

# 二阶段提交协议(Two-Phase Commit) #

*  背景  
    在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败
 *  假设
    
     *  分布式系统中，存在一个节点作为协调者(Coordinator)，其他节点作为参与者(Participants)，且节点之间可以进行网络通信
     *  所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上，即使节点损坏不会导致日志数据的消失
     *  所有节点不会永久性损坏，即使损坏后仍然可以恢复
 *  概括
    
     *  参与者 将操作成败通知 协调者，再由 协调者 根据 所有参与者 的反馈情报决定 各参与者 是否要 提交操作 还是 中止操作
 *  阶段一(投票阶段)
    
     *  事务(是否可以提交事务)询问
        
         *  协调者 向所有的 参与者 发送事务内容，询问是否可以执行 事务提交 操作，并开始等待各 参与者 的响应
     *  执行事务
        
         *  各 参与者节点 执行事务操作，并将Undo和Redo信息记入事务日志中
     *  各 参与者 向 协调者 反馈事务询问的响应
        
         *  如果参与者成功执行了事务操作，则反馈YES响应，否则返回NO响应
 *  阶段二(完成阶段)
    
     *  协调者 从所有 参与者 获得的反馈都是YES响应
        
         *  发送提交请求
            
             *  协调者 向所有 参与者节点 发出COMMIT请求
         *  事务提交
            
             *  参与者接收到COMMIT请求后，会正式执行事务提交操作，并在完成提交之后 释放 在整个事务执行期间占用的事务资源
         *  反馈事务提交结果
            
             *  参与者 在完成事务提交之后，向 协调者 发送ACK消息
         *  完成事务
            
             *  协调者 接收到所有 参与者 反馈的ACK消息后，完成事务
     *  任何一个 参与者 向 协调者 反馈了NO响应
        
         *  发送回滚请求
            
             *  协调者 向所有 参与者节点 发送 ROLLBACK 请求
         *  事务回滚
            
             *  参与者 接收到ROLLBACK请求后，会利用其在阶段一中记录的UNDO信息来执行事务回滚操作，并在完成回滚之后 释放 在整个事务执行期间占用的资源
         *  反馈事务回滚结果
            
             *  参与者 在完成事务回滚之后，向 协调者 发送ACK消息
         *  中断事务
            
             *  协调者 接收到 所有参与者 反馈的ACK消息后，完成事务中断
 *  缺点
    
     *  同步阻塞
        
         *  所有(参与者)参与该事务操作的逻辑都处于阻塞状态
         *  其它访问该事务操作锁定的资源的操作也会被阻塞
     *  单点问题
        
         *  协调者出现问题则整个二阶段提交流程将无法运行
         *  如果协调者在阶段二中出现问题，则其他参与者将会一直处于锁定事务资源的状态，而无法继续完成事务操作
     *  数据不一致
        
         *  可能只有部分参与者收到了COMMIT请求，并执行了提交；其他结点没有收到COMMIT请求从而无法提交
     *  太过保守
        
         *  当参与者出现故障，导致协调者始终无法获取所有参与者的响应信息时，协调者只能依靠自身的超时机制判断是否需要中断事务

# ZAB协议(ZooKeeper Atomic Broadcast) #

*  作用
    
     *  保证分布式事务的最终一致性
 *  要解决的问题
    
     *  正确、高效地处理客户端大量的并发请求
     *  分布式环境中，要保证一个全局的变更序列被顺序应用
     *  容错处理(这一点是基于解决第1点问题使用的 主备模式 而提出)
 *  核心概念
    
     *  协议定义
        
         *  并不像Paxos算法那样的通用的分布式一致性算法
         *  是一种特别为ZooKeeper设计的崩溃可恢复的原子消息广播算法
     *  Leader服务器
        
         *  所有事务请求必须由一个全局唯一的服务器来协调处理
     *  Follower服务器
        
         *  余下的其他服务器
     *  基本流程
        
         *  Leader负责将一个客户端事务请求转换成一个事务Proposal(提议)，并将该Proposal分发给集群中所有Follower
         *  Leader等待超过半数的Follower进行正确反馈
         *  Leader向所有Follower分发Commit消息，要求将前一个Proposal进行提交
     *  举例
        
         *  Zookeeper 客户端会随机的链接到 zookeeper 集群中的一个节点
         *  如果是读请求，就直接从当前节点中读取数据
         *  如果是写请求，那么节点就会向 Leader 提交事务，Leader 接收到事务提交，会广播该事务，只要超过半数节点写入成功，该事务就会被提交
 *  基本模式
    
     *  崩溃恢复
        
         *  Leader选举
            
             *  选举出一个Leader，同时Leader会维护一个Follower列表，客户端可以和这些 Follower进行通信
             *  协议并没有规定选举算法
             *  实现中使用的如：Fast Leader Election
         *  数据同步
            
             *  Leader要负责将本身的数据与Follower完成同步，做到多副本存储。这样也是提现了CAP中的高可用和分区容错
             *  Follower将队列中未处理完的请求消费完成后，写入本地事务日志中
     *  消息广播
        
         *  Leader可以接受客户端新的事务Proposal，将新的Proposal广播给所有的Follower
 *  关键概念及理解
    
     *  ZAB协议的主备模型(具体的说就是核心概念中的介绍)
        
         *  能够很好地处理客户端大量的并发请求
     *  消息广播是基于具有FIFO特性的TCP协议来进行网络通信的
        
         *  能够很容易的保证消息处理过程中消息收、发的顺序性
     *  换一种说法：Leader与每一个Follower之间都维护了一个单独的FIFO消息队列进行收发消息
        
         *  消息队列可以做到异步解耦：Leader和Follower之间只需要往队列中发消息即可
     *  ZAB协议中Leader等待Follower的ACK反馈消息：只要半数以上的Follower成功反馈即可，不需要收到全部Follower反馈
        
         *  相比二阶段提交协议，做了简化，提高了性能
 *  崩溃恢复需要保证的两点原则
    
     *  ZAB协议需要确保那些已经在Leader上提交的事务Propocal，最终被所有服务器都提交
     *  ZAB协议需要确保在丢弃只在Leader上提出的事务Proposal (而没有被提交)
     *  概括起来说就是：已经被Commit的数据不会丢失，未被Commit的数据要对客户端不可见
 *  崩溃恢复的场景  
    \- 集群启动  
    \- 新节点加入  
    \- Leader重启、宕机  
    \- Follower重启、宕机
 *  FLE选举
    
     *  关键点
        
         *  初始投票给自己
            
             *  广播时会将自己的选票存入投票箱
         *  更新选票
            
             *  每个节点接收到其他节点的投票时，发生PK时，会根据PK结果更新自己的选票
             *  广播自己的最新选票(同时将自己的投票存入投票箱) 这里有个问题，何时要发送广播？？？？？？
             *  将接收到的选票存入投票箱(覆盖方式)
         *  更新选票优化版
            
             *  每个节点接收到其他节点的投票时，发生PK时，会根据PK结果更新自己的选票
             *  清空投票箱
             *  广播自己的最新选票(同时将自己的投票存入投票箱) 这里有个问题，何时要发送广播？？？？？？
             *  将接收到的有效选票(与自己最新投票结果一致的选票)存入投票箱
         *  每个节点的投票箱，保存自己和其他节点最新的投票，并且这些投票处于同一轮次，投票箱中的票是用来判断是否已有过半服务器认可了自己的最新投票
 *  不同场景下的数据同步相关逻辑
    
     *  待补充。。。。。。
     *  保证已经被Commit的数据不会丢失
        
         *  Follower将自己最大zxid发送给Leader，之后leader将 Follower的zxid 到 自身zxid 之间 的所有被Commit过的Proposal同步给Follower
     *  保证未被Commit的数据要对客户端不可见
        
         *  判断是否需要提交未Commit的Proposal，这属于第一点原则
            
             *  Leader被选出来后，先判断自身未Commit的Proposal是否在大多数节点中存在(判断是否大多数节点已经成功执行了事务Proposal)，从而决定是否要将其Commit
         *  第二点原则 ??? 有问题
            
             *  Leader此时知道自己Commit过的zxid区间： \[commit\_min\_xzid, commit\_max\_zxid\]
             *  Follower将自身 Commit过的最大commit\_zxid 以及 未被Commit过的所有zxid (记为zxid\_set)发送给Leader
             *  Leader通知Follower将其zxid\_set中大于Follower的commit\_max\_zxid(如果有)的所有Proposal全部删除
 *  使用场景
    
     *  服务发现
     *  分布式锁
     *  分布式leader选举
     *  等补充
 *  待补充
    
     *  Fast Paxos算法
 *  问题记录
    
     *  FLE选举，最初Fowller如何确定，需要将自己的选票发送给哪些其他节点？
     *  从广播的角度理解，广播自己的选票，会不会带来广播风暴？

# ZooKeeper client API (原生API) #

*  创建会话
    
     *  会话的建立是异步的过程
     *  当会话真正创建完毕后，ZK server会向会话对应的ZK client发送一个事件通知，因此ZK client只有在获取这个通知后，才算真正建立了会话
     *  判断已建立会话的方法( c api )
        
         *  通过zoo\_state(zh)判断状态值是否为ZOO\_CONNECTED\_STATE
         *  当client与server会话建立后，触发默认watcher， 接收到type为-1(ZOO\_SESSION\_EVENT)，state为3(ZOO\_CONNECTED\_STATE)
         *  业务上做判断：即调用zoo\_exists()或zoo\_get\_data()能够返回正确的数据
 *  watcher && callback
    
     *  watcher
        
         *  事件通知处理器，即ZK client可以接收来自ZK server的事件通知并做一些处理(同步处理、异步处理)
         *  不管client/server，注册事件的watcher通知是一次性的，一旦被触发后，该注册就失效了，因此ZK client需要反复注册该事件的watcher通知
         *  ZK server发送的仅是一个通知，并不包括节点的变化情况，因此ZK client需要自己重新获取有什么变化
         *  client watcher触发(调用callback)是一个串行同步的过程
            
             *  保证了顺序
             *  不能因为一个watcher的处理逻辑影响了整个客户端的watcher回调
         *  default watcher callback( c api )
            
             *  zookeeper\_init函数注册default watcher并设置default callback
         *  custom watcher callback( c api )
            
             *  zoo\_get、zoo\_get\_children、zoo\_exists等函数注册相应watcher并设置其callback
     *  callback
        
         *  异步回调函数，以下api有同步、异步两个版本，调用异步api需要传入一个回调函数
 *  创建节点
    
     *  临时结点
        
         *  如果客户端会话失效，那么这个节点就会被自动清理掉
         *  临时结点只能做为叶子结点
 *  删除节点
 *  读取数据
    
     *  获取子节点列表
     *  获取节点数据
 *  更新数据
 *  检测节点是否存在
 *  权限控制

# ZooKeeper client API (高级API) #

*  Session超时重连
 *  Watcher反复注册

# cpp zookeeper client项目 #

[https://github.com/chenguang9239/CppZooKeeperApi.git][https_github.com_chenguang9239_CppZooKeeperApi.git]

# 参考 #

《从Paxos到Zookeeper-分布式一致性原理与实践》  
[https://www.jianshu.com/p/2bceacd60b8a][https_www.jianshu.com_p_2bceacd60b8a]  
[FastLeaderElection选主算法流程详解][FastLeaderElection]  
[Zookeeper架构及FastLeaderElection机制][Zookeeper_FastLeaderElection]  
[Zookeeper开发常见问题][Zookeeper]  
[zookeeper（四）核心watch和watcher][zookeeper_watch_watcher]

转载于:https://www.cnblogs.com/wangzhiyi/p/11298686.html

[https_github.com_chenguang9239_CppZooKeeperApi.git]: https://github.com/chenguang9239/CppZooKeeperApi.git
[https_www.jianshu.com_p_2bceacd60b8a]: https://www.jianshu.com/p/2bceacd60b8a
[FastLeaderElection]: https://blog.csdn.net/gangsijay888/article/details/82383599
[Zookeeper_FastLeaderElection]: http://www.jasongj.com/zookeeper/fastleaderelection/
[Zookeeper]: http://www.iyeele.com/343.html
[zookeeper_watch_watcher]: https://www.cnblogs.com/yucongblog/p/7764234.html