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

作为一个稳定的办事化框架，dubbo可以选择并推荐zookeeper作为注册中间。其底层将zookeeper常用的客户端zkclient和curator封装成为ZookeeperClient。

1. 

   zookeeper到底是什么？（技巧文）

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

   2）背景介绍：最初其作为研发Hadoop时的副产品。因为分布式体系一一致性处理较为艰苦，其他的分布式体系没有须要 费劲反复造轮子，故随后的分布式体系中大年夜量应用了zookeeper。故随后的大年夜部疏分布式体系中大年夜量应用了zookeeper，以至于zookeeper成为了各类分布式体系的基本组件，其地位之重要，可想而知。（类比下之前进修过的netty，netty是对 socket 收集编程的优良包装，是一个通信组件框架。不懂得netty的可以先收藏本文，再花五分钟进修下这么说吧,Netty很简单，其实就是个Jar包，是作为通信组件用的）

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

   更新节点

2. 4）好处：包管在分布式情况下数据的最终一致性，这个就是zookeeper能解决的问题。

   5）膳绫擎提到了很多次一致性，那么毕竟什么是一致性，给大年夜家弥补下这个概念：

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

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

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

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

   

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

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

   1. 准时义务推送。对于膳绫擎的情况，有可能一次推送搞不定，于是须要2次，3次推送。不要困惑，付出宝内最初掉落单率很高，妒攀赖后续赓续的准时义务推送增长成功率。

   2. 萌芽重试补偿。对于分布式应用中不肯定的情况，先应用萌芽接口萌芽到当缁ご态，如不雅当缁ご态不一致则采取补偿接口对状况进行重试推动，或者回滚接口对营业做回滚。典范的场景如银行跟付出宝之间的交互。付出宝发送一个转账请求到银行，如一向未收到响应，则可以经由过程银行的萌芽接口萌芽该笔交易的状况，如该笔交易对方未收到，则采取补偿的模式进行推送。

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

   作为业界有名的分布式SOA框架，dubbo的重要的办事注册发明功能就是由zookeeper来供给的。

   对于一个办事框架，注册中间是其核心中的核心，固然临时挂掉落并不会导致全部办事出问题，然则一旦挂掉落，整体风险就很高。推敲一般情况，注册中间就是单台机械的时刻，其实现很轻易，所有机械起来都去注册办事给它，并且所有调用方都跟它保持长连接，一旦办事有变，即经由过程长连接来通知到调用方。然则当办事集群范围扩大年夜时，这工作就不简单了，单机保持连接数有限，并且轻易故障。

   办事花费者则订阅其父节点的变更，诸如启动停止都可以或许经由过程节点创建删除得知，异常情况比如被调用方掉落线也可以经由过程临时节点session 断开主动删除得知；

3. 办事花费方同时也会将本身订阅的办事以节点创建的方法放到zookeeper；

4. 于是可以获得映射关系，诸如谁供给了办事，谁订阅了谁供给的办事，基于这层关系袈滟做监控，就能随便马虎得知全部体系情况。

zookeeper的根本数据模型（技巧好文）：

一句话，类似Linux文件体系的节点模型

负载均衡。见膳绫擎kafka用法。