一 zookeeper介绍
因为要使用kafka，但是不想用kafka自带的，而且考虑到后面别的地方需要使用，比如分布式job，觉得独立的比较好。
zookeeper目前资料一大把，但是一是我需要锻炼写blog的能力，还有就是万一有一些别人没讲到的，给大家带来惊喜，岂不美哉。
zookeeper官方介绍：一个为分布式应用提供分布式协调的服务。
设计目标(Design Goals)
简单: zookeeper 允许通过一个共享层的namespace去相互协调，这个namespace的组织结构很像一个标准的文件系统。namespace是由叫做 znodes的数据项组成。在zookeeper说法中，和文件和文件目录有相似之处。不像一个典型文件系统，被设计用来存储。Zookeeper数据被保存在memory，另一个意思就是它可以实现高的生产力。zookeeper可以被使用在一个大规模分布式系统，而且在一个单元失败还是可以保持运行，在客户端实现了复杂同步能力。
zookeeper复制（ZooKeeper is replicated）
zookeeper通过一一套hosts去复制，名叫ensemble。支撑zookeeper服务的服务器，必须相互可以访问通。在一个持久存储中，他们保留一个在内存中的image状态，和一个事务日志和镜像在一起。
客户端连接一个单个zookeeper服务。客户端维护一个tcp连接，通过它发送请求，得到请求和watch events，和发送心跳包。如果一个tcp连接断掉，客户端将连接另外一个服务。
zookeeper是有秩序的（ZooKeeper is ordered）
zookeeper的每一个印记更新一个数字，反映了全部zookeeper事务的秩序。后面的操作能使用这个秩序去实现高级别的抽象，正如同步。
zookeeper是高速的（ZooKeeper is fast）
在读占优势负载中它是尤其的快。zookeeper应用运行在上千的机器上，而且它工作最好的情况下是读通常比写多，比率是大约10：1
数据模型和命名层（Data model and the hierarchical namespace）
命名空间很像一个独立的文件系统。一个名字是一个被slash（/）分割的路径元素序列。每一个节点在在zookeeper的命名空间中被标志为一个路径来使用
节点和临时节点（Nodes and ephemeral nodes）
不像一个标准的文件系统，每个节点在一个zookeeper命名空间中能有数据关联，这个命名空间同样有子节点。它是像一文件系统允许一个文件也可以是一个目录。（zookeeper被设计去存储协调数据：状态信息，配置，位置信息等，因此存储数据在每一个节点通常是小的，在1byte到kb的范围吧）我们使用term znode去让 我们正在讨论的 的zookeeper数据节点更清楚。
znodes维护一个状体结构，包含了版本号为每一个数据更改，ACL更改，和时间戳去允许缓存验证和协调更新。每次一个znode的数据更改，版本号自增。比如一个实例，，无论何时一个客户端检索数据，它总是接受一个版本的数据。
在一个namespace中存储在每一个节点的数据，是原子的读和写。读获取关联一个znode的全部数据，一个写替换全部数据。每个节点有一个访问控制列表（ACL）限制谁能做那些。
zookeeper也有一个临时node的概念。这些znodes与创建这些znodes的session存在一样久。如果session结束，znode就删除。
协调更新和watches（Conditional updates and watches）
zookeeper支持watches的思想。客户端能设置一个watch在一个znodes。znode更改的时候，一个watch将被triggered和移除。一个watch被激发，客户端接收一个packet，说znode已经更改。然后如果在一个服务到客户端的连接被破坏，客户端将接受一个本地通知。
Guarantees
zookeeper是一个非常快和非常简单的，自从它的目标，虽然，是计划作为一个基本为一个更复杂服务结构，正如同步。它实现一套保证。
1 时序一致，从一个客户端的更新被应用在一个先来后到的秩序上
2 原子，更新或者成功，或者失败
3 单个系统image，不管服务连接的是那个服务器，对客户端来说看到的都是相同景象。
4 可靠，一旦一个更新已经被应用，它将持续从那个时间直到一个客户端覆盖更新它。
5 及时，客户端系统的面貌被担保是在某个时间界限中是最新的。
Simple API
create 创建一个znode
delete 删除一个node
exists 测试一个node是否在一个位置存在
get 从一个node读取数据
set 写一个data去一个node
get children 检索一个node的子项的列表
sync 等待数据去被传播
实现（Implementation）
zookeeper组件展示zookeeper服务的较高层面的成分。每一个组成zookeeper服务的服务器复制它自己每一个componets的copy。
复制数据库是一个内存数据库，包含整个数据树。更新记录日志在硬盘为了恢复。然后写是序列化到硬盘，在他们应用到内存前。
每一个zookeeper服务器服务客户端。客户端准确连接到一个服务器去提交请求。读请求从每个服务器数据库的本地复制中提供服务，写请求被一个一致性协议处理，
从客户端的全部写请求一致性协议部分，被趋向一个单个的服务器，名叫leader。其余的，叫followers，从leader接受消息提议和商定传递消息。消息层处理失败替换leader和同步followers和leaders。
二 zookeeper使用
下载：http://mirrors.shu.edu.cn/apache/zookeeper/zookeeper-3.4.13/
wget http://mirrors.shu.edu.cn/apache/zookeeper/zookeeper-3.4.13/zookeeper-3.4.13.tar.gz
看看目录:
首先看配置文件conf/zoo.cfg:
tickTime=2000 dataDir=/var/lib/zookeeper clientPort=2181
- tickTime
- 微妙为基本单位，它被使用作为heartbeats和最低限度的session超时，超市将是两次ticktime。
- dataDir
- 存储内存数据库镜像，除非指定了其他，对数据库更新的事务日志
- clientPort
-
监听端口
我们创建一个cfg文件，然后将上面的配置写入，然后现在可以启动:
然后去连接：
bin/zkCli.sh -server 127.0.0.1:2181
这样的结果证明连接成功
使用help去查询命令：
命令自己去玩吧，这个必须实践，接下来去看看zookeeper的复制
Running Replicated ZooKeeper
运行zookeeper在一个单独的模式下对于开发测试是很方便的，但是生产环境，你是运行在一个复制mode下的，一个服务器复制组在相同的应用，叫做quorum，而且再复制模式，全部服务器在quorum有相同的配置文件。
注意：对于复制模式，需要最少3个服务器，强烈推荐服务器数量是奇数。
下面是复制模式的配置：
tickTime=2000 dataDir=/var/lib/zookeeper clientPort=2181 initLimit=5 syncLimit=2 server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888
initLimit：新的入口，是用于针对过时，zookeeper用来限制在quorum去连接一个leader的时间长度。
syncLimit：限制一个服务从一个leader多大的成都过时。
如果你指定了一个tickTime，在如上例子中，那么超时就是10秒。
而正server.x，当服务启动，它知道那个服务被查找文件myid在data目录。那个文件包含这服务的编号。