Zookeeper简介

搬砖俱乐部

发布于 2019-11-01 15:12:14

9150

发布于 2019-11-01 15:12:14

文章被收录于专栏：BanzClub

“Zookeeper是一个开源的，为了解决分布式应用协调的服务，具有低延迟、高可用等特点。”

Zookeeper提供了构建分布式系统基础的协调服务，比如，提供一致性，顺序执行，持久性。使得我们在开发分布式应用时，可以更加关注应用的业务实现，而依赖Zookeeper来实现分布式系统的一致性问题。这样，客户端只需要通过Zookeeper提供的API来操作业务中需要保证分布式一致性的数据。

在解决分布式系统的问题时，有很多解决方案，包括两阶段提交、三阶段提交，还有比较经典的Paxos算法，Zookeeper使用的是ZAB（Zookeeper Atomic Broadcast）协议，它使用的是Fast-Paxos算法的思想，通过选举出一个Leader，只有Leader才能进行提交提案，避免了Paxos算法存在的活锁问题。

Zookeeper是Apache Hadoop的一个子项目，很多开源的分布式项目都是基于Zookeeper实现，包括HBase、Hadoop、Kafka等。

—

Zookeeper数据结构简介

Zookeeper提供了树形的数据模型，类似于文件系统的目录结构，在数据模型中，每个Path被称为数据节点ZNode。每个ZNode上可以存储数据，也可以在包含子节点，也就构建成一个层次化的命名空间，类似于树。

节点类型包括持久节点、临时节点、持久顺序节点、临时顺序节点。

持久节点是指被创建之后，会一直存在Zookeeper服务器端，直到被删除掉；
临时节点的生命周期与会话绑定到一起，也就是创建临时节点的会话失效，节点就会被清理掉；
持久顺序节点和持久节点一样，特殊的是，在创建持久顺序节点时，会自动在节点名称上增加一个数字后缀，表示节点创建的先后；
临时顺序节点和临时节点特性一样，也增加了类似于持久顺序节点的顺序特性；

我们可以通过命令行来创建、修改、获取、删除Zookeeper的节点数据。

我们创建节点时需要设置节点的内容，其实，zookeeper除了存储数据内容之外，还包括节点本身的状态信息。各个节点属性说明如下：

我们不仅可以通过zkClient在服务器上操作zookeeper的节点，还可以使用zookeeper提供的api来操作。当然，目前应用比较广泛的客户端api是Apache提供的Curator，比原生的api更加易用，解决了很多客户端常见的问题，包括：循环监听、断线重连等。

—

Zookeeper工作原理

Zookeeper分为单机模式和集群模式，绝大多数实际应用场景都是集群模式，集群中的节点包括Leader、Follower和Observer三种角色，Leader是集群的主节点，也就是Master，Leader节点可以提供读和写服务；Follower和Observer是集群的从节点，提供读服务，Follower和Observer的区别在于，Observer节点不能参与选举过程，也不参与写操作的“过半写成功”的策略。

Zookeeper集群的读操作，客户端与集群中任意服务器节点连接，通过Client Api进行读操作即可。

Zookeeper集群的写操作则比较复杂，客户端与集群中任意节点连接，当客户端进行写操作时，Follower会将写请求转发到Leader，Leader将消息封装为一次提案，广播给所有Follower，过半数的Follower同意该提议，会给Leader一个ACK，Leader再广播一个commit提案，Leader会在本地做一次事务的提交，收到commit的Follower也会各自进行一次事务的提交。则与客户端连接的节点，响应客户端完成了一次写操作。

Zookeeper集群对外服务，需保证集群有Leader节点的存在，但分布式系统的特点就是集群中的节点可能会因为故障而出现问题，这就需要分布式系统有故障恢复的能力。

Zookeeper集群中的节点通常包含四种状态：

LOOKING：寻找Leader状态，处于该状态需要进入选举流程；

LEADING：领导者状态，表明当前角色为Leader；

FOLLOWING：跟随者，Leader已经选举出来，表明当前服务角色为Follower；

OBSERVER：观察者状态, 表明当前服务角色为Observer；

集群正常服务时，集群的节点应该处于leading、following、observer状态，当Leader节点挂了，则集群中的Follower节点将进入looking状态，集群进入崩溃恢复模式，此时集群不对外提供服务。集群的崩溃恢复模式也就是重新选主的过程，这时集群需要根据投票确定新的Leader，当某个节点的选票超过半数，则会确立该节点为新Leader，其他节点会变为Follower状态。此时Follower需要同步Leader的数据，当集群状态都一致了，集群才可以继续对外提供读和写服务。

下面再通过ZAB协议算法来重新了解一下Zookeeper的工作原理，ZAB协议主要包括消息广播和崩溃恢复两个过程，这里进一步细分为发现、同步、广播三个阶段：

阶段一（发现）：主要就是Leader选举的过程。

Follower将自己最后的事务 Proposal 的 epoch 值，发送给准 Leader；
准 Leader 生成新的 epoch 值，广播给 Follower；
接收到新的 epoch 值的 Follower，如果当前 epoch 小于新的 epoch（是否存在大于情况？），将自己的 epoch 更新，并给 Leader 发送 ACK；
Leader 收到过半的 ACK 后，选择一个 Follower 进行初始化工作；

阶段二（同步）：在完成发现过程之后，将进入同步阶段。

Leader 将新Leader 信息广播给所有集合中的 Follower；
Follower 收到新Leader 消息后，如果，epoch 等于该消息，则进行同步工作，并给 Leader 发送 ACK；如果小于该消息，则进行上一轮的同步，本轮数据对于她来说太超前了，之前的活还没有干完；
Leader 收到过半的 ACK后，向所有 Follower 发送 Commit 消息；
Follower 收到 Commit 消息，提交为提交的事务，完成同步；

阶段三（广播）：当集群正常工作状态（写操作）时，就是广播阶段。