关于zookeeper:Zookeeper学习笔记一基本概念和简单使用

闲扯两句, 个别学习一门新技术我当初会间接看文档，文档上的一些外围观点放到文章中，起因在于我心愿记录我的思考过程，同时也是锤炼本人浏览英文文档的能力。

概述

首先咱们关上 bing 搜索引擎，搜寻 Zookeeper，有同学可能会问，你为什么让关上 bing 搜素引擎，而不是百度呢。那是因为目前在百度搜寻 Zookeeper，第一页没找到官网：

然而你关上 bing 搜寻 Zookeeper:

个人感觉百度的搜寻品质有变差的迹象，所以我最近用 bing 比拟多。

ZooKeeper is a high-performance coordination service for distributed applications. It exposes common services – such as naming, configuration management, synchronization, and group services – in a simple interface so you don’t have to write them from scratch.

Zookeeper 为分布式应用提供高性能协调服务，用简略的接口提供了许多服务，有域名服务、配置管理、分布式同步、组服务。

解读 1: 域名服务、配置管理、分布式同步、组服务这四个似懂非懂.

解读 2 为分布式应用提供了高性能的协调服务，高性能咱们是喜爱的，协调了啥？

再聊聊分布式吧

咱们再来聊聊服务端零碎架构的演进吧，最后的时候咱们的服务只在一台服务器上运行，缓缓的随着用户量的一直晋升，单机部署曾经无奈再满足访问量了。于是人们天然就想到了集群，即雷同的利用再部署一遍，由 Nginx 或其余中间件依据负载平衡算法将申请摊派到集群的机器上。然而为了谋求高牢靠，咱们不能将一个做单机集群，将利用在配置文件中改端口实现集群，然而这并不牢靠，如果这台计算机呈现了什么问题，整个服务都会变得不可用，为了不让鸡蛋放在一个篮子里，维持服务的高牢靠，咱们将服务在多台计算机上，这样就算一台计算机上的服务呈现了问题，服务还是可用的 (当初咱们的服务还是一个单体利用)，这也就是分布式部署，所以分布式并不一定要和微服务挂钩。

然而这又引入了新的问题:

• 一个节点挂掉不能提供服务时如何被集群通晓并由其余节点接替工作

例子: 当数据量与访问量一直回升，单机的 MySQL 无奈再撑持零碎的访问量，咱们开始搭建集群，晋升数据库的拜访能力，为了减少可靠性，咱们多机部署，甚至多地部署。

一般来说增删改耗费的性能远小于查问的性能，所以咱们选若干台数据库节点做写入，对于用户的新增数据申请，会摊派到写节点，写节点写入实现要将这个数据扩散到其余节点, 但这里有一个问题就是如果写节点挂掉呢，那一个自然而然的操作是从从库中再选一个读库回应申请，同时将挂掉的结点从集群中剔除.

• 在分布式的场景下如何保障工作只被执行一次。

例子: 分布式下的定时工作，在计算机 A 和 B 上都部署了服务，如何保障定时工作只执行一次。

这也就是 Zookeeper 的协调。

基本概念与设计指标

在设计指标外面能看到外围概念。

• ZooKeeper is simple. (Zookeeper 是简略的)

ZooKeeper allows distributed processes to coordinate with each other through a shared hierarchical namespace which is organized similarly to a standard file system. The namespace consists of data registers – called znodes, in ZooKeeper parlance – and these are similar to files and directories. Unlike a typical file system, which is designed for storage, ZooKeeper data is kept in-memory, which means ZooKeeper can achieve high throughput and low latency numbers.

Zookeeper 通过相似于文件系统的命名空间来实现对分布式过程的协调，命名空间是由一个一个数据寄存器组成，在 Zookeeper 中它们被称为 znode, ZNode 与文件系统的文件夹是类似的，然而 Zookeeper 抉择将数据保留在内存中，这意味着 Zookeeper 能够实现高吞吐和低提早。

这就是 Zookeeper 的命名空间，像不像 Linux 的文件系统, 一个典型的树结构，其实你也能够类比到 windows 的文件系统，/ 是根目录，这是硬盘，上面是文件夹。像一个文件夹有多个子文件夹一样，一个 znode 也领有多个结点，以 key/value 模式存储数据。Znode 有两种，分为长期节点和永恒节点，节点的类型在创立时被确定，并且不能扭转。长期节点的生命周期依赖于创立它们的会话。一旦会话完结，长期节点将会被主动删除，当然也能够手动删除，长期节点不容许领有子节点。永恒节点的生命周期不依赖于会话，并且只有在客户端显式执行删除操作的时候，能力被删除。Znode 还有一个序列化的个性，如果创立的时候指定的话，该 Znode 的名字前面会主动追加一个递增的序列号。序列号对于此节点的父节点来说是惟一的，这样便会记录每个子节点的创立的先后顺序。

