zookeeper

zookeeper简介

• ZooKeeper是一个分布式的，开源的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。
• 它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
• ZooKeeper：提供通用的分布式锁服务，用以协调分布式应用。
• Keepalived 监控节点不好管理，采用优先级监控没有协同工作；功能单一；可扩展性差

zookeeper 运用场景

这里请看博客其他文章

zookeeper的角色

1. 领导者（leader），负责进行投票的发起和决议，更新系统状态。
2. 学习者（learner），包括跟随者（follower）和观察者（observer），
3. follower用于接受客户端请求并想客户端返回结果，在选主过程中参与投票。
4. Observer可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度。
   Zookeeper需保证高可用和强一致性；
   为了支持更多的客户端，需要增加更多Server；
   Server增多，投票阶段延迟增大，影响性能；
   权衡伸缩性和高吞吐率，引入Observer
   Observer不参与投票；
   Observers接受客户端的连接，并将写请求转发给leader节点；
   加入更多Observer节点，提高伸缩性，同时不影响吞吐率。
5. 客户端（client），是请求发起方。

zookeeper的特点

1. 最终一致性：为客户端展示同一个视图，这是zookeeper里面一个非常重要的功能
2. 可靠性：如果消息被到一台服务器接受，那么它将被所有的服务器接受
3. 实时性：Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口
4. 独立性：各个Client之间互不干预
5. 原子性：更新只能成功或者失败，没有中间状态
6. 顺序性：所有Server，同一消息发布顺序一致

zookeeper安装配置

官网：https://zookeeper.apache.org/doc/trunk/zookeeperStarted.html

1. 下载安装包并解压
2. 配置zoo.cfg文件

• tickTime=2000 发送心跳的间隔时间，单位：毫秒
• dataDir=/opt/data
• dataLogDir=/Users/zdandljb/zookeeper/dataLog
• clientPort=2181 户端连接 Zookeeper 服务器的端口，
• Zookeeper 会监听这个端口，接受客户端的访问请求。
• initLimit=5
• syncLimit=2
• server.1=node01:2888:3888
• server.2=node02:2888:3888
• server.3=node03:2888:3888
• initLimit： 这个配置项是用来配置 Zookeeper 接受客户端（这里所说的客户端是 Zookeeper 服务器集群中连接到 Leader 的 Follower 服务器）初始化连接时最长能忍受多少个心跳时间间隔数。当已经超过 5 个心跳的时间（也就是 tickTime）长度后 Zookeeper 服务器还没有收到客户端的返回信息，那么表明这个客户端连接失败。总的时间长度就是 5*2000=10 秒
• syncLimit：这个配置项标识 Leader 与 Follower 之间发送消息，请求和应答时间长度，最长不能超过多少个 tickTime 的心跳时间长度，总的时间长度就是 2*2000=4 秒
• server.A=B：C：D：其 中 A 是一个数字，表示这个是第几号服务器；B 是这个服务器的 ip 地址；C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口；D 表示的是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式，由于 B 都是一样，所以不同的 Zookeeper 实例通信端口号不能一样，所以要给它们分配不同的端口号

3. 创建myid文件，server1机器的内容为：1，server2机器的内容为：2，server3机器的内容为：3
4. 在conf目录下创建一个配置文件zoo.cfg
5. 复制到其他zk节点

深入zookeeper原理，大话paxos算法

• 先说 Paxos，它是一个基于消息传递的一致性算法，Leslie Lamport 在 1990 年提出，近几年被广泛应用于分布式计算中，Google 的 Chubby，Apache 的 Zookeeper 都是基于它的理论来实现的，Paxos 还被认为是到目前为止唯一的分布式一致性算法，其它的算法都是 Paxos的改进或简化。有个问题要提一下，Paxos 有一个前提：没有拜占庭将军问题。就是说 Paxos只有在一个可信的计算环境中才能成立，这个环境是不会被入侵所破坏的。

• 关于 Paxos 的具体描述可以在 Wiki 中找到：http://zh.wikipedia.org/zh-cn/Paxos 算法。网上关于 Paxos 分析的文章也很多。这里希望用最简单的方式加以描述并建立起 Paxos 和 ZKServer 的对应关系。

• Paxos 描述了这样一个场景，有一个叫做 Paxos 的小岛(Island)上面住了一批居民，岛上面所有的事情由一些特殊的人决定，他们叫做议员(Senator)。议员的总数(Senator Count)是确定的，不能更改。岛上每次环境事务的变更都需要通过一个提议(Proposal)，每个提议都有一个编号(PID)，这个编号是一直增长的，不能倒退。每个提议都需要超过半数((Senator Count)/2+1)的议员同意才能生效。每个议员只会同意大于当前编号的提议，包括已生效的和未生效的。如果议员收到小于等于当前编号的提议，他会拒绝，并告知对方：你的提议已经有人提过了。这里的当前编号是每个议员在自己记事本上面记录的编号，他不断更新这个编号。整个议会不能保证所有议员记事本上的编号总是相同的。现在议会有一个目标：保证所有的议员对于提议都能达成一致的看法。

• 好，现在议会开始运作，所有议员一开始记事本上面记录的编号都是 0。有一个议员发了一个提议：将电费设定为 1 元/度。他首先看了一下记事本，嗯，当前提议编号是 0，那么我的这个提议的编号就是 1，于是他给所有议员发消息：1 号提议，设定电费 1 元/度。其他议员收到消息以后查了一下记事本，哦，当前提议编号是 0，这个提议可接受，于是他记录下这个提议并回复：我接受你的 1 号提议，同时他在记事本上记录：当前提议编号为 1。发起提议的议员收到了超过半数的回复，立即给所有人发通知：1 号提议生效！收到的议员会修改他的记事本，将 1 好提议由记录改成正式的法令，当有人问他电费为多少时，他会查看法令并告诉对方：1 元/度。

