哈哈，相信很多朋友都看过很多篇标题这样的“这么说吧，xxx很简单，其实就是个xxx，是作为xxx用的”入门好文章，好了，废话不多说，今天来讲讲zookeeper 。喜欢的朋友可以收藏关注。

先一句话概括下zookeeper：zookeeper可谓是目前使用最广泛的分布式组件了。其功能和职责单一，但却非常重要。

一、zookeeper到底是什么？（技术文）

1）zookeeper实际上是yahoo开发的，用于分布式中一致性处理的框架。

2）背景介绍：最初其作为研发Hadoop时的副产品。由于分布式系统中一致性处理较为困难，其他的分布式系统没有必要 费劲重复造轮子，故随后的分布式系统中大量应用了zookeeper。故随后的大部分分布式系统中大量应用了zookeeper，以至于zookeeper成为了各种分布式系统的基础组件，其地位之重要，可想而知。（类比下之前学习过的netty，netty是对 socket 网络编程的优秀包装，是一个通讯组件框架。不了解netty的可以先收藏本文，再花五分钟学习下这么说吧,Netty很简单，其实就是个Jar包，是作为通讯组件用的）

3 ) 具体应用场景：著名的hadoop、kafka、dubbo 都是基于zookeeper而构建。

4）好处：保证在分布式环境下数据的最终一致性，这个就是zookeeper能解决的问题。

5）上面提到了很多次一致性，那么究竟什么是一致性，给大家补充下这个概念：

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

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

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

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

6）再补充一些常见的解决一致性问题的方式：

1. 查询重试补偿。对于分布式应用中不确定的情况，先使用查询接口查询到当前状态，如果当前状态不一致则采用补偿接口对状态进行重试推进，或者回滚接口对业务做回滚。典型的场景如银行跟支付宝之间的交互。支付宝发送一个转账请求到银行，如一直未收到响应，则可以通过银行的查询接口查询该笔交易的状态，如该笔交易对方未收到，则采取补偿的模式进行推送。

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

3. TCC。try-confirm-cancel。实际上是两阶段协议，第二阶段的可以实现提交操作或是逆操作。

7）zookeeper到底能做什么？前面提到hadoop、kafka、dubbo 都是基于zookeeper而构建，这里，我就以dubbo来具体阐述zookeeper。（真真技术文）

作为业界知名的分布式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. 事件监听

实际上，就是对节点的增删查改加上权限控制与事件监听，但是通过对这些原语的组合以及不同场景的使用，可以实现很多用法。

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

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

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

4. 分布式协调通知。协调通知实际上与发布订阅类似，由于引入的第三方的zookeeper，实际上对很多种协调通知做了解耦。

5. 集群管理与master选举。通过上面的第二点特性，可以轻易得知集群机器存活状况，从而轻松管理集群；通过上面第一点特性，可以做出master争抢。

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

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

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

可以发现，所有的原语就是zookeeper的基础，而其他的用法总结无非是将原语放到不同场景下的归类罢了。

今天，zookeeper的入门教程就到这里。相信到这里你对zookeeper应该有个初步的了解和大致的印象了。本头条号内有多个专题，如【数据结构】、【netty专题】、【dubbo专题】、【mysql优化专题】、【redis专题】、【高并发专题】等优质好文，适合3-5年（12-18k）经验的程序员阅读,头条大屌们可关注后静下心来查看专题文章。