zookeeper原理

问题导读: 1.zookeeper观察者什么时候调用？ 2.传统远程轮询服务存在什么问题？ 3.zk中回调服务的机制是什么？ 4.zk中watcher为什么不永久注册？ 5.什么是znode？ 在阅读之前首先明确个概念： 1.什么是znode？ 2.什么是客户端？ 我们使用 znode 这个术语来表示 ZooKeeper的数据节点 。 znode维持一个stat结构，它包含数据变化的 版本号 、ACL变化和时间戳，以允许cache 校验 和协调化的更新。每当znode的数据变化时，版本号将增加。一个客户端收到数据时，它也会收到数据的版本号。 保存在每个znode中的数据都是自动读写的。读操作获取znode的所有数据，写操作替换掉znode的所有数据。每个节点有一个访问控制表（ACL）来限制谁能做哪些操作。 Zookeeper中的角色主要有以下三类，如下表所示： <ignore_js_op> 系统模型如图所示： <ignore_js_op> 传统轮询远程service服务 传统远程的service往往是这样服务的，服务提供者在远程service注册自己的服务，服务调用者不断去远程service轮询看看是否服务提供者有没有提供服务或者更新服务。所以有弊端，就是延时比较高，而且因为很多不必要的空轮询带来高的负载和网络损耗，这种模式到zk里面就应该是这样。 <ignore_js_op>

1、系统架构 Client 1 包含访问hbase的接口，client维护着一些cache来加快对hbase的访问，比如regione的位置信息。 Zookeeper 1 保证任何时候，集群中只有一个master 2 存贮所有Region的寻址入口 3 实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Master 4 存储Hbase的schema,包括有哪些table，每个table有哪些column family Master职责 1 为Region server分配region 2 负责region server的负载均衡 3 发现失效的region server并重新分配其上的region 4 HDFS上的垃圾文件回收 5 处理schema更新请求 Region Server职责 1 Region server维护Master分配给它的region，处理对这些region的IO请求 2 Region server负责切分在运行过程中变得过大的region 可以看到，client访问hbase上数据的过程并不需要master参与（寻址访问zookeeper和region server，数据读写访问regione server），master仅仅维护者table和region的元数据信息，负载很低。 2、整体结构（ 物理存储 ） 1

用一web应用集群，负载均衡部署实现： 在上图可以看到，变量A在JVM1、JVM2、JVM3三个JVM内存中（这个变量A主要体现是在一个类中的一个成员变量，是一个有状态的对象），如果我们不加任何控制的话，变量A同进都会在JVM分配一块内存，三个请求发过来同时对这个变量进行操作，显然结果不是我们想要的。 如果我们业务中存在这样的场景的话，就需要找到一种方法来解决。 为了保证一个方法或属性在高并发的情况下同一时间只能被同一个线程执行，在传统单机部署的情况下，可以使用Java并发处理相关的API（如 ReentrantLock 或 Synchronized ）进行互斥控制。但是，随之业务发展的需要，原单机部署的系统演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同的机器上，这将原来的单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。 为了解决这个问题，就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！ 分布式锁应该具备哪些条件 在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行； 高可用、高性能的获取锁与释放锁； 具备可重入特性； 具备锁失效机制、防止死锁； 具备非阻塞锁特性，即没有获取到锁直接返回获取锁失败； 分布式锁的实现方式 目前几乎所有大型网站及应用都是分布式部署

ZooKeeper是Hadoop Ecosystem中非常重要的组件，它的主要功能是为分布式系统提供一致性协调(Coordination)服务，与之对应的Google的类似服务叫Chubby。今天这篇文章分为三个部分来介绍ZooKeeper，第一部分介绍ZooKeeper的基本原理，第二部分介绍ZooKeeper提供的Client API的使用，第三部分介绍一些ZooKeeper典型的应用场景。 　　 　　ZooKeeper基本原理 　　 　　1. 数据模型 　　 　　zookeeper-tree 　　 　　如上图所示，ZooKeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。每个ZNode都可以通过其路径唯一标识，比如上图中第三层的第一个ZNode, 它的路径是/app1/c1。在每个ZNode上可存储少量数据(默认是1M, 可以通过配置修改, 通常不建议在ZNode上存储大量的数据)，这个特性非常有用，在后面的典型应用场景中会介绍到。另外，每个ZNode上还存储了其Acl信息，这里需要注意，虽说ZNode的树形结构跟Unix文件系统很类似，但是其Acl与Unix文件系统是完全不同的，每个ZNode的Acl的独立的，子结点不会继承父结点的，关于ZooKeeper中的Acl可以参考之前写过的一篇文章

zk集群的选举机制： 半数机制 ：zk集群中的有半数以上的节点存活，zk就能正常运行，所以zk集群节点最好是奇数个。Zk集群中只有一个leader，其他都是follower 选举机制 :会经过投票，票数大于半数以上的第一台服务器，当选leader Server1 server2 server3 server4 server5 (id大的不给id小的投票，id小的会给id大的投票，server1-5，id依次增大) 5台机器：server1开始投票，server1投自己，因为server1 id最小，所以server1只有一票 Server2：server2会投自己，server1也会投server2一票，server2 两票 Server3：server3会投自己，server1和server2各自投server3一票，那么server3就三票，三票在半数以上(一共五台机器)，所以就选server3当leader， 后边的server4(4票)和server5(5票)虽然来都比server3票数多，但是server3是第一个票数大于半数以上的，所以就选择server3当leader Zokeeper的监听的原理：(重点) 1）首先要有一个main()线程 2）在main()线程中创建zookeeper的客户端，这时就会创建两个线程，一个负责网络连接通信(connect)

