1.Windows安装和使用zookeeper

之前整理过一篇文章《zookeeper 分布式锁服务》，本文介绍的 Zookeeper 是以 3.4.5 这个稳定版本为基础，最新的版本可以通过官网 http://hadoop.apache.org/zookeeper/来获取，Zookeeper 的安装非常简单，下面将从单机模式和集群模式两个方面介绍 Zookeeper 的Windows安装和配置.

首先需要安装JdK，从Oracle的Java网站下载，安装很简单，就不再详述。

单机模式

单机安装非常简单，只要获取到 Zookeeper 的压缩包并解压到某个目录如：C:\zookeeper-3.4.5\下，Zookeeper 的启动脚本在 bin 目录下，Windows 下的启动脚本是 zkServer.cmd。

在你执行启动脚本之前，还有几个基本的配置项需要配置一下，Zookeeper 的配置文件在 conf 目录下，这个目录下有 zoo_sample.cfg 和 log4j.properties，你需要做的就是将 zoo_sample.cfg 改名为 zoo.cfg，因为 Zookeeper 在启动时会找这个文件作为默认配置文件。下面详细介绍一下，这个配置文件中各个配置项的意义。

# The number of milliseconds of each tick
tickTime=2000
# The number of ticks that the initial 
# synchronization phase can take
initLimit=10
# The number of ticks that can pass between 
# sending a request and getting an acknowledgement
syncLimit=5
# the directory where the snapshot is stored.
# do not use /tmp for storage, /tmp here is just 
# example sakes.
dataDir=C:\\zookeeper-3.4.5\\data
dataLogDir=C:\\zookeeper-3.4.5\\log
# the port at which the clients will connect
clientPort=2181
#
# Be sure to read the maintenance section of the 
# administrator guide before turning on autopurge.
#
# http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance
#
# The number of snapshots to retain in dataDir
#autopurge.snapRetainCount=3
# Purge task interval in hours
# Set to "0" to disable auto purge feature
#autopurge.purgeInterval=1

tickTime：这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime 时间就会发送一个心跳。
dataDir：顾名思义就是 Zookeeper 保存数据的目录，默认情况下，Zookeeper 将写数据的日志文件也保存在这个目录里。
dataLogDir：顾名思义就是 Zookeeper 保存日志文件的目录
clientPort：这个端口就是客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。

当这些配置项配置好后，你现在就可以启动 Zookeeper 了，启动后要检查 Zookeeper 是否已经在服务，可以通过 netstat – ano 命令查看是否有你配置的 clientPort 端口号在监听服务。

集群模式

Zookeeper 不仅可以单机提供服务，同时也支持多机组成集群来提供服务。实际上 Zookeeper 还支持另外一种伪集群的方式，也就是可以在一台物理机上运行多个 Zookeeper 实例，下面将介绍集群模式的安装和配置。

Zookeeper 的集群模式的安装和配置也不是很复杂，所要做的就是增加几个配置项。集群模式除了上面的三个配置项还要增加下面几个配置项：

initLimit=5
syncLimit=2
server.1=192.168.211.1:2888:3888
server.2=192.168.211.2:2888:3888

- initLimit：这个配置项是用来配置 Zookeeper 接受客户端（这里所说的客户端不是用户连接 Zookeeper 服务器的客户端，而是 Zookeeper 服务器集群中连接到 Leader 的 Follower 服务器）初始化连接时最长能忍受多少个心跳时间间隔数。当已经超过 10 个心跳的时间（也就是 tickTime）长度后 Zookeeper 服务器还没有收到客户端的返回信息，那么表明这个客户端连接失败。总的时间长度就是 5*2000=10 秒
- syncLimit：这个配置项标识 Leader 与 Follower 之间发送消息，请求和应答时间长度，最长不能超过多少个 tickTime 的时间长度，总的时间长度就是 2*2000=4 秒
- server.A=B：C：D：其中 A 是一个数字，表示这个是第几号服务器；B 是这个服务器的 ip 地址；C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口；D 表示的是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式，由于 B 都是一样，所以不同的 Zookeeper 实例通信端口号不能一样，所以要给它们分配不同的端口号。
- 除了修改 zoo.cfg 配置文件，集群模式下还要配置一个文件 myid，这个文件在 dataDir 目录下，这个文件里面就有一个数据就是 A 的值，Zookeeper 启动时会读取这个文件，拿到里面的数据与 zoo.cfg 里面的配置信息比较从而判断到底是那个 server。

