zookeeper入门系列-概述

转自https://blog.csdn.net/liweisnake/article/details/63251252

 

zookeeper可谓是目前使用最普遍的分布式组件了。其功能和职责单一，但却很是重要。

在现今这个年代，介绍zookeeper的书和文章可谓多如牛毛，本人不才，试图经过本身的理解来介绍zookeeper，但愿经过一个初学者的视角来学习zookeeper，以期让人更加深刻和平稳的理解zookeeper。其中参考了很多教程和书，相关书目列在文末，也感谢这些做者。

学习新的框架，先让咱们搞清楚他是什么，这是它的内涵，而后再介绍它能作什么，这是它的外延，内涵和外延共同来定义框架自己，会对框架有较为深入的理解，在应用层面上知道如何用。其次再搞清楚zookeeper相关的理论基础，其目的是知道zookeeper是如何被发明的，是否可以借鉴以便从此本身可以用到其余地方。最后搞清楚zookeeper中一些设计的原理和细节，目的也是搞清前因后果，学会“术”从而应用到别的地方。固然了，加深的理解一样可以帮助认识zookeeper自己，在使用时才知道为何这样用。

首先，

zookeeper究竟是什么？

zookeeper其实是yahoo开发的，用于分布式中一致性处理的框架。最初其做为研发hadoop时的副产品。因为分布式系统中一致性处理较为困难，其余的分布式系统没有必要 费劲重复造轮子，故随后的分布式系统中大量应用了zookeeper，以致于zookeeper成为了各类分布式系统的基础组件，其地位之重要，可想而知。著名的hadoop，kafka，dubbo 都是基于zookeeper而构建。

要想理解zookeeper究竟是作啥的，那首先得理解清楚，什么是一致性。

所谓的一致性，实际上就是围绕着“看见”来的。谁能看见？可否看见？何时看见？举个例子：淘宝后台卖家，在后台上架一件大促的商品，经过服务器A提交到主数据库，假设刚提交后立马就有用户去经过应用服务器B去从数据库查询该商品，就会出现一个现象，卖家已经更新成功了，然而买家却看不到；而通过一段时间后，主数据库的数据同步到了从数据库，买家就能查到了。

假设卖家更新成功以后买家立马就能看到卖家的更新，则称为强一致性；

若是卖家更新成功后买家不能看到卖家更新的内容，则称为弱一致性；

而卖家更新成功后，买家通过一段时间最终能看到卖家的更新，则称为最终一致性。

更多的一致性例子能够参考文献2，里面列举了10种一致性的例子，若是要给一致性下个定义，能够是分布式系统中状态或数据保持同步和一致。特别须要注意一致性跟事务的区别，能够记得学习数据库时特别强调ACID，故而知足ACID的数据库可以作事务，其中C便是一致性，所以，事务是一致性的一种特例，比起一致性更难达成。

如何保证在分布式环境下数据的最终一致，这个就是zookeeper须要解决的问题。对于这些问题，有哪些挑战，zookeeper又是如何解决这些挑战的，下一篇文章将会主要涉及这个主题。

一些常见的解决一致性问题的方式：

1. 查询重试补偿。对于分布式应用中不肯定的状况，先使用查询接口查询到当前状态，若是当前状态不一致则采用补偿接口对状态进行重试推动，或者回滚接口对业务作回滚。典型的场景如银行跟支付宝之间的交互。支付宝发送一个转帐请求到银行，如一直未收到响应，则能够经过银行的查询接口查询该笔交易的状态，如该笔交易对方未收到，则采起补偿的模式进行推送。

2. 定时任务推送。对于上面的状况，有可能一次推送搞不定，因而须要2次，3次推送。不要怀疑，支付宝内最初掉单率很高，全靠后续不断的定时任务推送增长成功率。

3. TCC。try-confirm-cancel。其实是两阶段协议，第二阶段的能够实现提交操做或是逆操做。

 

zookeeper到底能作什么？

在业界的实际应用是什么？了解这些应用，会对zookeeper可以作的事有更直观的认识。

hadoop：

鼻祖级应用，ResourceManager在整个hadoop中算是单点，为了实现其高可用，分为主备ResourceManager，zookeeper在其中管理整个ResourceManager。

能够想象，主备ResourceManager最初是主RM提供服务，若是一切安好，则zookeeper无用武之地。然而，总归会出现主RM提供不了服务的状况。因而会出现主备切换的状况，而zookeeper正是为主备切换保驾护航。

先来推理一下，主备切换会出现什么问题。传统的主备切换，可让主备之间维持心跳链接，一旦备机发现主机心跳检测不到了，则本身切换为主机，原来的主机等待救援。这种方式有两个问题，一是因为网络抖动，负载过大等问题，备机检测不到心跳并不能说明主机必定挂了，有可能必定时间后主机或网络恢复，这时候主机并不知道备机已经切换为主机，2台主机互相争用，可能形成脑裂；二是若是一些数据集中在主机上面，则备机切换时因为同步延时势必会损失掉一部分的数据。

如何解决这些问题？早期的方式提供了很多解决方案，好比备机一旦切换为主机，则经过电源控制直接切断主机电源，简单粗暴，可是此刻备机已是单点，若是主机是由于量撑不住而挂，那备机有可能会重蹈覆辙，最终致使整个服务不可用。