介绍 Kafka 是由 Apache软件基金会 开发的一个开源流处理平台，由 Scala 和 Java 编写。Kafka是一种高吞吐量的 分布式 发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。 这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像 Hadoop 一样的 日志 数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka的目的是通过 Hadoop 的并行加载机制来统一线上和离线的消息处理，也是为了通过 集群 来提供实时的消息。 一、KAFKA 体系结构图： Producer ： 生产者，也就是发送消息的一方。生产者负责创建消息， 通过 zookeeper 找到 broker ， 然后将其投递到 Kafka 中。 Consumer ： 消费者，也就是接收消息的一方。 通过 zookeeper 找对应的 broker 进行消费 ， 进而进行相应的业务逻辑处理。 Broker ： 服务代理节点。对于 Kafka 而言， Broker 可以简单地看作一个独立的 Kafka 服务节点或 Kafka 服务实例。大多数情况下也可以将 Broker 看作一台 Kafka 服务器，前提是这台服务器上只部署了一个 Kafka 实例。一个或多个

概述 Zookeeper字面上理解就是动物管理员，是大数据框架Hadoop生态圈中的一个服务中间件，Hadoop生态圈中很多开源项目使用动物命名，那么需要一个管理员来管理这些“动物”。他负责分布式应用程序协调的工作。 Hadoop框架 Zookeeper主要提供以下四点功能： 统一命名服务、配置管理、集群管理、共享锁和队列管理 ，用于高效的管理集群的运行。 Zookeeper通过心跳机制可以检测挂掉的机器并将挂掉机器的ip和服务对应关系从列表中删除。 Zookeeper 部署有三种方式，单机模式、集群模式、伪集群模式，以下采用Docker 的方式部署 注意： 集群为大于等于3个奇数，如 3、5、7,不宜太多，集群机器多了选举和数据同步耗时长，不稳定。 zk安装 docker-compose-yml version: '3.1' services: zoo1: image: zookeeper restart: always hostname: zoo1 ports: - 2181:2181 environment: ZOO_MY_ID: 1 ZOO_SERVERS: server.1=zoo1:2888:3888 配置说明 2181：客户端连接 Zookeeper 集群使用的监听端口号 3888：选举 leader 使用 2888：集群内机器通讯使用（Leader 和

参考： Zookeeper的一致性协议：Zab Chubby&Zookeeper原理及在分布式环境中的应用 Paxos vs. Viewstamped Replication vs. Zab Zab vs. Paxos Zab: High-performance broadcast for primary-backup systems Chubby：面向松散耦合的分布式系统的锁服务 Chubby 和Zookeeper 的理解 zookeeper 使用Zab(zookeeper atom broadcast). Zab集群机器越多，写性能会有所降低、读性能得到水平扩展。从Follower直接读取数据，虽不保证最新但最终会读到最新的，为其应用领域配置管理上读>>写而设计。 具体下面描述更加清楚： Zab is a different protocol than Paxos, although it shares with it some key aspects, as for example: A leader proposes values to the followers Leaders wait for acknowledgements from a quorum of followers before considering a proposal committed

1.1. 一致性协议概述 前面已经讨论过，在分布式环境下，有很多不确定性因素，故障随时都回发生，也讲了 CAP 理论， BASE 理论 我们希望达到，在分布式环境下能搭建一个高可用的，且数据高一致性的服务，目标是这样，但 CAP 理论告诉我们要达到这样的理想环境是不可能的。这三者最多完全满足 2 个。 在这个前提下， P （分区容错性）是必然要满足的，因为毕竟是分布式，不能把所有的应用全放到一个服务器里面，这样服务器是吃不消的，而且也存在单点故障问题。 所以，只能从一致性和可用性中找平衡。 怎么个平衡法？在这种环境下出现了 BASE 理论： 即使无法做到强一致性，但分布式系统可以根据自己的业务特点，采用适当的方式来使系统达到最终的一致性； BASE 由 Basically Avaliable 基本可用、 Soft state 软状态、 Eventually consistent 最终一致性组成，一句话概括就是：平时系统要求是基本可用，除开成功失败，运行有可容忍的延迟状态，但是，无论如何经过一段时间的延迟后系统最终必须达成数据是一致的。 其实可能发现不管是 CAP 理论，还是 BASE 理论，他们都是理论，这些理论是需要算法来实现的，今天讲的 2PC 、 3PC 、 Paxos 算法， ZAB 算法就是干这事情。 所以今天要讲的这些的前提一定是分布式，解决的问题全部都是在分布式环境下

一、Zookeeper的角色 » 领导者（leader），负责进行投票的发起和决议，更新系统状态 » 学习者（learner），包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并想客户端返回结果，在选主过程中参与投票 » Observer可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度 » 客户端（client），请求发起方 ObServer： Observers：在不伤害写性能的情况下扩展Zookeeper 尽管通过Client直接连接到Zookeeper集群的性能已经非常好了，但是这种架构如果要承受超大规模的Client，就必须增加Zookeeper集群的Server数量， 随着Server的增加，Zookeeper集群的写性能必定下降，我们知道Zookeeper的Znode变更是要过半数投票通过，随着机器的增加，由于网络消耗等原因 必然导致投票成本增加，从而导致写性能的下降。 Observer是一种新型的Zookeeper节点，可以帮助解决上述问题，提供Zookeeper的可扩展性。Observer不参与投票，只是简单的接收投票结果，因此我们 增加再多的Observer，也不会影响集群的写性能。除了这个差别