在淘宝介绍里边怎么做网站链接,网站的推广平台有哪些,济南做网站那家好,固定ip做网站和域名区别目录
01ZooKeeper的ZAB协议
ZAB协议概念
ZAB协议基本模式
消息广播
崩溃恢复
选举出新的Leader服务器
数据同步
02Zookeeper的核心
ZooKeeper 的核心特点
ZooKeeper 的核心组件
选举算法概述
服务器启动时的Leader选举
服务器运行期间的Leader选举
03ZooKeeper的…
目录
01ZooKeeper的ZAB协议
ZAB协议概念
ZAB协议基本模式
消息广播
崩溃恢复
选举出新的Leader服务器
数据同步
02Zookeeper的核心
ZooKeeper 的核心特点
ZooKeeper 的核心组件
选举算法概述
服务器启动时的Leader选举
服务器运行期间的Leader选举
03ZooKeeper的简单使用
04ZooKeeper的应用场景 01ZooKeeper的ZAB协议
在解决一致性方面Zookeeper并没有直接采用Paxos算法而是采用了一种被称为ZAB(ZooKeeper Atomic Broadcast)的一致性协议。
ZAB协议概念
ZAB协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议。基于该协议Zookeeper实现了一种主备模式的系统架构来维持集群中各副本之间数据的一致性。
ZAB协议的核心是定义了事务请求的处理方式
所有事务请求必须由一个全局唯一的服务器来协调处理这样的服务器被称为Leader服务器而余下的其他服务器则成为Follower服务器。Leader服务器负责将一个客户端事务请求转换为一个事务Proposal提议并将该Proposal分发给集群中的所有Follower服务器。之后Leader服务器需要等待所有Follower服务器的反馈一旦超过半数的Follower服务器进行了正确的反馈后那么Leader就会再次向所有的Follower服务器发布Commit信息要求将前一个Proposal进行提交。
ZAB协议基本模式
ZAB 协议包括两种基本模式消息广播和崩溃恢复。 消息广播这是 ZAB 协议的基本模式之一用于确保 ZooKeeper 集群中的所有节点都接收到相同的消息。在这种模式下ZooKeeper 集群中的 leader 节点负责将客户端请求转化为一系列的消息然后将这些消息广播给所有的 follower 节点。每个 follower 节点接收到消息后会将消息写入本地的事务日志。一旦超过半数的节点确认接收了消息leader 就可以提交这些消息并将其应用到自己的状态机上从而达到状态一致性。这确保了 ZooKeeper 的一致性和可靠性。 崩溃恢复是 ZAB 协议的另一种基本模式用于选择 ZooKeeper 集群中的 leader 节点。在一个 ZooKeeper 集群中只有一个节点充当 leader负责处理客户端请求并维护共享状态。如果当前的 leader 节点出现故障集群需要选举一个新的 leader。ZAB 协议中的选举是基于消息广播的节点会争相发送选举消息然后根据规则选择新的 leader。选举过程确保了只有一个节点成为 leader从而维持了一致性。
消息广播
ZAB的消息广播类似于二阶段提交。不同之处是ZAB协议移除了中断逻辑——Follower服务器要么Ack给Leader要么抛弃Leader。当过半的Follower服务器反馈Ack之后就开始提交事务Proposal,而不需要等待集群中所有的Follower服务器都反馈响应。 消息广播是基于具有FIFO特性的TCP协议通信的所以能很容易地保证消息广播过程中消息接收与发送的顺序性。 整个消息广播过程中leader服务器会为每一个事务请求生成一个Proposal来进行广播并且在广播事务Proposal之前Leader服务器会为这个事务分配一个全局单调递增的唯一ID,称之为事务ID(即ZXID)。而且每一个事务Proposal严格按照其ZXID的先后顺序进行排序和处理。 消息广播过程中Leader服务器会为每一个Follower服务器各自分配一个单独的队列将需要广播的事务Proposal一次放入队列中根据FIFO的策略发送。每一个Follower服务器在接收到这个事务Proposal之后都会首先将其以事务日志的形式写入本地磁盘在成功写入后反馈给Leader服务器一个Ack响应。服务器收到过半的Follower的Ack响应后就会广播一个Commit消息给所有的服务器以通知其进行事务提交同时Leader完成自身的事务提交每一个Follower服务器收到Commit消息后完成自身事务的提交。
需要注意的是Leader服务器可以处理事务请求(包括创建、更新和删除节点等需要保证强一致性的操作)和非事务请求Follower服务器只能处理非事务请求如果Follower收到事务请求会转交给Leader服务器。
崩溃恢复
简化的二阶段提交模型是无法处理Leader崩溃带来的数据不一致问题。一旦Leader服务器出现崩溃或者由于网络导致Leader服务器失去了过半Follower的联系就会进入崩溃恢复模式。
崩溃恢复状态下ZAB协议有两件事要做 选举出新的Leader服务器 数据同步
选举出新的Leader服务器
整个崩溃过程结束后需要选举出新的Leader服务器而且还得让其他服务器感知到选举产生的新Leader服务器。
在ZAB协议中崩溃恢复模式可能出现的两个数据不一致的隐患场景 服务器Leader在确认半数通过后完成了进行自身事务的提交但是发送Commit告知Follower进行事务提交的瞬间异常这是第一个需要保证的特性确保在Leader服务器提交过的事务最终被所有服务器都提交。 ZAB协议规定如果一个Proposal事务在一台机器上被处理成功那么应该在所有的机器上都被处理成功哪怕机器出现故障崩溃。(所以在过半确认过程中数据会被强制一致的)基于这个特性如果Leader节点在提出了某个Proposal事务之后就崩了没有告知到Follower进行本地提交等崩溃恢复了原本的Leader保留了提出这个Proposal的状态此时应该直接丢弃而不是强制同步。这是第二个需要保证的特性确保丢弃那些只在Leader服务器上被提出的事务。
结合这两种情况ZAB协议设计的选举算法就必须要满足能够确保提交已经被Leader提交的事务Proposal同时丢弃已经被跳过的事务Proposal。
ZAB协议的Leader选举方案就是拥有最大ZXID的Follower服务器作为新的Leader服务器。为什么呢 在消息广播的过程中Leader服务器进行自身事务的提交前提是收到了半数的Follower服务器的Ack响应那么此时必然有Follower服务器的事务日志中保存了所有的proposal状态包含Leader异常时提交的那份。 Follower自身ZXID是64位高32位是epoch编号低32位是消息计数器每接收到1条消息1新Leader选举后epoch会1消息计数器置为0。设计的好处在于旧的Leader作为Follower接入时它的ZXID是肯定小于新Leader的而且新Leader会让它将所有的拥有旧的epoch号的未被Commit的proposal清除。
至此就保证了崩溃恢复后数据的一致性。
数据同步
在选出新的Leader服务器后需要开始数据同步。Leader服务器会为每一个Follower服务器准备一个队列将那些没有被同步的事务以Proposal消息的形式逐个发给Follower服务器在Follower服务器将所有未同步的proposal事务从Leader服务器上同步并成功应用到本地数据库中后Leader服务器会将该Follower服务器加入真正可用的Follower列表中然后开始之后的正常流程。
02Zookeeper的核心
ZooKeeper是一个开源的分布式协调服务用于构建分布式应用和分布式系统。它提供了一个高度可靠的分布式协调基础设施帮助应用程序在分布式环境中协同工作。ZooKeeper 通常用于解决分布式系统中的一致性、配置管理、锁服务、命名服务等问题。
ZooKeeper 的核心特点 分布式文件系统ZooKeeper 维护一个分层的命名空间类似于文件系统目录结构它可以用于存储配置信息和分布式数据。 一致性ZooKeeper 提供了强一致性的数据模型即一旦数据被写入所有客户端都能读取到最新的数据从而确保数据的一致性。 高可用性ZooKeeper 以多数节点的方式运行即在集群中的节点数必须超过半数以确保高可用性。如果一些节点失效ZooKeeper 仍然能够提供服务。 快速通知ZooKeeper 允许客户端监听节点数据的变化一旦节点数据发生变化相关的客户端将得到通知。 顺序一致性ZooKeeper 允许客户端按照顺序创建节点并提供了有序性保证这在分布式锁服务中非常有用。
ZooKeeper 的核心组件 集群ZooKeeper 集群由多个节点组成这些节点分布在不同的机器上它们协同工作以提供服务。典型的 ZooKeeper 集群包括奇数个节点通常是 3、5 或 7 个节点以确保多数节点可用。 ZNodeZNode 是 ZooKeeper 命名空间的基本单元类似于文件系统中的目录或文件。每个 ZNode 可以包含数据并具有一个路径名称。 会话ZooKeeper 客户端与 ZooKeeper 服务器之间建立会话会话是客户端与服务器之间的状态会话用于保持连接和跟踪会话的生命周期。 Watch客户端可以在 ZNode 上设置 Watch以便在 ZNode 数据发生变化时获得通知。 选举算法ZooKeeper 使用选举算法来选举 leader 节点leader 负责协调事务和保持一致性。
选举算法概述
分两种情况拆解下选举算法服务器启动时的Leader选举和服务器运行期间的Leader选举。
服务器启动时的Leader选举
假设在集群中有3台服务器已经可以互相通信它们需要选出一个Leader服务器。有一个前提条件它们拥有一个myid的属性server1的myid是1server2的myid是2server3的myid是3。
1.每个server会发出一个投票
例如server1以(myidzxid)格式发送给其他服务器投票的数据(1,0)server2发送的(2,0)。
2.接收来自每个服务器的投票
每个服务器都会收到其他服务器的投票首先验证有效性其次是否本轮投票、是否来自Looking状态的服务器。
3.处理投票
每个服务器根据规则处理收到的投票规则如下 优先zxid。zxid大的优先作为Leader。 zxid相同myid大的作为Leader。
那么3台服务器的zxid都为0就会比较myid。server1和server2根据规则会修改自身投票为(3,0)。然后重新向其他服务器发送投票。server3不用修改只是再发送一次。
4.统计投票
每次投票服务器都会统计所有投票判断是否产生了Leader这里还是使用的过半概念当有一半的服务器收到相同的投票时候就认为已经选出了Leader。
5.改变服务器状态
一旦确定了Leader服务器就会变更自己的状态Follower会变更为FOLLOWINGLeader会变更为LEADING。
服务器运行期间的Leader选举
当Leader服务器挂掉的时候就会进行新一轮的Leader选举。
1.变更状态
非Observer服务器会将自己的服务器状态变更为LOOKING开始选举流程。(Observer服务器不参与选举也不投票)
2.每个server发出一个投票
与启动期间不同的是运行期间的服务器可能有不同的zxid。例如server的投票(1,1112)server3的投票(3,1113)。
3.接收各个服务器的投票
4.处理投票显然server3的zxid大server3会成为Leader。
5.统计投票
6.改变服务器状态 03ZooKeeper的简单使用
可以参考这篇博客http://t.csdnimg.cn/N6yyU
04ZooKeeper的应用场景
Apache ZooKeeper 在分布式系统中有多种典型应用场景它提供了高度可靠的分布式协调服务用于解决各种分布式系统的共识、配置管理和协同协作问题。以下是 ZooKeeper 的一些典型应用场景 分布式配置管理ZooKeeper 可用于存储和管理应用程序的配置信息。各个分布式节点可以监听配置节点当配置发生变化时节点能够及时获取最新的配置实现动态配置管理。 分布式锁服务ZooKeeper 提供了分布式锁服务允许多个节点协同竞争获取锁。这对于协调分布式系统中的操作非常有用确保只有一个节点能够执行关键操作。 分布式一致性ZooKeeper 可以用于协调多个节点以达成一致的决策。它确保在分布式系统中节点的状态和数据是一致的从而提供强一致性的数据存储。 服务发现ZooKeeper 可用于注册和发现分布式系统中的服务。各个服务可以在 ZooKeeper 上注册自己的地址和状态其他节点可以查询这些信息以发现可用的服务。 领导者选举ZooKeeper 通常用于选举分布式系统中的领导者节点。它确保只有一个节点成为领导者从而协调系统的操作。 分布式任务队列ZooKeeper 可用于创建分布式任务队列多个节点可以将任务推送到队列中然后从队列中获取任务进行处理。 分布式协同协作ZooKeeper 提供了分布式协调服务可以用于构建分布式应用程序确保多个节点协同协作并实现一致性。 分布式文件系统虽然 ZooKeeper 不是一个文件系统但它可以用于管理分布式系统中的文件和配置信息作为分布式文件系统的一部分。
参考资料从Paxos到Zookeeper 分布式一致性原理与实践 [倪超著]