• 现在看冲突的解决：假设总共有三个议员 S1-S3，S1 和 S2 同时发起了一个提议:1 号提议，设定电费。S1 想设为 1 元/度, S2 想设为 2 元/度。结果 S3 先收到了 S1 的提议，于是他做了和前面同样的操作。紧接着他又收到了 S2 的提议，结果他一查记事本，咦，这个提议的编号小于等于我的当前编号 1，于是他拒绝了这个提议：对不起，这个提议先前提过了。于是 S2 的提议被拒绝，S1 正式发布了提议: 1 号提议生效。S2 向 S1 或者 S3 打听并更新了 1号法令的内容，然后他可以选择继续发起 2 号提议。

• 好，Paxos 的精华就这么多内容。现在让我们来对号入座，看看在 ZK Server 里面 Paxos是如何得以贯彻实施的。

  小岛(Island)——ZK Server Cluster
  议员(Senator)——ZK Server
  提议(Proposal)——ZNode Change(Create/Delete/SetData…)
  提议编号(PID)——Zxid(ZooKeeper Transaction Id)
  正式法令——所有 ZNode 及其数据

• 貌似关键的概念都能一一对应上，但是等一下，Paxos 岛上的议员应该是人人平等的吧，而 ZK Server 好像有一个 Leader 的概念。没错，其实 Leader 的概念也应该属于 Paxos 范畴的。如果议员人人平等，在某种情况下会由于提议的冲突而产生一个“活锁”（所谓活锁我的理解是大家都没有死，都在动，但是一直解决不了冲突问题）。Paxos 的作者 Lamport 在他的文章”The Part-Time Parliament“中阐述了这个问题并给出了解决方案——在所有议员中设立一个总统，只有总统有权发出提议，如果议员有自己的提议，必须发给总统并由总统来提出。好，我们又多了一个角色：总统。

  总统——ZK Server Leader

  又一个问题产生了，总统怎么选出来的？
  现在我们假设总统已经选好了，下面看看 ZK Server 是怎么实施的。

  情况一：

  屁民甲(Client)到某个议员(ZK Server)那里询问(Get)某条法令的情况(ZNode 的数据)，议员毫不犹豫的拿出他的记事本(local storage)，查阅法令并告诉他结果，同时声明：我的数据不一定是最新的。你想要最新的数据？没问题，等着，等我找总统 Sync 一下再告诉你。

  情况二：

  屁民乙(Client)到某个议员(ZK Server)那里要求政府归还欠他的一万元钱，议员让他在办公室等着，自己将问题反映给了总统，总统询问所有议员的意见，多数议员表示欠屁民的钱一定要还，于是总统发表声明，从国库中拿出一万元还债，国库总资产由 100 万变成 99 万。屁民乙拿到钱回去了(Client 函数返回)。

  情况三：

  总统突然挂了，议员接二连三的发现联系不上总统，于是各自发表声明，推选新的总统，总统大选期间政府停业，拒绝屁民的请求。

• 到此为止，当然还有很多其他的情况，但这些情况总是能在 Paxos 的算法中找到原型并加以解决。这也正是我们认为 Paxos 是 Zookeeper 的灵魂的原因。当然 ZK Server 还有很多属于自己特性的东西：Session, Watcher，Version 等等等等，需要我们花更多的时间去研究和学习。

zookeeper的节点及工作原理

1. 工作原理：

• 每个Server在内存中存储了一份数据；
• Zookeeper启动时，将从实例中选举一个leader（Paxos协议）
• Leader负责处理数据更新等操作
• 一个更新操作成功，当且仅当大多数Server在内存中成功修改数据

Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。
Zab协议有两种模式，它们分别是恢复模式和广播模式。
当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。一旦leader已经和多数的follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个server加入zookeeper服务中，它会在恢复模式下启动，发现leader，并和leader进行状态同步。待到同步结束，它也参与消息广播。Zookeeper服务一直维持在Broadcast状态，直到leader崩溃了或者leader失去了大部分的followers支持.
广播模式需要保证proposal被按顺序处理，因此zk采用了递增的事务id号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch。低32位是个递增计数。
当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的server都恢复到一个正确的状态。

2. Znode节点

• Znode有两种类型，短暂的（ephemeral）和持久的（persistent）
• Znode的类型在创建时确定并且之后不能再修改
• 短暂znode的客户端会话结束时，zookeeper会将该短暂znode删除，短暂znode不可以有子节点
• 持久znode不依赖于客户端会话，只有当客户端明确要删除该持久znode时才会被删除
• Znode有四种形式的目录节点
  PERSISTENT、持久的
  EPHEMERAL、短暂的
  PERSISTENT_SEQUENTIAL、持久且有序的
  EPHEMERAL_SEQUENTIAL 短暂且有序的

zookeeper方法及RMI实现（理解）

1. Zookeeper的方法（API）：
   
   观察者（watcher）
   

总结

Zookeeper 作为 Hadoop 项目中的一个子项目，是Hadoop 集群管理的一个必不可少的模块，它主要用来控制集群中的数据，如它管理 Hadoop 集群中的NameNode，还有 Hbase 中 Master、 Server 之间状态同步等。
Zoopkeeper 提供了一套很好的分布式集群管理的机制，就是它这种基于层次型的目录树的数据结构，并对树中的节点进行有效管理，从而可以设计出多种多样的分布式的数据管理模型。