zookeeper底层原理讲解

zookeeper是一个分布式的协调系统协调系统。zookeeper保证了数据在ZK之间数据的事务性的一致性。其中zookeeper提供了分布式的锁服务，用于协调分布式应用程序。zookeeper的应用主要有储存元数据信息和选举机制。例如在hadoop中可以利用zookeeper选取namenode的active状态，可以在znode下储存对应的信息，来决定哪台nameNode是active状态的。在HBase中，zookeeper负责储存region的信息以及Master的选取。在Storm中负责储存数据的元数据信息。

为什么使用zookeeer？

我们知道要写一个分布式应用是非常困难的，主要原因就是局部故障。一个消息通过网络在两个节点之间传递时，网络如果发生故障，发送方并不知道接收方是否接收到了这个消息。也可能在网络故障收到了此消息，也可能没有收到，又或者可能接收方的进程死了。发送方了解情况的唯一方法就是再次连接发送方，并向他进行询问。这就是局部故障：根本不知道操作是否失败。因此，大部分分布式应用需要一个主控、协调控制器来管理物理分布的子进程。目前，大部分应用需要开发私有的协调程序，缺乏一个通用的机制。协调程序的反复编写浪费，且难以形成通用、伸缩性好的协调器。协调服务非常容易出错，并很难从故障中恢复。例如：协调服务很容易处于“脑裂”甚至死锁。Zookeeper的设计目的，是为了减轻分布式应用程序所承担的协调任务。

zookeeper并不能阻止局部故障的发生，以为它的本质就是分布式系统，当然也不会隐藏局部故障。zookeeepr的目的就是提供一些工具集，用来建立安全处理局部故障的分布式引用。
zookeeper是一个分布式小文件系统，并且被设计为高可用性。通过选举算法和集群复制可以避免单点故障，由于是文件系统，因此即使所有的zookeeper节点挂掉也不会影响数据的丢失，只要将重启服务器之后数据又被加载恢复。另外zookeeper的更新是原子性的。也就是说更新不是成功就是失败。通过版本号，zookeeper又实现了更新的乐观锁，当版本号不相符时，则表示需要跟新的节点已经被其他客户端更新过了。而当前的更新操作将全部失败，这些故障zookeeper提供了保障。我们需要做的只是调用API。与此同时，随着分布式应用的的不断深入，需要对集群管理逐步透明化监控集群和作业状态，可以充分利ZK的独有特性。

一、zookeeper概述

1.zookeeper中的角色

在zookeeper集群当中，集群中的服务器角色分为leader和learner，Learner又分为observer和flollwer，具体功能如下：

leader(领导者)

为客户端提供读和写的功能，负责投票的发起和决议，负责系统的状态。
follower（跟随者）为客户端提供读服务，如果是写的服务则转发给leader。在选举过程中进行投票。

observer(观察者)

为客户端提供读服务，如果是写服务就转发个leader。不参与leader的选举投票。也不参与写的过半原则机制。在不影响写的前提下，提高集群读的性能，此角色于zookeeper3.3系列新增的角色。

client（客户端）

连接zookeeper集群的使用者，请求的发起者，独立于zookeeper集群的角色。

2.zookeeper特点

• 一致性
  client客户端无论连接到集群中的哪个视图，展示给它的都是同一个视图。
  可靠性：具有简单、健壮、良好的性能如果一条请求消息被集群中的一台节点接收到，那么这条消息最终会被所有的节点接收到。
• 实时性
  zookeeepr保证客户端在一定的时间间隔内获得结果，包括成功和失败，但是由于网络延迟原因，zookeeper不能保证两台客户端同时得到刚更新的消息。如果都需要最新的消息需要调用sync()接口。
• 等待无关（wait free）
  执行慢的或者失效的client不会干预快速请求的client，没的每个客户端都有等效的。
• 原子性
  更新只能是成功或者失败的。没有中间状态。
• 顺序性
  一台服务器上如果消息a在消息b前发布，那么所有的server上的消息a都是在消息b前发布的。

二、zookeeper工作原理

1.zookeeper的核心是原子广播，这个机制保证了各个server之间的数据同步。实现这个机制的协议是Zab协议，Zab协议有两种分别是恢复模式（选主）和广播模式（同步），当服务器启动或者领导者奔溃之后Zab就进入了恢复模式，当leader领导者选举出来之后且大多数server和leadr完成状态同步之后。恢复模式就关闭了。恢复模式保证了leader和server之间的状态同步。

2.为了保证顺序的一致性。zookeeper采用了递增的事务id(zxid)来标志事务，所有的提议在被提出的时候就加上了zxid，具体实现中是通过64位的数组，高32位是epoch用来表示与leader关系是否改变，每次一个leader选举出来且大多数Server都会产生一个新的epoch,标识当前属于哪个leader的统治时期，低32位是用来用来递增计数。
（zxid（64位数字）=高32+低32位=leader统治时期+计数器）

3.每个server的工作过程中有三种状态
(1)looking,当前server不知道leader是谁？正在搜寻
(2)leading:选举出来的leader
(3)following:leader已经选举出来了，当前server与leader进行同步。当前是server角色是learner学习者。

2.zookeeper的读写机制
zookeeper是由一个server或者多个server组成的。一个集群中zookeeper通过自己的选举投票机制保证只有一个leader和多个follower。每个server保存一分数据副本。全局的数据副本一致，分布式读写。更新请求转发，有leader实时。

session会话

1、客户端通过TCP协议与独立服务器或者一个集群中的某个服务器建立会话连接。
2、会话提供顺序保障，即同一个会话中的请求以FIFO的顺序执行。如果客户端有多个并发会话，FIFO顺序在多个会话之间未必能够保持。
3、如果连接的Server出现问题，在没有超过Timeout时间时，可以连接其他节点。zookeeper客户端透明地转移一个会话到不同的服务器。
4、同一session期内的特性不变
5、当一个会话因某种原因终止，在这个会话期间创建的临时节点将会消失。

Session是由谁来创建的？
Leader：产生一个唯一的session，放到消息队列，让所有server知道
过半机制：保证session创建成功或者失败

数据模型Znode：

znode有两种类型，瞬时的（ephemeral）和持久的（persistent）
znode支持序列SEQUENTIAL：leader
短暂znode的客户端会话结束时，zookeeper会将该短暂znode删除，短暂znode不可以有子节点
持久znode不依赖于客户端会话，只有当客户端明确要删除该持久znode时才会被删除
znode的类型在创建时确定并且之后不能再修改
有序znode节点被分配唯一单调递增的整数。
比如：客户端创建有序znode，路径为/task/task-，则zookeeper为其分配序号1，并追加到znode节点：
/task/task-1。有序znode节点唯一，同时也可根据该序号查看znode创建顺序。
znode有四种形式的目录节点
PERSISTENT
EPHEMERAL
PERSISTENT_SEQUENTIAL
EPHEMERAL_SEQUENTIAL