ZooKeeper简介

Zookeeper简介：

Zookeeper是什么？

zookeeper是一种分布式协调中间件，内部存储了分布式服务之间进行沟通的元数据（小而重要的数据），将分布式一致性服务封装起来，并对外暴露了高效可靠灵活的API，保证了分布式操作的最终一致性。

ZNode:

zookeeper是一种znode tree结构，也就是znode组成的一颗树，类似于文件夹目录的那种形式。并且对外暴露关于znode的增删该查的API，而与该API进行交互的一般是 zkclient 或 curator 等框架，客户端程序只需要引入这样的jar包，然后调用这些框架暴露的更加高级、简单的API，实现与zookeeper的交互。

节点分类：znode分为有序临时、有序持久、无序临时、无序持久。其中临时节点会根据会话是否结束而决定保留还是删除。

通知机制：znode有watch机制，可以监测本节点、本节点内容、子节点，发生变化时将相应的事件通知到客户端。

Zxid: 

一个全局递增的唯一ID，用于标识事务，也被称为事务ID。一个16进制的64位id，高32位为epoch，标识leader周期，低32位为自增的一个数值。

每一个事务请求都会转发到leader上，leader发出proposal时，会生成一个zxid标识该proposal。

Zookeeper集群：

集群角色：

leader: 事务请求（写请求）的唯一处理者，保证集群事务处理的顺序性; 集群内部各服务器的调度者。

follower: 处理客户端非事务请求（读请求）；转发事务请求给 leader；参与事务请求 Proposal 的投票; 参与 Leader 选举的投票。

observer: 在 zookeeper3.3 之后才出现的角色，只处理非事务请求；不参与投票。

容灾性：

一个 zookeeper 集群如果要对外提供可用的服务，那么集群中必须要有过半的机器正常工作并且彼此之间能够正常通信。

ZAB协议：

又叫原子广播协议，有两部分组成，消息广播模式、崩溃恢复模式。消息广播模式定义了zookeeper集群中数据同步的模型；崩溃恢复模式定义了leader节点崩溃后如何恢复的模型。

1、消息广播模式：

即leader节点的数据同步到集群中所有其他节点的一个过程：

1、只有leader可以处理事务请求，如果是其他follower或observer接受到事务请求，会转发给leader；

2、leader处理事务请求时，会对集群节点发起proposal，同时为每个proposal分配一个全局id，即zxid；

3、follower、observer接收到proposal之后，会首先将其以事务日志的方式写入本地磁盘，写入成功之后，向leader返回一个Ack消息；

4、只有集群过半的节点返回Ack给leader之后，leader开始对集群节点发起commit，同时自身也会完成事务提交；

5、follower、observer接收到commit消息后，进行事务提交。

注意：

只要有一个节点commit了proposal，那么就要确保所有节点最终都能正确commit该proposal。

Leader 服务器与每一个 Follower 服务器之间都维护了一个单独的 FIFO 消息队列进行收发消息，使用队列消息可以做到异步解耦。 Leader 和 Follower 之间只需要往队列中发消息即可。如果使用同步的方式会引起阻塞，性能要下降很多。

2、崩溃恢复模式：

当leader崩溃或失去与过半的节点的联系时进入崩溃恢复模式，当半数节点与新master节点状态同步时退出恢复模式。

已经被处理的消息不能丢：已经commit的proposal不会丢，即使只有一台follower commit了。

被丢弃的消息不能再出现：原leader中生成但没有发出去的proposal，或是原leader中发出proposal但是没有过半节点响应ack，没有进入commit阶段，这些消息都需要丢弃。

leader选举算法：zxid大的优先当选leader（zxid大的节点拥有最新的最全的数据），zxid相同的情况下，myid大的当选leader，同时通过epoch判断，所以不会选举到原来的leader。

ZK主要使用场景：

分布式系统的协调机制：

所谓协调是一个最广泛的概念，分布式系统中因为拆分成了很多服务，各个服务都有多个实例，不同的服务的不同实例分布在不同的机器或不同进程上，所以很多时候，需要进行合理的“沟通”，才能决定接下来该怎么做，（我觉得下面讲的注册中心、HA高可用、分布式锁等等都只是所谓“协调”的情况之一而已！），然后各个服务像一个团队一样，在ZK的统一协调下，共同把事情做好做对。就是这样一个思想，这也就是为什么ZK说自己就是一个分布式协调机制的原因。

注册中心：

集群的出现，分布式的出现，导致的问题：

1.服务地址不好维护；

2.可用服务地址的动态感知；

3.负载均衡。

所谓注册中心，其实就是针对服务发现这一功能的配置中心，只不过记录的配置是服务的地址而已，而且是动态配置，会随着服务的状态随时调整配置。

zookeeper分别解决的问题：

1.地址维护：类似DNS的命名服务，一个接口地址对应了多个服务地址（host:ip），利用zookeeper znode tree结构实现。

2.动态感知：服务端与zookeeper通过会话机制，保证了zk上的临时节点的 生/死，然后通过监测该临时节点的生/死，通知到客户端。

3.负载均衡：通过dubbo内的负载均衡算法实现，保证zk的单纯性；同时dubbo会缓存zk服务地址，减少与zk频繁通讯，但是当服务端挂了之后，zk上的临时节点消失会通知到客户端更新缓存；

HA高可用机制：

所谓HA高可用，我理解比较模糊，可能就是Kafka里面的那种leader follower角色，leader负责对外提供读写服务，follower平时什么也不干，当leader挂了之后,follower成为新的leader对外提供服务。

那ZK实现HA高可用机制，也很简单，大概意思说一下：系统A1，系统A2，刚开始他俩都去ZK上创建一个名为active的临时节点，这是系统A1创建成功了，那么系统A1自然就成了leader，系统A2创建active临时节点失败，沦为follower，并监听这个节点。如果系统A1挂了，那么ZK就接收不到心跳，之后系统A2也就收到ZK的监听反馈，去创建active临时节点，创建成功，就成为了新的leader。

分布式锁：

ZK实现分布式锁的方式是通过临时有序节点来实现的。实现锁的方式：临时有序节点 + 监听。

锁实现机制就是：A客户端连接zk后，创建了第一个临时子节点，判断自己是第一个子节点后（获取锁成功）；B客户端连接上来zk之后，创建了第二个临时子节点，判断自己不是第一个子节点（获取锁失败），监听自己的前一个节点（锁等待）；当A客户端处理完相关事情后与zk断开连接，对应的第一个临时子节点消失（锁释放）；第二个子节点监听到该事件，重新去判断自己现在是不是第一个子节点，判断是（获取锁成功）。