命令发送广播_分布式系统架构你必会的 Zookeeper 之基础模块常用命令核心原理集群搭建实战演练（上）...

摘要：

Zookeeper 是什么 ？

它适合那些常见的应用场景 ？

它是如何提供管理服务的 ？

它的核心原理又是什么 ？

它又为何得到大数据应用 Kafka / Hbase / Hadoop 的青睐 ？

它能使你更好的理解集群模式下的架构思维

1. 什么是 Zookeeper ？

1)Zookeeper (文中后续简称 ZK)是一个开源的分布式服务协调系统，最初由雅虎公司开发，后成为 Apache 基金会顶级开源项目。

2)设计 ZK 目的是集中管理纷繁复杂的分布式服务，将其组成一个高效可靠的集群对外提供稳定的服务。

3)ZK 系统服务中间件为我们提供了一系列 API 接口供业务方调用。

2. Zookeeper 常见应用场景

ZK 主要是用来解决分布式系统架构中经常遇到的一些数据管理问题：

• 统一配置管理中心

• 统一命名服务

• 状态同步服务

• 分布式全局唯一 ID

• 集群管理服务

• 分布式同步锁

• 分布式队列等

3. Zookeeper 基础知识

3.1 Zookeeper 管理的集群结构

• 集群服务通过 ZK Client 客户端连接到 ZK 服务器。

• 建立的链接是长链接，因为客户端需要频繁的与 ZK 服务器节点进行点对点的数据交互，这样非常高效。

3.2 ZK 基础模块(一)——文件系统

• 和 Linux 文件系统类似，都是 树状 结构

• 区别是 ZK 中没有文件和目录的区别，统一称为 Znode 节点

• ZK 拥有一个命名空间就像一个精简的文件系统，不同的是它的命名空间中的每个节点拥有它自己或者它下面子节点相关联的数据。ZK 中必须使用绝对路径也就是使用"/"开头。

ZK 节点类型(4 种)如下图所示：

1)持久节点 —— 客户端断开时，节点保留

2)临时节点 —— 客户端断开时，节点删除，不存在子节点

3)持久顺序节点 —— 客户端断开时，节点保留

4)临时顺序节点 —— 客户端断开时，节点删除

备注：顺序节点一般存在持久节点下面，创建的顺序节点是由 ZK 服务器生成的有序递增节点。

3.3 ZK 基础模块(二)——注册监听与通知机制

注册监听 ——> 事件触发图解如下：

客户端注册在 ZK 上，并监听 ZK 上某个 Znode 节点的变化，具体如下所示：

• 被监听的 Znode 是否存在(创建、删除)

• 被监听的 Znode 的数据变化

• 被监听的 Znode 的子节点的变化

4. Zookeeper 常用命令

ZK 的安装可以参考：《分布式系统「全链路日志追踪」实战之 RestTemplate & Feign》的 3.1.2 小节内容。

环境准备：Mac OS + Zookeeper

1)打开 iTerm 2 客户端，输入 zkServer start，启动 ZK 如下：

2)通过 zkCli 连接 Zookeeper Server，如下：

3)Zookeeper 的常用基本命令

增删改查，演示如下：

• ls path 或 ls2 path，其中 ls 列出当前目录下的所有子目录，ls2 会多一些节点相关的状态信息，如下：

• create path data，创建 zk 持久节点 Znode，并存放数据 data，如下：

• create -e path data，创建 zk 临时节点 Znode，并存放数据 data，如下:

• create -s -e path data，创建 zk 临时顺序节点，其中 path 以 / 结尾，如下：

• get path，获取节点 path 上存储的数据，如下：

• set path data，设置节点 path 的数据，如下：

• delete path，删除节点 path，如下：

见上图，删除 /test 节点没有成功，因为该节点下存在临时顺序节点，故无法删除。需将该节点下的临时顺序节点删除完，才能删除该节点，具体操作如下：

• stat path，列出节点path当前状态，即 ls2 = ls + stat

• 上图中，Znode节点的状态含义解释如下：

  • cZxid：创建节点时的事务 ID；

  • ctime：创建节点时的时间；

  • mZxid：最后修改节点时的事务 ID；

  • mtime：最后修改节点时的事务 ID；

  • pZxid：表示该节点的子节点列表最后一次修改的事务 ID，添加子节点或删除子节点就会影响子节点列表，但是修改子节点的数据内容则不会影响该 ID；

  • cversion：子节点版本号，子节点每次修改该版本号加 1；

  • dataVersion：数据版本号，数据每次修改该版本号加 1；

  • aclVersion：权限版本号，权限每次修改该版本号加 1；

  • ephemeralOwner：如果节点为临时节点，那么它的值为这个节点拥有者的 session ID；如果该节点不是 ephemeral 节点, ephemeralOwner 值为 0。

  • dataLength：该节点的数据长度；

  • numChildren：该节点拥有子节点的数量。

注册监听相关的常用命令如下：

• stat path watch：注册监听 Znode，包括新增和删除，注：Znode 可以是一个不存在的节点。

开启 2 个 iTerm 窗口，分别连接 ZK，如下所示：

• get path watch：注册监听 Znode 保存的数据变化。

• ls path watch：注册监听 Znode 下的子节点变化，包括新增和删除

4)常见 zk 基础操作命令如下图所示(help 命令)：

5. Zookeeper 核心原理

5.1 ZK 数据同步机制

