《ZooKeeper实现分布式的思路》由会员分享，可在线阅读，更多相关《ZooKeeper实现分布式的思路（4页珍藏版）》请在金锄头文库上搜索。
1、ZooKeeper 实现分布式的思路Hadoop 生态系统为开源届提供很多优秀软件，zookeeper 便是其中一员。前段时间项目中用到了 zookeeper，主要是用作服务的注册和发现使用方式类似阿里的dubbo。实际上 zookeeper 的功能不仅仅只有这些内容，它提供了一系列非常方便使用的功能，后面会提到。这篇文章仅仅是我个人的一点儿理解，如有错误烦请指正，以免给别人误导。1、 zookeeper 是什么zookeeper 的名字很有趣被称为动物管理员，这是因为 Hadoop 生态系统中很多软件的名字都是动物，hadoop 本身就是小象的意思，还有 hive 小蜜蜂，pig。zooke
2、eper 作为一个分布式协调系统在 hadhoop 中被广泛的应用，其中 HBase 默认带有 zookeeper。zookeeper 主要功能有配置维护、分布式锁、选举、分布式队列等，并且 zookeeper 本身可以是一个集群，提供了高可用性。这一切的功能都离不开 zookeeper 的数据模型。2、 zookeeper 数据模型zookeeper 提供的命名服务看起来和一个 unix 的文件系统非常相似，下面是从官网复制的一张图：其中的每个节点称为 znode，每个 znode 节点既可以包含数据又可以包含子节点，由于zookeeper 被定位为协调程序因此 znode 中的数据通常存储
3、的是非常小的数据，比如状态信息，位置信息等等。znode 中有一个很重要的概念节点类型， znode 有两种类型的节点：临时节点，永久节点。其中这两种节点又分为有序和无序，重点讲一下临时节点，因为 zk中很多基础的功能都是基于临时节点实现的，client 在和 zookeeper 连接的时候两者之间会建立起 session，session 的状态由 zookeeper 服务端维护，临时节点的特点是随着 session的超时服务端会将 client 建立的所有临时节点移除，而永久节点即使客户端退出节点也不会消失，同时临时节点不能有子节点但是可以挂载数据。结合 watcher 机制可以实现非常丰富
4、和灵活的功能。3、 zookeeper 集群结构zookeeper 本身支持单机部署和集群部署，生产环境建议使用集群部署，因为集群部署不存在单点故障问题，并且 zookeeper 建议部署的节点个数为奇数个，只有超过一半的机器不可用整个 zk 集群才不可用。zookeeper 集群中主要有两个角色 leader 和 flower，每个客户端可以连接集群中的任何一个 zookeeper 节点，同时从其上面 read 信息，但是针对 write操作，flower 节点会转发给 leader，由 leader 负责原子广播，从而保证集群中各个节点的数据一致性，zookeeper 中规定只有当多余一半
5、的节点同步完成整个 write 操作才算完成。也就是说可能会有少于一半的数据不是新数据，因此 zookeeper 中不是强一致性而是实现的最终一致性。但是客户端可以使用 sync 来强制读取最新的数据。4、 replactionzookeeper 中的高可用性是通过数据冗余和实现的，也就是一份数据存在多个节点中，zookeeper 中要求同一份数据需要在超过一半的节点上存在，只有这样才能实现对宕机数量的容忍度更高。zk 建议配置奇数个节点，是因为在 flower 同步数据和进行 leader 选举的时候都要求有超过一半完成或同意才算 ok。举例来说，假如有 3 个节点，至少需要有 2 个节点正
6、常，就是容忍度为 1(允许宕掉的节点数)，有 4 个节点，至少需要有三个节点正常，容忍度同样为 1，多出来一个机器但是容忍度相同在任何时候看来都得不偿失。因此 zk 建议部署奇数个节点，但这不是强制。另外再看一下为什么写操作的时候要求至少有超过一半节点 commit 成功整体才成功，假如有 2t+1 个 zk 节点，也就是必须有 t+1 个节点 commit成功才算成功，因为只有这种情况下才能达成至少有一个节点存有前后两次的更新操作(两次 t+1 节点至少会重复一个)。zookeeper 使用 zab 算法实现数据的原子广播，并且每次write 会写日志然后更新缓存，每个 zk 节点维护一个
7、zxid，zxid 是一个全局变量，随着znode 的每一次改变而递增，当 leader 挂掉的时候，剩余的 flower 选择 zxid 最大的节点作为新的 leader，在新 leader 提供服务前还需要一次数据恢复，新 leader 只是拥有最多的数据，但不一定拥有最新的数据，因此 leader 和 flower 的数据需要同步到最新的状态，通过合并的过程完成整个数据的恢复。上图 5 个 zk 节点允许两个宕机，其他三个节点总是能恢复出来 ABCDE。5、 Watch 机制zookeeper 允许客户端对 znode 节点或者节点中的数据设置监听器，当 znode 改变的时候服务器触发
8、监听，客户端完成一个回调做自己需要处理的逻辑。zookeeper 中的 watch 是一次性的，也就是当监听触发后，需要再次应用 watcher，下次才能在收到变化的通知。exists， getData，getChildren 接口都可以指定是否应用 watcher，可以使用默认的 watcher或者自定义 watcher。触发 watcher 的可以为 create、delete、setData、setACL。6、配置管理如果是单机或者几台机器，当应用的配置项变更的时候，可能通过手动的方式去修改一下，但是假如一个集群中有成百上千个应用节点，如何才能保证快速无差错的完成配置项的变更。zooke
9、eper 的出现可以轻松地解决这个问题每个节点在 zk 上建立永久型 znode 并写入配置项，然后监听该节点下数据的变化，一旦其他客户端修改了其中的数据，所有的监听客户端都会收到变更通知。7、 Leader 选举zookeeper 本身提供 leader 选举机制，大概的思路是所有的节点创建临时有序的 znode 然后监听所有节点的变化情况，获取最小序号和自己创建的序列作比较，如果自己为最小则当选为 leader，当主动删除自己创建的节点或者 leader 宕机后，临时节点消失，该变化会被其他存活的节点获取到从而触发第二次的 leader 选举，依次类推。实际上 zookeeper 提到的很
10、多 recipes curator 都提供了很好的实现( 除了两阶段提交)，同时基于底层的zookeeper api 开发应用需要考虑的东西很多，curator 对这些都提供了封装，所以如果要编写 zookeeper 应用推荐使用 curator。leader 应用的场景很广泛，curator 提供了两种不同的选举实现，一种是轮询做 leader，另外一种是永久获取 leader 权直到退出，两种选举实现可以应用在不同的集群应用中。HBase 中使用的是获取 leader 的永久权【编辑推荐】克服部署挑战，让 Hadoop 和云成为最佳拍档 对象存储系统 vs Hadoop 云存储怎么选？ 能否利用 Hadoop 搭建完整的云计算平台？ 从 HDFS 架构和设计看 Hadoop 和云计算的关系 云平台发现服务构建：为什么不使用 ZooKeeper
