01. 概述

1.1 分布式应用

分布式应用（distributed application）指的是应用程序分布在不同计算机上，通过网络来共同完成一项任务的工作方式。以javaEE实现一个电商网站为例：

• 单体应用：所有功能都写在一个项目了;打包成一个可运行的war包;部署这个war包就可以完成整个网站所有功能。
• 分布式应用：不同的功能写在不同的项目里；打包成多个可运行的war包；由多个运行的服务共同完成整个网站的完整功能。



• 如上图，这个电商网站包含了用户管理、商品管理、订单管理、支付管理4个模块（也称为服务），在分布式应用里面，许多功能都是多个服务共同协作完成的，服务间如何高效有序地协作就成为分布式开发中一个重要的问题。
• 类比：

• 单一应用 --> 所有工作都一个人完成
• 分布式应用 --> 很多工作由多个人共同协作完成

1.2 什么是zookeeper

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它主要是用来解决分布式应用中经常遇到的一些问题。

ZooKeeper从字面意思理解，【Zoo - 动物园，Keeper - 管理员】动物园中有很多种动物，这里的动物就可以比作分布式环境下多种多样的服务，而ZooKeeper做的就是管理这些服务。

1.3 架构

zookeeper的架构如下图所示：

• 读操作，直接读取其中一个Follwer并直接返回，
• 写操作，zookeeper集群会做如下两步处理:

• 这些请求会被发送到Leader节点上
• Leader节点上数据变更会同步到集群中其他的Follower节点

• Leader节点在接收到数据变更请求后，首先将变更写入本地磁盘，以作恢复分布式java应用 基础与实之用。当所有的写请求持久化到磁盘以后，才会将变更应用到内存中。
• 注意:持久化到硬盘的数据，只是用于服务重启时数据恢复。
• 当Leader节点出现故障无法正常相应时，集群会自动重新选举一Follwer节点作为Leader。

1.4 存储结构和分层命名空间

在ZooKeeper中每个命名空间（Namespace）被称为ZNode，你可以这样理解，每个ZNode包含一个路径和与之相关的属性和数据，以及继承自该节点的孩子列表。与传统文件系统不同的是，ZooKeeper中的数据保存在内存中，实现了分布式同步服务的高吞吐和低延迟。

ZNode分类及特性：

1.4.1永久节点和临时节点（Ephemeral）

• 永久节点（默认）：一但创建成功就不会自动消失。
• 临时节点：创建成功后，一但客户端与服务器失去连接，就会自动删除

1.4.2有序节点（Sequence Nodes）

zookeeper支持创建有序节点，也就是在zNode名称后面自动拼接一个递增的数字。

1.4.3节点的更新与监听（watches）

zookeeper客户端可以监听zNode数据的变化,一但zNode的数据发生变化，则自动通知到正在监听的客户端。

02. zookeeper安装及常用指令

一般来讲，单机模式用于本地测试；集群模式用于生产环境；伪集群模式用于对zookeeper集群的学习。

2.1 单机模式

单机模式就是只在一台机器上启动一个zookeeper服务，这种模式配置简单，但是有单点故障问题，只适合在本地调试使用。

部署步骤：

1. 把 zookeeper 的压缩包（zookeeper-3.4.6.tar.gz），解压缩压缩包。

2. 进入zookeeper-3.4.6目录，创建data目录，用于存储参数的数据
3. 进入conf目录 ，把zoo_sample.cfg 复制并重命名为zoo.cfg文件。
4. 打开zoo.cfg文件, 修改data属性：dataDir=…/data
5. 进入Zookeeper的bin目录，双击zkServer.cmd，启动Zookeeper服务，红框中表示端口号为2181

2.2 集群模式（了解）

为了获得可靠的 ZooKeeper 服务，用户应该在一个集群上部署 ZooKeeper 。只要集群上大多数的ZooKeeper 服务启动了，那么总的 ZooKeeper 服务将是可用的。另外，最好使用奇数台机器。 如果 zookeeper拥有 5 台机器，那么它就能处理 2 台机器的故障了。

• 端口说明

• 2181 Client连接的端口，和单机模式相同
• 2888 follower 连接到 leader的端口
• 3888 leader 选举的端口

• myid

• 用来标记集群中当前服务的身份(1~255)

部署步骤

集群模式的部署与单机模式模式类似，只是需要部署到多台机器上 ,再对配置做一些调整。这里以3台机器为例，具体部署步骤如下：

1. 参照单机模式的部署步骤，在3台机器上进行部署
2. 在每个机器的dataDir（zoo.cfg里定义的属性）目录下创建名为myid的文件，并为三台机器上的myid写入不同的数字（1~255）,例如这里三台机器。
   第1台机器myid内容(data/myid):

第2台机器myid内容(data/myid):

讯享网

第3台机器myid内容(data/myid):

注意：myid里的内容是和zoo.cfg里的相对应的

1. 修改每一台机器的配置文件(zoo.cfg)，完整的配置如下：

讯享网

1. 分别启动三台机器上的zookeeper

2.3 伪集群模式

部署步骤:

1. 把 zookeeper 的压缩包（zookeeper-3.4.6.tar.gz），解压缩压缩包。并通过复制得到三个文件夹，为了方便演示，这里命名为zookeeper01、zookeeper02、zookeeper03
2. 分别进入zookeeper安装目录（zookeeper01、zookeeper02、zookeeper03）,创建data目录。
3. 分别进入三个zookeeper的conf目录 ，把zoo_sample.cfg 复制得到zoo.cfg文件。
4. 分别修改三个配置文件，三台机器的配置文件唯一不同的属性就是，其他配置文件都一样。内容如下：
   zookeeper01/config/zoo.cfg