数据模型

Zookeeper 会维护一个具有层次关系的数据结构，它非常类似于一个标准的文件系统，如图 1 所示：

Zookeeper 这种数据结构有如下这些特点：

1. 每个子目录项如 NameService 都被称作为 znode，这个 znode 是被它所在的路径唯一标识，如 Server1 这个 znode 的标识为 /NameService/Server1
2. znode 可以有子节点目录，并且每个 znode 可以存储数据，注意 EPHEMERAL 类型的目录节点不能有子节点目录
3. znode 是有版本的，每个 znode 中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据
4. znode 可以是临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个 znode 也将自动删除，Zookeeper 的客户端和服务器通信采用长连接方式，每个客户端和服务器通过心跳来保持连接，这个连接状态称为 session，如果 znode 是临时节点，这个 session 失效，znode 也就删除了
5. znode 的目录名可以自动编号，如 App1 已经存在，再创建的话，将会自动命名为 App2
6. znode 可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是 Zookeeper 的核心特性，Zookeeper 的很多功能都是基于这个特性实现的，后面在典型的应用场景中会有实例介绍

如何使用

Zookeeper 作为一个分布式的服务框架，主要用来解决分布式集群中应用系统的一致性问题，它能提供基于类似于文件系统的目录节点树方式的数据存储，但是 Zookeeper 并不是用来专门存储数据的，它的作用主要是用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理.

通过C#代码使用zookeeper

Zookeeper的使用主要是通过创建其Nuget ZooKeeperNet包下的Zookeeper实例，并且调用其接口方法进行的，主要的操作就是对znode的增删改操作，监听znode的变化以及处理。

参考：Windows安装和使用zookeeper - 张善友 - 博客园

2.使用 RMI + ZooKeeper 实现远程调用框架

在 Java 世界里，有一种技术可以实现“跨虚拟机”的调用，它就是 RMI（Remote Method Invocation，远程方法调用）。例如，服务A 在 JVM1 中运行，服务B 在 JVM2 中运行，服务A 与服务B 可相互进行远程调用，就像调用本地方法一样，这就是 RMI。在分布式系统中，我们使用 RMI 技术可轻松将服务提供者（Service Provider）与服务消费者（Service Consumer）进行分离，充分体现组件之间的弱耦合，系统架构更易于扩展。

参考：3 使用 RMI + ZooKeeper 实现远程调用框架_ZooKeeper教程_田守枝Java技术博客

3.ZooKeeper之（四）配置与命令---建议参考博主写的非常好

Nginx之（一）Nginx是什么_冰河-CSDN博客

4.zookeeper 客户端 zkCli 命令详解

安装 zookeeper
启动/停止 zookeeper
配置文件
zookeeper 命令
zookeeper cli
对 znode 进行增删改查
创建节点 create
列出节点 ls
获取节点信息 get
检查状态 stat
修改节点 set
删除节点 rmr
删除节点 delete
其他指令
历史记录 history
重复之前的命令 redo
是否输出 watch 事件（printwatches）
关闭连接 close
打开连接 connect
退出连接 quit
强制同步 sync
ACL 操作
ACL Permissions
权限相关命令
ACL Schemes
world 方案
IP 方案
auth 方案
digest 方案
创建节点时指定 ACL
zookeeper quota
参考:https://blog.csdn.net/feixiang2039/article/details/79810102

5.Zookeeper学习笔记

（一）znode的概念

znode通过路径被引用，类似linux文件系统的路径。根节点用/表示，其余节点从/开始加上各层节点的名称，如/zoo/duck。但是与文件系统路径不同，znode没有相对路径的概念，每个节点都以绝对路径标识。

znode既可以作为保存数据的容器（如同文件），也可以作为保存其它znode的容器（如目录）。znode除了可以保存数据外（保存的数据不能太大，一个znode存储的数据被限制在1M以内），znode本身就是一个数据结构，其中的信息称为元数据（如创建时间、子节点信息、版本信息、ACL信息等）。

