Zookeeper快速入门（一）

本文来自bilibili视频：
https://www.bilibili.com/video/BV1JT4y1g7nM?p=19

Zookeeper概述

• Zookeeper 是一个开源的分布式协调服务框架 ，主要用来解决分布式集群中应用系统的一致性问题和数据管理问题。

例如：
1、网络中的不同主机的进程对共享资源访问的一致性问题（分布式锁）。

2、进程1、2看到的共享资源要和进程3看到的共享资源一致。假如进程1在写，进程3要读，进程3要通过网络同步文件以后才可以读文件。

Zookeeper特点

• Zookeeper 本质上是一个分布式文件系统（多台主机进行整合），适合存放小文件（更多的是配置文件），也可以理解为一个数据库。
• 用户并不关心文件（data.conf）存储在哪个主机上，Zookeeper会对外提供一个统一的访问路径。
• 圆形代表Znode（Zookeeper节点），既有文件特性，又有文件夹特性。
  
• 可以通过操作文件系统的方式操作Zookeeper
  • 使用路径获取Znode
  • 获取Znode携带的数据
  • 修改Znode携带的数据
  • 删除Znode
  • 添加Znode

Zookeeper架构

Zookeeper集群是一个基于主从架构的高可用（7×24hour）集群。

读请求一般被称为非事务性操作，写操作被称为事务性请求。
一般情况下，Follower只能处理非事务性请求，若收到了write请求则需要转发给Leader。

每个服务器承担如下三种角色中的一种：

• Leader：一个Zookeeper集群同一时间只会有一个实际工作的Leader,它会发起并维护与各Follwer及Observer间的心跳。所有的写操作必须要通过Leader完成再由Leader将写操作广播给其它服务器。
• Follower：一个Zookeeper集群可能同时存在多个Follower,它会响应Leader的心跳。Follower可直接处理并返回客户端的读请求，同时会将写请求转发给Leader处理，并且负责在Leader处理写请求时对请求进行投票。
• Observer 角色与Follower类似，但是无投票权。

Zookeeper应用场景

数据发布 / 订阅

数据发布/订阅系统,需要发布者将数据发布到Zookeeper的节点上,供订阅者进行数据订阅，进而达到动态获取数据的目的，实现配置信息的集中式管理和数据的动态更新。发布/订阅一般有两种设计模式：推模式和拉模式，服务端主动将数据更新发送给所有订阅的客户端称为推模式；客户端主动请求获取最新数据称为拉模式。
Zookeeper采用了推拉相结合的模式，客户端向服务端注册自己需要关注的节点，一旦该节点数据发生变更，那么服务端就会向相应的客户端推送Watcher事件通知，客户端接收到此通知后，主动到服务端获取最新的数据。

Watch机制可以监控节点的变化：如果源数据发生改变则节点也发生改变。

命名服务

命名服务是分步实现系统中较为常见的一类场景，分布式系统中，被命名的实体通常可以是集群中的机器、提供的服务地址或远程对象等，通过命名服务，客户端可以根据指定名字来获取资源的实体，在分布式环境中，上层应用仅仅需要一个全局唯一的名字。Zookeeper 可以实现一套分布式全局唯一ID的分配机制。

通过调用Zookeeper节点创建的API接口就可以创建一个顺序节点, 并且在API返回值中会返回这个节点的完整名字，利用此特性，可以生成全局ID，其步骤如下：
1.客户端根据任务类型,在指定类型的任务下通过调用接口创建一个顺序节点， 如"job-"。
2创建完成后，会返回一个完整的节点名,如"job-00000001"
3.客户端拼接type类型和返回值后，就可以作为全局唯一ID了 ，如"type2-job-00000001".

分布式协调 / 通知

Zookeeper中特有的Watcher注册于异步通知机制，能够很好地实现分布式环境下不同机器，甚至不同系统之间的协调与通知，从而实现对数据变更的实时处理。通常的做法是不同的客户端都对Zookeeper上的同一个数据节点进行Watcher注册，监听数据节点的变化(包括节点本身和子节点)，若数据节点发生变化，那么所有订阅的客户端都能够接收到相应的Watcher通知，并作出相应处理。
在绝大多数分布式系统中，系统机器间的通信无外乎心跳检测、工作进度汇报和系统调度。

1. 心跳检测
   不同机器间需要检测到彼此是否在正常运行：基于其临时节点特性(临时节点的生存周期是客户端会话，客户端若宕机后,其临时节点自然不再存在)，可以让不同机器都在Zookeeper的一个指定节点下创建临时子节点，不同的机器之间可以根据这个临时子节点来判断对应的客户端机器是否存活。通过Zookeeper可以大大减少系统耦合。
   
2. 工作进度汇报
   通常任务被分发到不同机器后，需要实时地将自己的任务执行进度汇报给分发系统，可以在Zookeeper上选择一个节点， 每个任务客户端都在这个节点下面创建临时子节点，这样不仅可以判断机器是否存活，同时各个机器可以将自己的任务执行进度写到该临时节点中去，以便中心系统能够实时获取任务的执行进度。
3. 系统调度
   Zookeeper能够实现如下系统调度模式:分布式系统由控制台和一些客户端系统两部分构成，控制台的职责就是需要将一些指令信息发送给所有的客户端， 以控制他们进行相应的业务逻辑，后台管理人员在控制台上做一些操作，实际上就是修改Zookeeper上某些节点的数据，Zokeeper可以把数据变更以时间通知的形式发送给订阅客户端。

分布式锁

分布式锁用于控制分布式系统之间同步访问共享资源的一种方式，可以保证不同系统访问一个或一组资源时的一 致性，主要分为排它锁和共享锁。

排它锁又称为写锁或独占锁，若事务T1对数据对象O1加上了排它锁，那么在整个加锁期间,只允许事务T1对O1进行读取和更新操作，其他任何事务都不能再对这个数据对象进行任何类型的操作，直到T1释放了排它锁。

1. 获取锁，在需要获取排它锁时，所有客户端通过调用接口，在 /exclusive_ lock节点下创建临时子节点/exclusive_ lock/lock。Zookeeper可以保证只有一 个客户端能够创建成功,没有成功的客户端需要注册/exclusive_ lock节点监听。
   

2. 释放锁，当获取锁的客户端宕机或者正常完成业务逻辑都会导致临时节点的删除，此时，所有在/exclusive_ lock节点上注册监听的客户端都会收到通知，可以重新发起分布式锁获取。

共享锁又称为读锁，若事务T1对数据对象O1加上共享锁,那么当前事务只能对O1进行读取操作,其他事务也只能对这个数据对象加共享锁，直到该数据对象上的所有共享锁都被释放。在需要获取共享锁时，所有客户端都会到 /shared_lock 下面创建一个临时顺序节点。

分布式队列

有一些时候，多个团队需要共同完成一个任务， 比如，A团队将Hadoop集群计算的结果交给B团队继续计算，B完成了自己任务再交给c团队继续做。这就有点像业务系统的工作流一样，一环一环地传下去。
分布式环境下，我们同样需要一个类似单进程队列的组件， 用来实现跨进程、跨主机、跨网络的数据共享和数据传递，这就是我们的分布式队列。