版权声明：Collected by Bro_Rabbit only for study https://blog.csdn.net/weixin_38240095/article/details/83059753
一、概述
- Hadoop生态的分布式协调服务组件，基于对Paxos算法的实现，包含一个简单的原语集，分布式应用程序可以基于它实现一致性的同步服务，配置维护和命名服务等
- 几点细节说明
(1) Leader 是一个主节点，所有数据的写操作都是经由Leader实现的。客户端先更新Leader上的数据，Leader通知其他的Follower更新这份数据，且有半数以上的Follower更新成功就认为本次更新成功
(2) Leader和Follower不是启动之前由配置文件设置的角色，而是通过选举机制进行投票，一旦有一个server当选Leader，那么其他server自动成为Follower
(3) Obserber也可以接收客户端链接，将写请求转发给Leader，但Observer不参加投票过程，只同步Leader的状态。 Observer的目的是为了扩展系统，提高读取速度。
二、集群搭建
- ZooKeeper集群有基数个节点，最少为3个。
- 关键修改conf目录下的配置文件
mv zoo_sample.cfg zoo.cfg# The number of milliseconds of each tick (服务器之间或客户端与服务器之间维持心跳的时间间隔，每过一个 tickTime 时间就会发送一个心跳。以毫秒为单位。) tickTime=2000 # The number of ticks that the initial synchronization phase can take（集群中的Follower服务器与Leader服务器之间初始连接时能容忍的最大心跳数） initLimit=10 # The number of ticks that can pass between sending a request and getting an acknowledgement （集群中的Follower服务器与Leader服务器之间请求和应答之间能容忍的最大心跳数，超过则超时） syncLimit=5 # the directory where the snapshot is stored.do not use /tmp for storage, /tmp here is just example sakes.（本地保存数据的目录，默认情况下，ZooKeeper将写数据的日志文件也保存在这个目录里） dataDir=/home/hadoopApp/zookeeper-…/data # the port at which the clients will connect（客户端连接 ZooKeeper 服务器的端口，ZooKeeper 会监听这个端口，接受客户端的访问请求） clientPort=2181 # the maximum number of client connections. # increase this if you need to handle more clients #maxClientCnxns=60 # Be sure to read the maintenance section of the administrator guide before turning on autopurge. # http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance # The number of snapshots to retain in dataDir # autopurge.snapRetainCount=3 # Purge task interval in hours # Set to "0" to disable auto purge feature # autopurge.purgeInterval=1 #Servers config （ZooKeeper集群服务器.编号：通信端口：选举端口） server.<n>=<HostName>:2888:3888 - 在 工作目录 下创建一个名为 myid 的文件，其内容为本服务器在配置文件中的标识（server.<n>的<n>）
- 进入ZooKeeper-…/bin，执行./zkServer.sh start， 启动后回生成一个QuorumPeerMain进程
- 少于集群数量的一半，ZooKeeper不会工作（因为无法得到半数票，选不出Leader）。 可以使用./zkServer status查看状态角色
- 使用 ./zkCli.sh 登录只本地ZK服务器测试（通过help可查看zkshell命令）
三、节点
- ZooKeeper管理客户端所存放的数据采用的是类似于文件树的结构：从根节点/开始
- 每个Znode可以保存信息数据，最好小于1M，可以创建子节点
- Znode有两种类型：短暂( ephemeral )和持久( persistent )
* 短暂Znode在客户端会话结束时，ZooKeeper回将该短暂Znode删除，短暂Znode不可以有子节点
* 持久Znode不依赖于客户端会话，只有当客户端明确要删除该持久Znode时才会被删除
四、典型应用场景[转载]
| 情景 | 概述 | 详细 |
|---|---|---|
| 数据发布与订阅( 配置中心 ) | 发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等。 默认前提：数据量很小，但数据更新可能回比较快的场景。 |
|
| 软负载均衡 | 在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多分，达到对等服务。而消费者就需要在这些对等的服务器中选择一个来执行相关的业务逻辑，其中比较单行的是消息中间件的生产者与消费者的负载均衡 | linkedin开源的KafkaMQ和阿里开源的MetaQ都是通过ZooKeeper来做到生产者和消费者的负载均衡。这里以metaq为例：
|
| 命名服务 | 命名服务也是分布式系统中比较常见的一类场景。在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。被命名的实体通常可以是集群中的机器，提供的服务地址，远程对象等等——这些都可以统称为名字Name。其中较为常见的就是一些分布式服务框架中的服务地址列表。通过调用ZK提供的创建节点的API，能够很容易创建一个全局唯一的Path，这个Path即可作为一个名称 | 阿里开源的分布式服务框架Dubbo中使用ZK来作为其命名服务，维护全局的服务地址列表。在Dubbo实现中：
另外，Dubbo还有针对服务力度的监控，方法是订阅/dubbo/${serviceName}目录下所有提供者和消费者的信息 |
| 分布式通过/协调 | ZK中特有watcher注册与异步通知机制，能够很好地实现分布式环境下不同系统之间地通知与协调，实现对数据变更地实时处理。使用方法通常是不同系统都对ZK上同一个Znode进行注册，监听Znode的变化（包括Znode本身内容及子节点的），其中一个系统Update了Znode，那么另一个系统能够收到通知，并作出相应处理 |
|
| 集群机器管理 | 通常用于那种对集群中机器状态，机器在线率有较高，需要快速对集群中机器变化做出响应的场景。 | 过去的做法通常是使用监控系统，通过某种手段( 比如ping )定时检测每个机器，或者每个机器自己定时向监控系统汇报心跳。这种做法可行，但存在两个比较明显的问题：
|
| Master选举 | Master选举是ZK中最为经典的应用场景。在分布式环境中，相同的业务应用分布在不同的机器上，有些业务逻辑（如一些耗时计算，网络I/O），往往只需要让整个集群中的某一台机器进行执行，其余机器可以共享这个结果，这样可以大大减少重复劳动，提高性能 | 利用ZK的强一致性，能够保证在分布式高并发情况下节点创建的全局唯一性，即：同时有多个客户端请求创建/clusterMaster节点，最终一定只有一个客户端能够创建成功。利用这个特性，就能很轻易的在分布式环境中进行集群选取。 另外，将该场景进行演化即为动态Master选举。需要用到EPHEMERAL_SEQUENTIAL类型节点的特性。与之前不同，该场景允许所有请求都能够创建成功，但必须按找顺序进行创建，故所有的请求在ZK上创建结果的一种可能情况如下：/currentMaster/{sessionId}-1, /currentMaster/{sessionId}-2, /currentMaster/{sessionId}-3 … 每次选区序列号最小的那个机器作为Master，若该机器挂了，由他创建的节点会马上随之消失，那么之后最小的那个机器就是Master
|
| 分布式锁 | 分布式锁，主要得益于ZooKeeper保证了数据的强一致性。 锁服务可以分为两类，一个是保持独占，另一个是控制时序 |
|
| 分布式队列 | 简单地将有两种，一种是常规的先进先出，另一种是要等到队列成员聚齐之后才统一按序执行类BATCH |
|