zookeeper又是如何解决这个问题的呢？

1. zookeeper做为第三方集群参与到主备节点中去，当主备启动时会在zookeeper上竞争建立一个临时锁节点，争用成功者则充当主机，其他备机

2. 全部备机会监听该临时锁节点，一旦主机与zookeeper间session失效，则临时节点被删除

3. 一旦临时节点被删除，备机开始从新申请建立临时锁节点，从新争用为主机;

4. 用zookeeper如何解决脑裂？实际上主机争用到节点后经过对根节点作一个ACL权限控制，则其余抢占的机器因为没法更新临时锁节点，只有放弃成为备机。

zookeeper使用了很是简单又现成的方式来解决的这个问题，比起其余方案方便很多，这也是为啥zookeeper流行的缘由。说白了，就是把复杂操做封装化精简化

 

dubbo：

做为业界知名的分布式soa框架，dubbo的主要的服务注册发现功能即是由zookeeper来提供的。

对于一个服务框架，注册中心是其核心中的核心，虽然暂时挂掉并不会致使整个服务出问题，可是一旦挂掉，总体风险就很高。考虑通常状况，注册中心就是单台机器的时候，其实现很容易，全部机器起来都去注册服务给它，而且全部调用方都跟它保持长链接，一旦服务有变，即经过长链接来通知到调用方。可是当服务集群规模扩大时，这事情就不简单了，单机保持链接数有限，并且容易故障。

做为一个稳定的服务化框架，dubbo能够选择并推荐zookeeper做为注册中心。其底层将zookeeper经常使用的客户端zkclient和curator封装成为ZookeeperClient。

1. 当服务提供者服务启动时，向zookeeper注册一个节点

2. 服务消费者则订阅其父节点的变化，诸如启动中止都可以经过节点建立删除得知，异常状况好比被调用方掉线也能够经过临时节点session 断开自动删除得知

3. 服务消费方同时也会将本身订阅的服务以节点建立的方式放到zookeeper

4. 因而能够获得映射关系，诸如谁提供了服务，谁订阅了谁提供的服务，基于这层关系再作监控，就能轻易得知整个系统状况。

 

zookeeper的基本数据模型

一句话，相似linux文件系统的节点模型

其节点有以下有趣而又重要的特性：

1. 同一时刻多台机器建立同一个节点，只有一个会争抢成功。利用这个特性能够作分布式锁。

2. 临时节点的生命周期与会话一致，会话关闭则临时节点删除。这个特性常常用来作心跳，动态监控，负载等动做

3. 顺序节点保证节点名全局惟一。这个特性能够用来生成分布式环境下的全局自增加id

 

经过zookeeper提供的原语服务，能够对zookeeper能作的事情有个精确和直观的认识

zookeeper提供的原语服务

1. 建立节点。

2. 删除节点

3. 更新节点

4. 获取节点信息

5. 权限控制

6. 事件监听

实际上，就是对节点的增删查改加上权限控制与事件监听，可是经过对这些原语的组合以及不一样场景的使用，能够实现不少用法。参考文献5

1. 数据发布订阅。即注册中心，见上面dubbo用法。主要经过对节点管理作到发布以及事件监听作到订阅

2. 负载均衡。见上面kafka用法

3. 命名服务。zookeeper的节点结构自然支持命名服务，即把信息集中存储，并以树状管理，方便统一查阅

4. 分布式协调通知。协调通知实际上与发布订阅相似，因为引入的第三方的zookeeper，实际上对不少种协调通知作了解耦，好比参考文献4中提到的消息推送，心跳检测等

5. 集群管理与master选举。经过上面的第二点特性，能够轻易得知集群机器存活情况，从而轻松管理集群；经过上面第一点特性，能够作出master争抢。

6. 分布式锁。实际上就是第一点特性的应用。

7. 分布式队列。实际上就是第三点特性的应用。

8. 分布式的并发等待。相似于多线程的join问题，主任务的执行依赖于其余子任务所有执行完毕，在单机多线程里能够用join，可是分布式环境下如何实现呢。利用zookeeper，能够建立一个主任务节点，旗下子任务一旦执行完毕，则在主任务节点下挂一个子任务节点，等节点数量足够，则认为主任务能够开始执行。

能够发现，全部的原语就是zookeeper的基础，而其余的用法总结无非是将原语放到不一样场景下的归类罢了。

 

相信到这里你对zookeeper应该有个初步的了解和大体的印象了。

本系列文章分为：

zookeeper入门系列-概述

zookeeper入门系列-理论基础-分布式事务

zookeeper入门系列-理论基础-paxos协议

zookeeper入门系列-理论基础-zab协议

zookeeper入门系列-理论基础-raft协议

zookeeper入门系列-设计细节

 

参考文献：

保证分布式系统数据一致性的6种方案 http://weibo.com/ttarticle/p/show?id=2309403965965003062676

解决分布式系统的一致性问题，咱们须要了解哪些理论？ http://mp.weixin.qq.com/s/hGnpHfn7a7yxjPBP78i4bg

分布式系统的事务处理  http://coolshell.cn/articles/10910.html

ZooKeeper典型应用场景一览 http://jm.taobao.org/2011/10/08/1232/

zookeeper中的基本概念 http://www.hollischuang.com/archives/1280

zookeeper入门使用 http://www.importnew.com/23025.html