惠州建设网站,上海域名网站,汕尾网站建设公司,营销推广信息Zookeeper介绍
Zookeeper从设计模式角度来理解#xff0c;是一个基于观察者模式设计的分布式服务管理框架#xff0c;它负责存储和管理大家都关心的数据#xff0c;然后接受观察者的注册#xff0c;一旦这些数据的状态发生了变化#xff0c;Zookeeper就负责通知已经在Zoo…Zookeeper介绍
Zookeeper从设计模式角度来理解是一个基于观察者模式设计的分布式服务管理框架它负责存储和管理大家都关心的数据然后接受观察者的注册一旦这些数据的状态发生了变化Zookeeper就负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。
Zookeeper特点
集群中只要有半数以上节点存活Zookeeper集群就能正常提供服务。所以这就是选举机制的奇数原则Zookeeper适合安装奇数台服务。一个领导者Leaders和多个跟随者Follower组成的集群。
Zookeeper的选举机制
新集群选举 假设有五台服务器组成的Zookeeper集群从Service1到Service5同时它们都是最新启动的也就是没有历史数据在存放数据量这一点上都是一样的。假设这些服务器依序启动来看看会发生什么。 Service1启动发起一次选举。服务器1投自己一票。此时服务器1票数一票不够半数以上3票选举无法完成服务器1状态保持为LOOKINGService2启动再发起一次选举。Service1和Service2分别投自己一票并交换选票信息此时Service1发现Service2的ID比自己目前投票推举的Service1大更改选票为推举Service2。此时Service1票数0票Service2票数2票没有半数以上结果选举无法完成Service1Service2状态保持LOOKING。Service3启动发起一次选举。此时Service1和Service2都会更改选票为Service3。此次投票结果Service1为0票Service2为0票Service3为3票。此时Service3的票数已经超过半数Service3当选Leader。Service1与Service2更改状态为FOLLOWINGService3更改状态为LEADING。Service4启动发起一次选举。此时Service1Service2Service3已经不是LOOKING状态不会更改选票信息。交换选票信息结果Service3为3票Service4为1票。此时Service4服从多数更改选票信息为Service3并更改状态为FOLLOWING。Service5启动同理第4步一样Service5当FOLLOWING。 非全新集群选举 对于运行正常的zookeeper集群中途有机器down掉需要重新选举时选举过程就需要加入数据ID、服务器ID、和逻辑时钟。 逻辑时钟这个值从0开始每次选举必须一致。小的选举结果被忽略重新投票除去选举次数不完整的服务器。数据id数据新的version大数据每次更新都会更新version。数据id大的胜出选出数据最新的服务器。服务器id即myid。数据id相同的情况下服务器id大的胜出数据相同的情况下选择服务器id最大即权重最大的服务器。 Kafka依赖Zookeeper的选举 Kafka依赖ZK做了哪些事 ZooKeeper 作为给分布式系统提供协调服务的工具被 kafka 所依赖。在分布式系统中消费者需要知道有哪些生产者是可用的而如果每次消费者都需要和生产者建立连接并测试是否成功连接那效率也太低了显然是不可取的。而通过使用 ZooKeeper 协调服务Kafka 就能将 ProducerConsumerBroker 等结合在一起同时借助 ZooKeeperKafka 就能够将所有组件在无状态的条件下建立起生产者和消费者的订阅关系实现负载均衡。 Kafka选举 Leader维护了一个动态的in-sync replica set (ISR)意为和leader保持同步的follower集合。当ISR中的follower完成数据的同步之后leader就会给follower发送ack。如果follower长时间未向leader同步数据则该follower将被踢出ISR该时间阈值由replica.lag.time.max.ms参数设定。Leader发生故障之后就会从ISR中选举新的leader。 因此这个集合中的任何一个节点随时都可以被选为leader。ISR在ZooKeeper中维护。ISR中有f1个节点followleader就可以允许在f个节点down掉的情况下不会丢失消息并正常提供服。ISR的成员是动态的如果一个节点被淘汰了当它重新达到“同步中”的状态时他可以重新加入ISR。因此如果leader宕了直接从ISR中选择一个follower就行。 如果全挂呢 一旦所有节点都down了Kafka不会保证数据的不丢失。所以当副本都down掉时必须及时作出反应。等待ISR中的任何一个节点恢复并担任leader。 附Kafka为什么要放弃ZK 本身就是一个分布式系统但是需要另一个分布式系统来管理复杂性无疑增加了。部署的时候必须要部署两套系统的运维人员必须要具备的运维能力。Controller故障处理依赖一个单一节点跟进行交互如果这个节点发生了故障就需要从中选择新的新的选举成功后会重新从拉取元数据进行初始化并且需要通知其他所有的更新。老的需要关闭监听、事件处理线程和定时任务。分区数非常多时这个过程非常耗时而且这个过程中集群是不能工作的。 当分区数增加时保存的元数据变多集群压力变大 基于ZooKeeper的Hadoop高可用 HDFS 高可用 介绍 一个典型的HA集群NameNode会被配置在两台独立的机器上在任何时间上一个NameNode处于活动状态而另一个NameNode处于备份状态活动状态的NameNode会响应集群中所有的客户端备份状态的NameNode只是作为一个副本保证在必要的时候提供一个快速的转移。所以对于HDFS来说高可用其实就是针对NameNode的高可用。因为NameNode保存着集群的元数据信息一旦丢失整个集群将不复存在。 主备切换控制器 ZKFailoverControllerZKFC 作为独立的进程运行对 NameNode 的主备切换进行总体控制。ZKFailoverController 能及时检测到 NameNode 的健康状况在主 NameNode 故障时借助 Zookeeper 实现自动的主备选举和切换当然 NameNode 目前也支持不依赖于 Zookeeper 的手动主备切换。 原理 当HDFS的两台NN启动时ZKFCZookeeper FailoverController也会启动ZKFC会向ZK上写一个临时序列化的节点默认节点名是/hadoop-ha并取得和ZK的连接一旦NN挂掉那么ZKFC也会挂掉该节点会被ZK自动删除掉ZKFC有Watcher机制当子节点发生变化时触动另一个伴随着NN启动的ZKFC发现子节点变化了是不是排在第一位是就通知第二台NN开始接管向JN同步数据下载IDS文件并和FImage合并并生成新的FImage将元数据都变成最新的若是挂掉的NN重新启动那么ZKFC还会向ZK写个节点等现接管的NN挂掉后再接管成为Master。 什么是ZKFC ZKFC是一个Zookeeper的客户端它主要用来监测和管理NameNodes的状态每个NameNode机器上都会运行一个ZKFC程序它的职责主要有一是健康监控。ZKFC间歇性的ping NameNode得到NameNode返回状态如果NameNode失效或者不健康那么ZKFS将会标记其为不健康Zookeeper会话管理。当本地NaneNode运行良好时ZKFC将会持有一个Zookeeper session如果本地NameNode为Active它同时也持有一个“排他锁”znode如果session过期那么次lock所对应的znode也将被删除选举。当集群中其中一个NameNode宕机Zookeeper会自动将另一个激活。 内部操作与原理 HealthMonitor 初始化完成之后会启动内部的线程来定时调用对应 NameNode 的 HAServiceProtocol RPC 接口的方法对 NameNode 的健康状态进行检测。HealthMonitor 如果检测到 NameNode 的健康状态发生变化会回调 ZKFailoverController 注册的相应方法进行处理。如果 ZKFailoverController 判断需要进行主备切换会首先使用 ActiveStandbyElector 来进行自动的主备选举。ActiveStandbyElector 与 Zookeeper 进行交互完成自动的主备选举。ActiveStandbyElector 在主备选举完成后会回调 ZKFailoverController 的相应方法来通知当前的 NameNode 成为主 NameNode 或备 NameNode。ZKFailoverController 调用对应 NameNode 的 HAServiceProtocol RPC 接口的方法将 NameNode 转换为 Active 状态或 Standby 状态。 几句话描述就是ZooKeeper提供了简单的机制来实现Acitve Node选举如果当前Active失效Standby将会获取一个特定的排他锁那么获取锁的Node接下来将会成为Active。 Yarn高可用 介绍 YARN ResourceManager 的高可用与 HDFS NameNode 的高可用类似但是 ResourceManager 不像 NameNode 没有那么多的元数据信息需要维护所以它的状态信息可以直接写到 Zookeeper 上并依赖 Zookeeper 来进行主备选举。 内部操作与原理 在ZooKeeper上会有一个/yarn-leader-election/yarn1的锁节点所有的ResourceManager在启动的时候都会去竞争写一个Lock子节点/yarn-leader-election/yarn1/ActiveBreadCrumb该节点是临时节点。ZooKeepr能够保证最终只有一个ResourceManager能够创建成功。创建成功的那个ResourceManager就切换为Active状态没有成功的那些ResourceManager则切换为Standby状态。RM会把job的信息存放在zookeeper的/rmstore目录下active RM会向这个目录写app的信息。当active RM挂掉之后standby RM会通过zkfc切换为active状态然后从zookeeper的/rmstore目录下读取相应的作业信息。重新构建作业的内存信息启动内部服务开始接受NM的心跳信息构建集群的资源信息并且接受客户端的作业提交请求。 其他与总结 在大数据领域还有许多框架依赖于Zookeeper去选择主从比如Hbase集群Kudu集群Impala集群等等最底层的原理大径相同。总结 选举Zookeeper能够很容易地实现集群管理的功能若有多台Server组成一个服务集群则必须要一个leader知道集群中每台机器的服务状态从而做出调整重新分配服务策略。当集群中增加一台或多台Server时leader同样需要知道。Zookeeper不仅能够维护当前的集群中机器的服务状态而且能够选出一个leader来管理集群。 HA(分布式锁的应用)Master挂掉之后迅速切换到slave节点。
