@如何理解ZOOKEEPER及其地位
一、ZooKeeper基本介绍 1.1、何为ZooKeeperZooKeeper是一个分布式协调服务的开源框架，核心功能是解决分布式集群中应用系统的一致性问题（超赞的功能）。
ZooKeeper的本质可以理解为一个分布式的小文件存储系统，结构类似于文件系统的目录树，在目录树节点进行数据存储、维护和管理，通过监控对这些数据状态的变化，从而实现基于数据的集群管理。
分布式系统：
分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。简单来说就是一群独立计算机集合共同对外提供服务，但是对于系统的用户来说，就像是一台计算机在提供服务一样。
分布式意味着可以采用更多的普通计算机（相对于昂贵的大型机）组成分布式集群对外提供服务。计算机越多，CPU、内存、存储资源等也就越多，能够处理的并发访问量也就越大。
互联网网站常用的架构：
全局数据一致性：
ZK集群中每台服务器均会保存相同的一份数据副本，对于client来说，无论连接至哪台服务器，数据都是相同的；
可靠性：
ZK集群各服务器之间消息同步，只要有一台服务器接收消息成功，则ZK集群接收消息成功；
顺序性：
ZK集群中，消息存在先后顺序，具体又细分为全局有序和偏序两种；全局有序–指如果在一台服务器上消息a在消息b前发布，则在所有服务器上消息a都将在消息b前被发布；偏序–指如果消息b在消息a后被同一个发送者发布，a必将排在b前面；
数据更新原子性：
数据更新要么成功（半数以上节点成功），要么失败；
实时性：
client在一定时间范围内，获得服务器的更新信息。
大数据集群的心脏。
大数据生态里面，hadoop、hbase、hive…等组件都是分布式部署，这些组件利用Zookeeper的服务做了一些维持自身平衡的事情，比如集群管理、master选举、消息发布订阅、数据存储、分布式锁等。
分布式锁机制：
分布式锁的定义：在分布式系统中，应用可能部署在多台机器上，应用不在同一个jvm里面，这个时候还需要维护一个互斥排他的策略，需要一个跨jvm的锁同步，为了解决跨系统、跨jvm的锁，我们就必须引入分布式锁。
-
排他锁(写锁/独占锁)
核心：保证当前有且仅有一个事务获得锁，并且锁释放之后，所有正在等待获取锁的事务都能够被通知到；
保证在分布式高并发情况下节点的创建一定能够保证全局唯一性（全局数据一致性） -
共享锁（读锁）
加了共享锁之后，数据对象对所有事务都可见；
如果事务T1对数据对象O1加上了共享锁，那么当前事务只能对O1进行读取操作，其他事务也只能对这个数据对象加共享锁，直到该数据对象上的所有共享锁都被释放。
Zookeeper集群通常由2n+1台servers组成。这是因为为了保证Leader选举（基于Paxos算法的实现）能够得到多数的支持，所以ZooKeeper集群的数量一般为奇数。超过半数有效。
2.1、ZooKeeper集群介绍ZK集群图示：
| 角色对比 | 节点名称 | 事务请求（写操作） | 非事务请求（读操作） | Leader选举投票 | 是否必须存在 |
|---|---|---|---|---|---|
| Leader | 主节点 | 唯一可处理，保证顺序性，调度集群服务器 | 不处理 | 参与 | 是 |
| Follower | 从节点 | 转发事务请求给Leader | 处理非事务（读操作）请求 | 参与 | 是 |
| Observer | 观察者 | 转发事务请求给Leader | 处理非事务（读操作）请求 | 不参与 | 针对访问量比较大的zookeeper集群，负责观察Zookeeper集群的最新状态变化并将这些状态同步过来，通常用于提升集群的非事务处理能力 |
Server：服务器，所有的节点都是一台服务器；
Client：客户端；
事务：一个对于写操作（create，setData，delete等）的请求，统一转给Leader处理，并由其决定编号、执行操作的过程；
很多应用都是master-slave架构，master必须7*24小时工作，但是每次只能一个master在工作，这时需要一个选举机制，确定一个active状态的master，当active的master出现故障挂掉的时候，standby的master顶上去，这里主要讲zk这端的实现。
Master选举的功能：
各个master注册到zk的目录下，创建临时节点，成功在zk创建临时节点的目录，也就被选举为Master，其它备用的Master就会收到监听zk里面临时节点的变化，一旦删除，就会争夺创建临时节点的权利成为新的Master。
本质其实是利用zookeeper的临时节点的特性：临时节点随着会话的消亡而消亡，同一个临时节点只能创建一个，创建失败的节点（从master）对创建成功节点（主master）进行监控，一旦创建成功的节点（主master）会话消失，之前创建失败的节点（从master）就会监听到去抢夺创建临时节点
三、ZooKeeper集群选举机制zookeeper集群选举默认的算法是FastLeaderElection，采用投票数大于半数则胜出的逻辑。
3.1、概述服务器ID：
每台服务器都有编号，编号越大在选择算法中的权重越大。
选举状态：
| 状态 | 描述 |
|---|---|
| LOOKING | 竞选状态，很短暂 |
| LEADING | 领导者状态 |
| FOLLOWING | 随从状态，同步leader状态，参与投票 |
| OBSERVING | 观察状态，同步leader状态，不参与投票 |
数据ID/事务id：
- 服务器中存放的最新数据version；
- 值越大说明数据越新，在选举算法中数据越新权重越大。
逻辑时钟：
- 也叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的；
- 每投完一次票这个数据就会增加，然后与接收到的其它服务器返回的投票信息中的数值相比，根据不同的值做出不同的判断。
以5台服务器为例，每台服务器均没有数据，编号为1、2、3、4、5，按编号依次启动，选举过程如下：
-
服务器1启动，给自己投票，然后发投票信息，由于其它机器还未启动所以它收不到反馈信息，服务器1的状态为LOOKING ；
-
服务器2启动，给自己投票，同时与服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以服务器1、2的状态依然是LOOKING；
-
服务器3启动，给自己投票，同时与服务器1、2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为Leader，服务器1,2成为Follower ；
-
服务器4启动，给自己投票，同时与服务器1、2、3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为Follower ；
-
服务器5启动，后面的逻辑同服务器4成为Follower 。
正常运行的zookeeper集群，中途会存在有机器down掉的情况，在需要重新选举时，选举过程就需要加入事务ID、服务器ID和逻辑时钟。
- 事务ID（zxid）：即数据ID，数据越新，version就大，数据每次更新都会更新version。
- 服务器ID：机器编号，就是我们配置的myid中的值，每个机器一个。
- 逻辑时钟：这个值从0开始递增,每次选举对应一个值。 如果在同一次选举中,这个值是一致的。
Leader选举标准：
- 逻辑时钟小的选举结果被忽略，重新投票；
- 统一逻辑时钟后，事务ID大的胜出；
- 事务ID相同的情况下，服务器ID大的胜出；
ZooKeeper的数据模型，在结构上和标准文件系统相似：拥有一个层次的命名空间；采用树形层次结构。
4.1、数据结构
图中ZooKeeper树的每个节点称为一个Znode， 每个Znode由3部分组成：
- stat：此为状态信息, 描述该Znode的版本, 权限等信息
- data：与该Znode关联的数据
- children：该Znode下的子节点
Znode特性：
| Znode特性 | 描述 |
|---|---|
| Znode兼具文件和目录两种特点 | 可以像文件一样维护数据、元信息、ACL、时间戳等数据结构，又可以像目录一样可以作为路径标识的一部分；用户对Znode具有增、删、改、查等操作（权限允许的情况下）。 |
| Znode具有原子性操作 | 读操作将获取与节点相关的所有数据，写操作将替换掉节点的所有数据；每个节点都拥有自己的ACL(访问控制列表)，这个列表规定了用户的权限，限定了特定用户对目标节点可以执行的操作。 |
| Znode存储数据大小有限制 | ZooKeeper虽然可以关联一些数据，但并没有被设计为常规的数据库或者大数据存储；它用来管理调度数据，比如分布式应用中的配置文件信息、状态信息、汇集位置等等；这些数据的共同特性就是它们都是很小的数据，通常以KB为大小单位；ZooKeeper的服务器和客户端都被设计为严格检查并限制每个Znode的数据大小至多1M，但是常规使用中应该远小于此值。 |
| Znode通过路径引用 | 如同Unix中的文件路径，路径要求是绝对的、唯一的，必须由斜杠字符来开头，路径不能改变；在ZooKeeper中，路径由Unicode字符串组成，并且有一些限制；字符串"/zookeeper"用以保存管理信息，比如关键配额信息。 |
zk的所有Znode不管父子节点都能带数据，但linux的目录不能，所以zk里面的路径不能叫文件夹也不能叫文件，统一称为Znode。
zookeeper的文件系统的特点：
zk的文件系统和Linux的文件系统目录结构一样，从/开始；
zk的访问路径只有绝对路径，没有相对路径；
zk中没有文件和目录的概念，只有znode节点，Znode既有文件的功能，又有目录的功能。
Znode节点类型可分为两种：临时节点和永久节点。ZK的数据类型类似一棵树，所有的节点都称为Znode,节点的类型在创建时被确定，不能改变。
临时节点：
临时节点的生命周期依赖于创建它们的会话；
一旦会话结束，临时节点将被自动删除，也可以手动删除；
临时节点不允许拥有子节点。
永久节点：
永久节点的生命周期不依赖于会话，只有在客户端显示执行删除操作的时候，才能被删除。
序列化特性：
Znode节点有序性，Znode节点创建时，若指定序列化特性，该Znode的名字后面会自动追加一个不断增加的序列号；
序列号对于此节点的父节点来说是唯一的，这样便会记录每个子节点创建的先后顺序，它的格式为“%10d”(10位数字，没有数值的数位用0补充，例如“0000000001”)。
序列化特性下的四种Znode节点类型：
- PERSISTENT：永久节点
- EPHEMERAL：临时节点
- PERSISTENT_SEQUENTIAL：永久节点、序列化
- EPHEMERAL_SEQUENTIAL：临时节点、序列化
znode包含了一系列的属性，通过命令get，可以获得节点的属性：
属性介绍：
| 属性 | 描述 |
|---|---|
| cZxid | Znode创建的事务id |
| ctime | 节点创建时的时间戳 |
| mZxid | Znode被修改的事务id，即每次对znode的修改都会更新mZxid。 |
| mtime | 节点最新一次更新发生时的时间戳 |
| pzxid | 事务id，增删改的序号 |
| cversion | 子节点的版本号。当znode的子节点有变化时，cversion 的值就会增加1。 |
| dataVersion | 数据版本号，每次对节点进行set操作，dataVersion的值都会增加1（即使设置的是相同的数据），有效避免了数据更新时出现的先后顺序问题。 |
| ephemeralOwner |
事务id（zxid）：
对于zk来说，每次的变化都会产生一个唯一的事务id，zxid（ZooKeeper Transaction Id）。通过zxid，可以确定更新操作的先后顺序。例如，如果zxid1小于zxid2，说明zxid1操作先于zxid2发生，zxid对于整个zk都是唯一的，即使操作的是不同的znode。
首先，在zk中创建持久节点 /GroupMembers 作为父节点，父节点监听子节点的变化，client通过注册到zk，会在/GroupMembers下创建临时节点，临时节点的特性时当客户端与zk断开连接时会自动删除，不论是创建和删除，zk server都会监听，通过Watcher监听与通知机制，并且会把变动的结果通知到到其它client，这样，其它所有client都知道了其它兄弟们的存活情况。
#连接客户端 zkCli.sh -server node01 #命令提示 help create [-s][-e] path data acl # -s 顺序节点 # -e 临时节点，若不指定，则表示持久节点 # acl用来进行权限控制。 #永久节点需要显示的删除： delete rmr #临时节点可显示删除，也可断开时自动消失 节点的类型一共以四种 临时 永久 有序的临时节点 有序的永久节点 #创建顺序节点： create -s /test 123 #创建永久节点： create /test-p 123p #读取节点 #路径下的子节点列表：ls path [watch] ls / #获取节点信息：get path [watch] get /test #获取路径节点信息和路径下子节点列表 ls2 path [watch] ls2 /test #更新节点：set path data [version] #data就是要更新的新内容，version表示数据版本。 set /test abc #删除节点 #delete path [version] #若删除节点存在子节点，那么无法删除该节点，必须先删除子节点，再删除父节点。 delete /test #rmr path #可以递归删除节点。 rmr /test #quota #setquota -n|-b val path 对节点增加限制。 # n:表示子节点的最大个数 # b:表示数据值的最大长度 # val:子节点最大个数或数据值的最大长度 # path:节点路径 setquota -n 2 /quota #设定test下只能有一个子节点 setquota -b 20 /quota #设定test节点只能存放20b数据 listquota path #列出指定节点的quota listquota /quota delquota [-n|-b] path #删除quota delquota -n /quota delquota -b /quota history #列出命令历史 redo #该命令可以重新执行指定命令编号的历史命令,命令编号可以通过history查看 redo 11五、ZooKeeper Watcher机制
ZooKeeper中引入了Watcher机制的概念，实现了分布式数据发布/订阅功能，定义了一种一对多的订阅关系，能让多个订阅者同时监听某一个主题对象，当这个主题对象自身状态变化时，会通知所有订阅者，使他们能够做出相应的处理。
5.1、Watcher机制Watcher机制流程：
- 客户端向服务端注册一个Watcher监听；
- 服务端的一些事件触发Watcher监听；
- 向指定客户端发送一个事件通知。
Watcher机制特点：
| 特点 | 描述 |
|---|---|
| 事件封装 | ZooKeeper使用WatchedEvent对象来封装服务端事件并进行传递 |
| 事件属性 | 通知状态（keeperState）；事件类型（EventType）；节点路径（path） |
| 先注册再触发 | Watcher机制，必须客户端先去服务端注册监听，事件发送才会触发监听，通知给客户端 |
| 一次性触发 | 事件发生触发监听，一个watcher event就会被发送到设置监听的客户端，这种效果是一次性的，后续再次发生同样的事件，不会再次触发 |
| event异步发送 | watcher的通知事件从服务端发送到客户端是异步的 |
| 触发event种类 | 节点创建，节点删除，节点改变，子节点改变等 |
同一个事件类型在不同的通知状态中代表的含义有所不同：
| Keeper State | EventType | 触发条件 | 说明 |
|---|---|---|---|
| None(-1) | 客户端与Zookeeper服务端建立连结成功 | ||
| Disconnected(0)) | None(-1) | 客户端与Zookeeper服务器断开连结 | |
| AuthFailed(4)) | None(-1) | 通常有2种情况：1.使用错误的schema进行权限检查；2.SASL权限检查失败 | 同时也会收到AuthFailedException异常 |
| Expired(-112)) | Node(-1) | 会话超时 | 客户端会话失效，通常同时会收到SessionExpiredException异常 |
| SyncConnected(0) | NodeCreated(1) | Watcher监听的对应数据节点被创建 | |
| NodeDeleted(2) | Watcher监听的对应数据节点被删除 | 此时客户端与服务端处于连结状态 | |
| NodeDataChanged(3) | Watcher监听的对应数据节点的数据内容发生变更 | ||
| NodeChildChanged(4) | Watcher监听的对应数据节点的子节点列表发生变更 |
master选举的Znode监听：
当备用的master发现Znode已经被其它master创建后，这时备用master会注册监听这个Znode的变化。
锁机制：
基于监听机制上才能实现，比如释放锁的时候，需要告诉其它访问的应用这个Znode代表的锁已经释放，通知其它应用可以获取锁以进行下一步操作。
NameNode的HA：
zkfc机制（排他锁/写锁）
Yarn的HA：
zkfc机制（排他锁/写锁）
yarn的容错机制也带来一系列问题：
- 一个spark任务在yarn运行突然失败了，默认会重试，重试前会把上一次的driver端的信息写入zk，这时如果driver端的数据太大，比如你代码里broadcast一个很大的文件，这样很容易把zk写满写挂，直接导致zk不能工作，zk停止工作直接的代价是整个集群不能正常工作；
- application的信息存放在zk里面是持久化的节点，不会自动删除，当yarn的历史任务运行太多的时候，zk里面会存一堆的application的历史信息，导致zk的内存占用越来越大，也影响性能，需要写脚本手工清除。
hbase regionserver 向zookeeper注册，提供hbase regionserver状态信息（是否在线），HMaster通过watcher监听regionserver的存活情况，并不是HMaster跟Regionserver通过心跳机制检测。
HMaster启动时候会将hbase系统表-ROOT- 加载到 zookeeper cluster，通过zookeeper cluster可以获取当前系统表.META.的存储所对应的regionserver信息
6.3、Kafkabroker的注册：
所有broker会把自己的id号注册进zk的Znode里面，通过事件监听的机制，各个broker之间都知道所有兄弟的存活情况。当有broker启动时，会在zk里面创建Znode，并通知其它broker；当有broker下线或挂掉时，同样会通知其它broker。
topic的注册：
当topic创建时，kafka会把topic的name、partition、leader、topic的分布情况等信息写入zk里面，当broker退出时，会触发zookeeper更新其对应topic分区的isr列表，并决定是否需要做消费者的负载均衡。
consumer的注册：
当有新的消费者消费kafka数据时，会在zk中创建Znode保存一些信息，节点路径为ls /consumers/{group_id}，其节点下有三个子节点，分别为[ids, owners, offsets]。在常用的offset的维护中，应用消费kafka数据时要设置参数enable.auto.commit为true才会自动更新offset。
hiveserver2的选举：
hiveserver2用的锁是共享锁
表数据锁：
Hive 锁机制是为了让 Hive 支持并发读写的原子性而设计的 特性，比如，一个sql在insert数据，这时需要锁住表，不让其它sql去读取表数据，否则会有问题。