Znode 节点的个性:

1. 兼具文件和目录特点 既像文件一样保护着数据、信息、工夫戳等数据，又像目录一样能够作为门路标识的一部分，并能够具备子 Znode。用户对 Znode 具备增、删、改、查等操作
2. Znode 具备原子性操作 读操作将获取与节点相干的所有数据，写操作也将替换节点的所有数据
3. Znode 存储数据大小有限度 每个 Znode 的数据大小至少 1M，然而惯例应用中应该远小于此值。
4. Znode 通过门路援用，门路必须是相对的。

​

• ZooKeeper is replicated

  Like the distributed processes it coordinates, ZooKeeper itself is intended to be replicated over a set of hosts called an ensemble.

  The servers that make up the ZooKeeper service must all know about each other. They maintain an in-memory image of state, along with a transaction logs and snapshots in a persistent store. As long as a majority of the servers are available, the ZooKeeper service will be available.
  Clients connect to a single ZooKeeper server. The client maintains a TCP connection through which it sends requests, gets responses, gets watch events, and sends heart beats. If the TCP connection to the server breaks, the client will connect to a different server.

  如同被其协调的分布式应用一样，Zookeeper 自身也维持了一致性，集群中的 Zookeeper 同步内存状态、以及长久化的日志和快照，只有大部分的服务器是可用的，那么对应的 Zookeeper 就是可用的。

  客户端连贯到单台 Zookeeper，通过该连贯发送申请、获取响应、获取监听事件并发送心跳，如果客户端的连贯断开，客户端将会连贯到其余的 Zookeeper 上。

• Conditional updates and watches

  ZooKeeper supports the concept of watches. Clients can set a watch on a znode. A watch will be triggered and removed when the znode changes. When a watch is triggered, the client receives a packet saying that the znode has changed.

  Zookeeper 反对监听的概念，客户端能够监听 Znode，当节点被移除或者扭转的时候，会告诉监听的客户端，当节点产生扭转的时候将收到音讯。

小小总结一下

Zookeeper 借助以上个性来实现下面咱们提到的性能个性:

• 域名服务 将 ip 映射为服务名，如果咱们的服务集群中须要相互调用，那么咱们能够抉择将 ip 和域名存储到 Zookeeper 的节点中，在须要调用的时候去用域名来换取到对应的 ip 地址
• 配置管理 动静刷新配置, 基于监听机制，咱们将配置文件存储在 Znode 中，利用监听对应的 Znode，Znode 扭转会将扭转推送给对应的利用。也就是动静刷新配置
• 数据的公布与订阅 同样是基于监听机制

• 分布式锁 不同主机上的过程竞争对立资源，能够借助 Zookeeper 做分布式锁，举一个例子在服务 A 身上配置的有定时工作，咱们集群部署为了保障定时工作 A 只在一台上跑，咱们能够借助分布式锁来实现这个工作。

  为了让咱们让咱们的服务实现更强的吞吐能力和高可用，咱们抉择了分布式部署，然而在计算机的世界里通常是通过某种技术手段解决一个问题，就会引入新的问题，分布式部署的过程中，咱们又遇到了新的问题，比方节点之间的协调 (主从集群中选中 Leader)，资源的竞争问题，为了解决这些问题 Zookeeper 应运而生。

  为什么会将 Zookeeper 的官网文档拎进去呢，因为心愿将本人的学习过程也记录下来，我记得刚学 Java Web 的时候会去 B 站上找视频，然而我看视频的时候有的时候会想，视频作者是怎么得出这个论断的，他们是怎么得出 Zookeeper 能够这么用的，因为我想间接获取第一手的材料，有本人的思考过程。

先装起来

说了这么多，咱们先将 zookeeper 用起来再说。

本次咱们通过在 Linux 下进行装置部署, 国内进入 Zookeeper 官网下载比较慢，咱们通过镜像进行下载:

# 首先在 cd 到 usr 下建 zookeeper 目录，而后在这个目录下建 zk1、zk2、zk3. 咱们本次做集群部署
# zk1 上面执行上面命令 
wget https://mirrors.tuna.tsinghua.edu.cn/apache/zookeeper/zookeeper-3.7.1/apache-zookeeper-3.7.1-bin.tar.gz --no-check-certificate 
# 解压
tar -xzvf apache-zookeeper-3.7.1-bin.tar.gz
# 而后创立 data logs  目录
mkdir data logs
# 将 zk1 上面的所有文件复制到 zk2 zk3 上面一份
cp -r /usr/zookeeper/zk1/*  /usr/zookeeper/zk2/
cp -r /usr/zookeeper/zk1/*  /usr/zookeeper/zk3/
# zk1/data 上面建设 myud 文件，此文件记录节点 id, 每个 zookeeper 节点都须要一个 myid 文件来记录节点在集群中的 id, 此文件只能由一个数字。echo "1" >> /usr/zookeeper/zk1/data/myid
echo "2" >> /usr/zookeeper/zk2/data/myid
echo "3" >> /usr/zookeeper/zk3/data/myid
# 而后进入 apache-zookeeper-3.7.1-bin 的 conf 文件夹上面，将配置文件 zoo_sample.cfg 重名为 zoo.cfg。对该文件进行如下配置
mv zoo_sample.cfg  zoo.cfg
# 退出以下配置 dataDir 存储数据  dataLogDir 存储日志  clientPort 监听端口
dataDir=/usr/zookeeper/zk1/data 
dataLogDir=/usr/ZooKeeper/zk1/logs
clientPort=2181
server.1=127.0.0.1:8881:7771
server.2=127.0.0.1:8882:7772
server.3=127.0.0.1:8883:7773
#集群配置中模版为 server.id=host:port:port，id 是下面 myid 文件中配置的 id；ip 是节点的 ip，第一个 port 是节点之间通信的端口，第二个 port 用于选举 leader 节点
# 第一个编辑完, 咱们用复制指令将这个配置文件复制到 zk2 和 zk3 中。留神要改 clientPort dataDir dataLogDir
 /usr/zookeeper/zk1/apache-zookeeper-3.7.1-bin/bin/zkServer.sh start
 /usr/zookeeper/zk2/apache-zookeeper-3.7.1-bin/bin/zkServer.sh start
 /usr/zookeeper/zk3apache-zookeeper-3.7.1-bin/bin/zkServer.sh start
 # 失常启动会输入 Starting zookeeper ... STARTED 如果不释怀能够用 jps 指令进行监测 

节点的增删改查

像是 Redis 有 Redis Cli 一样，Zookeeper 也有对应的客户端咱们借助这个客户端来实现创立节点操作。

• 永恒节点

# 连贯 zk1
/usr/zookeeper/zk1/apache-zookeeper-3.7.1-bin/bin/zkCli.sh -server 127.0.0.1:2181
# 创立一个节点 dog 是 key 123 是 value
create /dog 123 
# 获取目录中存储的值
get /dog
# 当初连贯 zk2 获取 dog 节点
/usr/zookeeper/zk2/apache-zookeeper-3.7.1-bin/bin/zkCli.sh -server 127.0.0.1:2181
# 获取 dog 目录中存储的值 会发现可能获取的到
get /dog

• 长期节点

  # 连贯 zk1 创立长期节点 -e 代表长期节点
  create -e /dog/cat  123
  # 连贯 zk2 获取 /dog/cat
  get /dog/cat
  # 在 zk1 中输出 quit 指令, 断掉以后会话
  quit
  # 在 zk2 就获取不到了 

• 经典案例基: 基于 Znode 长期程序节点 +Watcher 机制实现偏心分布式锁

​ 原理如下:

申请 A 首先来到 Zookeeper 申请创立长期程序节点，Zookeeper 为申请 A 生成节点，申请 A 查看 lock 目录下本人的序号是否最小，如果是代表加锁胜利，B 监听节点程序值小于本人的节点的变动，如果 A 执行则 B 去获取锁，如果有 C、D 等更多的客户端监听，情理是一样的。

create -s -e /dog/pig  s #在 dog 下创立长期程序节点
# 返回值 Created /dog/pig0000000001 

写在最初

其实 Zookeeper 还有其余性能，如下:

• 数据的公布和订阅
• 服务注册与发现
• 分布式配置核心
• 命名服务
• 分布式锁
• Master 选举
• 负载平衡
• 分布式队列

这里只介绍了根本的概念和利用，心愿会对大家学习 Zookeeper 有所帮忙，放英文正文也是晋升本人浏览英文技术文档的程度。

参考资料

• 从 0 到 1 详解 ZooKeeper 的利用场景及架构 微信公众号 腾讯技术工程
• zookeeper 知识点汇总 https://www.cnblogs.com/reycg…
• zookeeper 入门 https://zookeeper.readthedocs…
• Nginx 负载平衡当其中一台服务器挂掉之后，Nginx 负载将会怎么呢？https://blog.csdn.net/Tomwild…
• 基于 zookeeper 的 MySQL 主主负载平衡的简略实现 https://www.cnblogs.com/TomSn…