zookeeper02/config/zoo.cfg

zookeeper03/config/zoo.cfg

1. 分别进入三个zookeeper的data目录,创建名为myid的文件，里内容是三个不同的数字（1~255）,要和zook.cfg里的属性相一一对应，用来标记不同的zookeepr节点。
2. 分别启动三个zookeeper服务。

2.4 zookeeper指令

命名学习阶段，使用单机模式即可，

启动客户端，在安装目录下，直接双击zkCli.cmd文件。

2.4.1 查询所有命令（help）

2.4.2 查询节点(ls)

2.4.3 创建节点（create）

2.4.4 查询节点数据(get)

2.4.5 创建有序点(create -s)

2.4.6 创建临时节点(create -e)

• 注意：关闭客户端，再次打开查看 app3节点消失(不是立即消失，需要一点时间)

2.4.7 创建有序临时节点(create -e -s)

2.4.8 修改节点数据(set)

2.4.9 删除节点(delete)

• 当要删除的节点无字节点时

2.4.10 递归删除节点(rmr)

• 当要删除的节点有字节点时

03. zookeeper的JAVA客户端

• Apache Curator（推荐使用）

3.1 初始化项目

用maven管理项目，在pom文件中加入Maven依赖，完整 的pom.xml文件内容如下：

3.1 实战1：ZK节点CRUD操作

• CuratorFramework类是操作zk节点的入口，有以下几个要点：

• CuratorFramework使用fluent风格接口。
• CuratorFramework使用CuratorFrameworkFactory进行分配。 它提供了工厂方法以及构造器创建实例。
• CuratorFramework实例完全是线程安全的。

• 下面是对zk节点增删改查的操作：

• 执行结果如下图所示:

3.2 实战2：zNode监听（watches）

Curator引入了Cache的概念用来实现对ZooKeeper服务器端进行事件监听。共有三种Cache：

• NodeCache 可以监听节点数据变化
• PathChildrenCache 可以监听子节点变化
• TreeCache 可以监听节点及子节点变化

这里以NodeCache为例，写一个监听节点数据变化的例子。代码如下：

运行时打开zkCli.cmd修改的data，再删除节点，更新运行结果如下：

04.zookeeper使用场景

4.1 分布式锁

4.1.1 为什么使用分布式锁

一个方法在高并发情况下的同一时间只能被同一个线程执行，在传统单体应用单机部署的情况下，可以使用Java并发处理相关的API(如ReentrantLcok或synchronized)进行互斥控制。但是，随着业务发展的需要，原单体单机部署的系统被演化成分布式系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题.

4.1.2 基于zookeeper的分布式锁原理

一个分布式锁对应ZooKeeper的一个节点，每个需要获取这个分布式锁的客户端线程在这个节点下创建一个临时有序节点，此时有两种情况：

1. 创建的临时顺序节点是文件夹下的第一个节点，则认为是获取分布式锁成功。
2. 创建的临时顺序节点不是文件夹下的第一个节点，则认为当前锁已经被另一个客户端线程获取，此时需要进入阻塞状态，等待节点顺序中的前一个节点释放锁的时候唤醒当前线程。

4.2 配置中心

对于项目中用到的配置信息（例如数据库地址、用户名、密码……）一般有两种处理方式：

• 直接放到项目配置文件里，会有如下缺点：

• 容易导致敏感信息泄露（例如线上的用户名、密码……）
• 一但配置信息变化（例如数据库密码变化），需要重新打包上线

• 配置中心，将配置信息维护到配置中心里

• 流程：

• 服务启动的时候直接来配置中心获取配置信息
• 配置信息变化时直接修改配置中心里的数据，配置中心将新的配置信息推送给服务(tomcat),无需重启服务。

4.3 注册中心

在生产环境中需要在一个业务服务器（例如tomcat）中调用另一个业务服务器的接口(例如HTTP接口)，那么就需要知道被调用方的IP地址和端口我们有三种方案:

• IP&端口写死在项目里（不推荐）

• 优点：简单直接。
• 缺点：如果被调用方IP地址和端口发生变化或者部署节点的数量发生变化，就需要修改调用方代码重新上线。

• 类比：

• app1–>同学A
• app2–>同学B
• IP+端口–>电话号码
• 调用–>同学A拨打同学B的电话

• 反向代理服务器，例如nginx

• 优点：调用方只需要配置Nginx地址，无需关心被调用用者真实的IP地址和端口。

• 类比：

• nginx --> 班长
• 反向代理服务器转发–>同学A让班长捎话给同学B

• 注册中心,例如zookeeper

• 优点：调用方无需配置被调用方的IP地址，当被调用方的信息变化可以自动更新。
• 流程:

• 注册，app2启动时将IP、端口等信息发送到注册中心
• app1启动时去注册中心拉取app2的信息(IP、端口等信息)
• 发起调用（例如HTTP请求）

• 分布式框架dubbo推荐使用zookeeepr作为注册中心。

• 类比:

• 注册中心 --> 班主任
• 注册 -->所有同学在入学的时候都将手机号告诉班主任
• 拉取目标服务器信息再发起调用–>同学A找班主任要同学B的电话号码再拨打电话

4.4 其他

除了上面列举的三种常见使用场景，zookeeper还可以实现名称服务器、队列、barrier（栅栏）、原子类型、选举等功能,在此不再赘述。