网站开发文档源码,wordpress用户名怎么起,网站建设方法牜金手指下拉覀,建设应用型网站的意义目录 1.1、概述1.2、选举机制1.2.1、选举触发条件1.2.2、选举规则1.2.3、选举过程详解 1.3、数据同步机制1.3.1、正常同步1.3.2、宕机同步 1.4、客户端常用命令1.5、应用场景1.5.1、配置管理1.5.2、命令服务1.5.3、分布式锁服务1.5.4、集群管理1.5.5、分布式ID1.5.6、分布式协调… 目录 1.1、概述1.2、选举机制1.2.1、选举触发条件1.2.2、选举规则1.2.3、选举过程详解 1.3、数据同步机制1.3.1、正常同步1.3.2、宕机同步 1.4、客户端常用命令1.5、应用场景1.5.1、配置管理1.5.2、命令服务1.5.3、分布式锁服务1.5.4、集群管理1.5.5、分布式ID1.5.6、分布式协调/通知1.5.7、心跳检测 1.1、概述 本文主要讲述ZooKeeper工作机制与应用场景关于ZooKeeper的核心概念、主要特征等内容请参考构建分布式系统的一致性基石之ZooKeeper简介这篇博文。
1.2、选举机制 ZooKeeper的选举机制基于ZAB协议ZooKeeper Atomic Broadcast这是一种为分布式系统设计的原子广播协议。其核心目标是快速选举出Leader节点并确保数据一致性。
1.2.1、选举触发条件
集群初始化时 所有节点启动时均为LOOKING状态触发首次选举。运行期间Leader故障时 Leader节点宕机或网络中断时剩余节点重新选举。
1.2.2、选举规则
ZXID事务ID优先 ZXID是64位整数由epoch任期和counter事务计数器组成数值越大表示数据越新优先级更高。SID服务器ID次之 若ZXID相同则SID配置文件中的myid较大的节点胜出。过半原则 候选节点需获得超过半数投票即N/2 1才能成为Leader。
1.2.3、选举过程详解 假设有五台服务器组成的Zookeeper集群它们的id从1-5在集群初次启动时是没有历史数据数据操作的事务ID也不存在其选举流程如下
服务器1 服务器1启动发起投票投票格式为(ZxidServerID),投出的票为(0,1)此时服务器1票数一票不够半数以上3票选举无法完成服务器1状态保持为LOOKING。服务器2 服务器2启动发起投票投出的票为(02)服务器1和2分别投自己一票并交换选票信息此时服务器1发现服务器2的ServerID比自己目前投票推举的服务器1大更改选票为推举服务器2。此时服务器1票数0票服务器2票数2票没有半数以上结果选举无法完成服务器12状态保持LOOKING。服务器3 服务器3启动发起投票投出的票为(03)此时服务器1和服务器2发现服务器3的ServerID比自己目前投票推举的服务器2大更改选票为推举服务器3。此次投票结果服务器1为0票服务器2为0票服务器3为3票。此时服务器3的票数已经超过半数服务器3当选Leader。服务器12更改状态为FOLLOWING服务器3更改状态为LEADING。服务器4 服务器4启动发起投票。此时服务器123已经不是LOOKING状态不会更改选票信息。交换选票信息结果服务器3为3票服务器4为1票。此时服务器4服从多数更改选票信息为服务器3并更改状态为FOLLOWING。服务器5 服务器5启动同服务器4启动过程类似。 Zookeeper集群的中每个服务器的数据都是一致的除非网络波动极大才会导致Zxid不一致故而每个服务器的Zxid一致。如果真的遇到Zxid不一致那么最大的Zxid的服务器会自动当选leader如果相当则按照上述规则进行选举。 运行期间的Leader故障时所有FOLLOWING节点切换为LOOKING状态。此时触发重新选举Leader的过程假设服务器3宕机时服务器1的Zxid为100服务器2的Zxid为101服务器4的Zxid为104服务器5的Zxid为105其选举流程如下
所有服务器给自己投票 此时服务器1、服务器2、服务器4、服务器5都为1票服务器1、服务器2、服务器4、服务器5的状态都为LOOKING。投票比较 服务器1发现服务器5的Zxid最大更改选票为推举服务器5。服务器2发现服务器5的Zxid最大更改选票为推举服务器5。服务器4发现服务器5的Zxid最大更改选票为推举服务器5。投票确认 服务器1为0票服务器2为0票服务器4为0票服务器5为4票。此时服务器4的票数已经超过半数服务器4当选Leader。服务器12、4更改状态为FOLLOWING服务器5更改状态为LEADING。
1.3、数据同步机制 zookeeper 的数据同步是为了保证各节点中数据的一至性同步时涉及两个流程:
一个是正常的客户端数据提交一个是集群某个节点宕机在恢复后的数据同步
1.3.1、正常同步 当leader 接收客户端写请求并同步给各个子节点的流程如下 但实际情况要复杂的多比如client 它并不知道哪个节点是leader 有可能写的请求会发给follower 由follower在转发给leader进行同步处理如下 client向zk中的server发送写请求到达followerfollower则会将该写请求转发给leaderleader将请求事务以proposal形式分发给follower 当follower收到收到leader的proposal时根据接收的先后顺序处理proposal 当Leader收到follower针对某个proposal过半的ack后则发起事务提交重新发起一个commit的proposal follower收到commit的proposal后记录事务提交并把数据更新到内存数据库 当写成功后反馈给client。
1.3.2、宕机同步 在集群运行过程当中如果有一个follower节点宕机由于宕机节点没过半集群仍然能正常服务。当leader 收到新的客户端请求此时无法同步给宕机的节点。造成数据不一至。为了解决这个问题当节点启动时第一件事情就是找当前的Leader比对数据是否一至。不一至则开始同步,同步完成之后在进行对外提供服务。 如何比对Leader的数据版本呢这里通过ZXID事务ID来确认。 ZXID是一个长度64位的数字其中低32位是按照数字递增任何数据的变更都会导致,低32位的数字简单加1。高32位是leader周期编号每当选举出一个新的leader时新的leader就从本地事物日志中取出ZXID,然后解析出高32位的周期编号进行加1再将低32位的全部设置为0。这样就保证了每次新选举的leader后保证了ZXID的唯一性而且是保证递增的。 1.4、客户端常用命令
启动客户端 zkCli.sh查看帮助 help查看当前znode所包含的内容 ls /创建节点 create /hello 18创建短暂znode create -e /haha tom创建带序号znode create -s /bigdata tom创建短暂带序号 create -e -s /bigdata tom查看此节点的详细信息 ls2 /获得节点值监听 get /hello watch监听路径 ls / watch修改znode数据 set /hello iiiii删除节点 delete /hello递归删除 rmr /delireba查看节点状态信息 stat /
1.5、应用场景 ZooKeeper 是一个高可用的分布式数据管理与协调框架。基于对 ZAB 算法的实现 该框架能够很好地保证分布式环境中数据的一致性。也是基于这样的特性使得ZooKeeper 成为了解决分布式一致性问题的利器其具有以下几种典型的应用场景。
1.5.1、配置管理 zookeeper 提供了节点watch的功能zookeeper 的 client对外提供服务的 server监控 zookeeper 上的节点znode当节点变动的时候client 会收到变动事件和变动后的内容基于 zookeeper 的这个特性我们可以给服务器集群中的所有机器 client都注册 watch 事件监控特定 znode节点中存储部署代码的配置信息 需要更新代码的时候修改 znode 中的值服务器集群中的每一台 server 都会收到代码更新事件然后触发调用更新目标代码。 现在有很多开源项目使用 Zookeeper 来维护配置比如在 HBase 中客户端就是连接一个 Zookeeper获得必要的 HBase 集群的配置信息然后才可以进一步操作。 还有在开源的消息队列 Kafka 中也使用 Zookeeper 来维护 broker 的信息。其原理如下
1.5.2、命令服务 命名服务也是分布式系统中比较常见的一类场景。在分布式系统中通过使用命名服务客户端应用能够根据指定名字来获取资源或服务的地址提供者等信息。 注册一个持久节点/service/business/what他下面的每个子节点都是一个可用服务 保 存 了 服 务 的 地 址 端 口 等 信 息 服 务 调 用 者 通 过 zookeeper 获 取 /service/business/what 所有子节点信息来得到可用的服务。 下面的节点都是临时节点服务器启动的时候会过来注册一个临时节点服务器挂掉之后或主动关闭之后临时节点会自动移除这样就可以保证使用者获取的 what 服务都是可用的而且可以动态的扩容缩容。
1.5.3、分布式锁服务 一个集群是一个分布式系统由多台服务器组成。为了提高并发度和可靠性多台服务器上运行着同一种服务。当多个服务在运行时就需要协调各服务的进度有时候需要保证当某个服务在进行某个操作时其他的服务都不能进行该操作即对该操作进行加锁如果当前机器挂掉后释放锁并fail over 到其他的机器继续执行该服务。
1.5.4、集群管理 一个集群有时会因为各种软硬件故障或者网络故障出现某些服务器挂掉而被移除集群而某些服务器加入到集群中的情况zookeeper会将这些服务器加入/移出的情况通知给集群中的其他正常工作的服务器以及时调整存储和计算等任务的分配和执行等。此外zookeeper还会对故障的服务器做出诊断并尝试修复。
1.5.5、分布式ID 在过去的单库单表型系统中通常可以使用数据库字段自带的auto_increment属性来自动为每条记录生成一个唯一的ID。但是分库分表后就无法在依靠数据库的auto_increment属性来唯一标识一条记录了。此时我们就可以用zookeeper在分布式环境下生成全局唯一ID。做法如下每次要生成一个新id时创建一个持久顺序节点创建操作返回的节点序号即为新id然后把比自己节点小的删除即可。
1.5.6、分布式协调/通知 ZooKeeper 中特有 Watcher 注册与异步通知机制能够很好的实现分布式环境下不同机器甚至不同系统之间的通知与协调从而实现对数据变更的实时处理。使用方法通常是不同的客户端都对 ZooKeeper 上同一个 ZNode 进行注册监听ZNode 的变化包括 ZNode 本身内容及子节点的如果 ZNode 发生了变化那么所有订阅的客户端都能够接收到相应的 Watcher 通知并做出相应的处理。 ZooKeeper 的分布式协调/通知是一种通用的分布式系统机器间的通信方式。
1.5.7、心跳检测 机器间的心跳检测机制是指在分布式环境中不同机器或进程之间需要检测到彼此是否在正常运行例如 A 机器需要知道 B 机器是否正常运行。在传统的开 发中我们通常是通过主机直接是否可以相互 PING 通来判断更复杂一点的话 则会通过在机器之间建立长连接通过 TCP 连接固有的心跳检测机制来实现上层 机器的心跳检测这些都是非常常见的心跳检测方法。 基于 ZooKeeper 的临时节点的特性可以让不同的进程都在 ZooKeeper 的一个指定节点下创建临时子节点不同的进程直接可以根据这个临时子节点来判断对应 的进程是否存活。通过这种方式检测和被检测系统直接并不需要直接相关联而是通过 ZooKeeper 上的某个节点进行关联大大减少了系统耦合。
