前言：终于到分布式篇，前面把JAVA的一些核心知识复习了一遍，也是一个JAVA程序员最基本要掌握的知识点，接下来分布式的知识点算是互联网行业的JAVA程序员必备的技能；
概念:ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是谷歌的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等
关键词：分布式，一致性服务
讲得通俗一点，zookeeper的诞生就是为了解决分布式一致性的问题。
什么是分布式一致性？
分布式：分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器，处理更多的数据。
一致性：指对每个节点一个数据的更新，整个集群都知道更新，并且是一致的 ；
PS：通俗一点以前一台服务器支撑一个系统的模式升级为多台服务器（多个容器）去支撑一个系统，这样这个系统的并发、容灾等各方面的能力将得到大大提升（传统的ngix和集群也能做到），分布式和集群最大的一个区别是分布式的节点都是不同业务（比如账号系统，订单系统，物流系统，商品系统各自部署在不同服务器上）这样做的好处是可以根据不同模块的特性合理地分配资源（比如账号系统访问量很大，需要部署3-5台机器，而物流系统的访问量较小，只需要部署1-2台服务器即可），一致性就是虽然账号系统部署了3台服务器，对于client而言是透明的（订单系统调用账号系统的服务，不用知道调用的哪台服务器上的系统， 结果每次都能得到幂等），那么如何保证每次都能得到这个幂等结果？也就是zookeeper的要解决的问题
基本架构图
角色：
群首（leader）： Leader作为整个ZooKeeper集群的主节点，负责响应所有对ZooKeeper状态变更的请求；
追随者（follower）：除了响应本服务器上的读请求外（exists，getData，getChildren等只读请求），follower还要处理leader的提议，并在leader提交该提议时在本地也进行提交
观察者（observer）：Observer和Follower比较相似，只有一些小区别：首先observer不参加选举也不响应提议；其次是observer不需要将事务持久化到磁盘，一旦observer被重启，需要从leader重新同步整个名字空间。
整个zookeeper集群只有这3种角色，可以看到leader只有一个，所有对数据变更的请求都需要有leader去调度（leader会向所有节点发送原子广播，收到一半以上的节点都同意的消息后才真正提交这个事务），所以leader这个节点相当重要，那如何确立这个learder呢？
答案是选举，zookeeper采用选举的方式确立leader（触发选举的场景分为2种，一种是服务器初始化启动时候，还有一种是服务器运行期间无法和Leader保持连接）
讲解选举过程前先需要了解几个名词
electionEpoch：每执行一次leader选举，electionEpoch就会自增，用来标记leader选举的轮次
peerEpoch：每次leader选举完成之后，都会选举出一个新的peerEpoch，用来标记事务请求所属的轮次
zxid：事务请求的唯一标记，由leader服务器负责进行分配。由2部分构成，高32位是上述的peerEpoch，低32位是请求的计数，从0开始。所以由zxid我们就可以知道该请求是哪个轮次的，并且是该轮次的第几个请求。
lastProcessedZxid：最后一次commit的事务请求的zxid
选举过程（第一次部署）：假设当前有3台服务器（server0，server1，server3）部署zk ，依次启动，第一次投票时候每台服务器都会把票投给自己，投票信息包含自身节点id和事务id zxid，第一次server0投出（0,0），server1投出（1,0）server2投出（2,0）
每个节点投完自己的票之后会接收其他服务器的投票信息，server0接到server1的投票（1,0）,因为
==============================================未完待续=======================================