• ZK 集群数据同步的核心是原子广播，这一机制保证了各个 ZK Server 之间的数据同步一致性；

• 来自 ZK Client 的读请求，直接由对应的 ZK Server 的本地副本来进行服务的；

• 来自 ZK Client 的写请求，Follower 会把请求转发给 Leader 处理，因为 ZK 要保证每台 Server 的本地副本是一致的，需要通过一致性协议来处理，实现这一机制的协议叫做 Zab 协议。

详见下图所示：

Zookeeper 原子广播

1)Zab 协议简介

Zab 协议是 ZK 为分布式协调服务专门设计的一种支持容错、崩溃、恢复的原子广播协议，是 ZK 保证数据一致性的核心算法。

• Zab 协议需要确保那些已经在 Leader 服务器上提交的事务最终被所有的 Server 都提交

• Zab 协议需要确保丢弃那些只在 Leader 服务器上被提出而没有被提交的事务

2)Zab 协议详解

• ZK Follower Server 收到 Client 的写请求转发给 ZK Leader Server 处理

• Leader 节点先将数据更新持久化到本地

• 然后将此次更新提议(Propose)给所有的 Follower 节点

• Follower 节点接收请求，成功将更新持久化到本地，发送一个 ACK 指令给 Leader

• Leader 节点接收到半数以上的 ACK 指令时，Leader 将广播 Commit 消息本地提交该消息

• 当接收到 Leader 节点发出的 Commit 消息时，Follower 也会提交该消息

详见下图所示：

5.2 Zookeeper Leader 选举

1)选举规则

• ZK Follower Server 节点参与选举-

• Observer 节点不参与选举

• 投票超过半数通过(故 ZK Server 节点个数为奇数最佳)。

2)选举指标

• Serverid 服务器编号 ID(即 myid 存储的值)，该值越大权重越大；
• Zxid 全局事务 ID，该值越大权重越大，优先级大于 Serverid；
• Epoch 逻辑时钟，也称为投票周期，该值越大权重越大，优先级大于 Zxid。

3)图解 zk Leader 选举过程 下面通过 3 个 Zookeeper 服务器 Zk Server-1、Zk Server-2、Zk Server-3 为例，启动顺序依次是Zk Server-1 ——> Zk Server-2 ——> Zk Server-3 ，其中选举参数 (Epoch,Serverid,Zxid)，选举过程如下所示：

在 ZK 集群运行过程中，如果 Follower 节点(Zk Server-3)宕机了，zk 无需重新选举，但是如果 Leader 节点(Zk Server-2)宕机了，那么 zk 服务器需要重新选举，过程如下图所示：

6. Zookeeper 集群搭建

1)ZK 集群是一个主从复制结构，具有高可用、强一致性的协同系统。 2)ZK 集群有三种角色，如下：

• Leader
• Follower
• Observer

3)集群搭建的一般步骤如下：

• 下载 Zookeeper 安装包；

• 解压后进入 conf 目录下，拷贝 mv zoo_sample.cfg zoo.cfg；

• 编辑 vim zoo.cfg；

  ZK 配置文件内容相关解析：

  • tickTime：客户端与服务器或者服务器与服务器之间维持心跳，默认 2000，单位 ms；

  • initLimit：允许 Follower 连接并同步到 Leader 的初始化连接时间，默认是 10 * tickTime；

  • syncLimit：允许 Leader 与 Follower 之间发送消息和应答时间最大限制，默认是 5 * tickTime；

  • dataDir：该属性对应的目录是用来存放myid信息跟一些版本，日志，跟服务器唯一的 ID 信息；

  • clientPort：客户端连接 zk 服务器端口，zookeeper 会监听这个端口，接收客户端的请求访问(端口默认是2181)；

  • server.A=B:C:D

    A：其中 A 是一个数字，表示这个是服务器的 id(也就是 myid 里面的值)

    B：是这个服务器的 ip 地址

    C：zk 服务器之间的通信端口

    D：Leader 选举的端口

• 创建 myid 文件

• 分别启动 Zookeeper 服务器，./zkServer.sh start；

• 查看各个 zk 服务器的角色，zkServer.sh status；

• 登录不同的 zk 服务器，./zkCli.sh

可参考之前写的 GitChat 文章《Zookeeper 与 Solr 集群搭建详细图文教程》，访问网址：

https://gitbook.cn/gitchat/activity/5b000ffb0b9abe23960f1ac1

7. Zookeeper 实战演练

后续内容请关注：《分布式系统架构你必会的 Zookeeper 之基础模块-常用命令-核心原理-集群搭建-实战演练(下)》，敬请期待！ 【备注： 分布式同步锁实现、服务注册与发现实现、分布式系统配置中心案例等。】

加油

# 精彩推荐 #

 分布式系统「全链路日志追踪」实战之 RestTemplate & Feign

 分布式任务调度框架 Elastic-Job 之动态任务发布实现详解

  小白都能看得懂的服务调用链路追踪设计与实现

   事务看完这篇你只能算入门

   微服务架构中你必须了解的 CAP 原理

  趣谈微服务之点-线-面关系

  [三步法] 可视化分析定位线上 JVM 问题

  从 Java 代码如何运行聊到 JVM 和对象的创建-分配-定位-布局-垃圾回收

   记一次生产频繁出现 Full GC 的 GC日志图文详解

 "在看"吗，赶快分享和收藏吧