（二）znode的操作

znode支持如下9种基本操作：

create：创建znode
delete：删除znode
exists：测试一个znode是否存在并且查询它的元数据
getChildren：获取一个znode的子节点列表
setACL：设置znode的ACL
getACL：获取znode的ACL
setData：设置znode所保存的数据
getData：获取znode所保存的数据
sync：将客户端的znode视图与zk服务器同步

（三）znode的类型

znode可分为短暂的（或叫临时的）和持久的。所谓短暂znode，是指创建该节点的客户端会话结束后，该节点会被自动删除。而持久znode的生存期与创建它的客户端会话无关，如果要删除，需要显示的执行命令删除。注意，短暂znode不可以有子节点。

顺序znode：指znode的名称中包含顺序号。当我们创建一个顺序znode时，框架会自动在指定的名称之后附加一个单调递增的计数器值（由父节点维护），并且保证这个计数器值是唯一的。注意，顺序znode可以是持久的，或短暂的。

（四）znode的版本信息

znode有版本信息，对于每个znode来说，均存在三个版本号：

dataVersion
数据版本号，每次对节点进行set操作，dataVersion的值都会增加1（即使设置的是相同的数据），初始值为0。
cversion
子节点的版本号。当znode的子节点有变化时，cversion 的值就会增加1，初始值为0。
aclVersion
ACL的版本号。

下面以dataVersion （数据版本号）为例来说明Zk中版本号的作用。每一个znode都有一个数据版本号，它随着每次数据变化而自增。ZooKeeper提供的一些API例如setData和delete根据版本号有条件地执行。多个客户端对同一个znode进行操作时，版本号的使用就会显得尤为重要。例如，假设客户端C1对znode /config写入一些配置信息，如果另一个客户端C2同时更新了这个znode，此时C1的版本号已经过期，C1调用setData一定不会成功。这正是版本机制有效避免了数据更新时出现的先后顺序问题。在这个例子中，C1在写入数据时使用的版本号无法匹配，使得操作失败。因此使用版本号可用来阻止并行操作的不一致性。

（五）znode的ACL列表

每个znode都有一个ACL（权限控制列表），用于决定哪个客户端可以对它执行何种操作，也就是说一种权限控制的方式。 znode的ACL列表可以在创建时指定，也可以后续重新设置。如果不加设置，默认所有客户端可以对znode进行任何操作。关于ACL的更详细信息本文不再介绍。

三、Zk的观察机制

当znode的发生变化时，Zk提供一种观察（watch）机制可以让希望获取这个变化信息的客户端得到通知。当一个客户端对一个节点设置了观察，如果该节点发生变化（如被删除、设置数据、添加/删除子节点等），Zk框架会通知设置了观察的客户端。

注意，节点上设置了观察，当节点发生变化后，只会通知一次。如果想再次获取通知，需要重新设置。

四、Zk的设计思路

在集群环境下，Zk通过复制来实现高可用性，只要集群环境下的超过一半机器处于可用状态，它就能提供服务。比如一个集群有5个节点，任意2台机器出现问题，但因为还有3台机器可用，3台超过1半，所以服务可以继续保证。如果集群是6台节点，也最多只能有2台机器出问题，因为如果有3台机器有问题，则可用的没超过一半，服务也不可用。因此，对于Zk的集群，其节点的数量通常配置为奇数个。

集群中的节点分为两种类型：领导者(leader)和跟随着(flower)。集群中的机器通过一个选择过程来选出领导者，其它的机器就作为跟随者。如果领导者出现故障，其它机器就会选出一个新的领导者。随后，如果之前的领导者恢复，则会成为一个跟随者。

Zk客户端可以连接到任意一台Zk服务器，但是所有的写请求都会被转发给领导者，再由领导者将更新广播给跟随者，当半数以上的跟随者已经将修改持久化之后，领导者才会提交这个更新，然后客户端才会收到一个更新成功的响应。

下面示意图可以简单说明上面描述的内容：

（摘自hadoop权威指南一书）

参考:https://www.jianshu.com/p/42556d349160