ZK是什么？

zookeeper一般被用来提供分布式环境的协调服务（后续简称zk）。zk的设计目标就是将那些复杂且容易出错的分布式一致性服务加以封装，构成高效且可靠的服务，并为用户提供一系列简单易用的接口。
分布式应用程序可以基于它实现：

  • 数据的发布和订阅
  • 负载均衡
  • 命名服务
  • 分布式协调与通知
  • 集群管理
  • 领导选举
  • 分布式锁
  • 分布式队列

zk一般都是以集群的方式对外提供服务，一个集群包含多个角色，每个节点都对应一台zk服务器，所有的节点共同对外提供服务。具体包括以下五大特性：

  1. 顺序性
  2. 原子性
  3. 一致性
  4. 可靠性
  5. 实时性

    内存模型

    zk内部拥有树状内存结构，与Unix文件系统非常类似。在zk中将这些目录和文健系统称为ZNode，每个ZNode都有对应路径及其包含的数据，ZNode可由zk客户端创建。当客户端和服务端建立连接后，服务端将为客户端创建一个Session(会话)，客户端对ZNode的所有操作均在这个会话中来完成。

image.png
ZNode包含4类节点

  • persistent节点（持久节点）
    • 持久节点是zk中最常见的一种节点类型，该数据节点被创建后，就会一直存在于zk服务器上，直到有删除操作来主动清理这个节点。
  • persistent_sequential （持久顺序节点）
    • 持久顺序节点的基本特性和持久节点一致，额外的特性表现在顺序性上，在zk中，每个节点都会为它的第一级子节点维护一份顺序，用于记录下每个子节点创建的先后顺序。基于这个顺序特性，在创建子节点的时候，可以设置这个标记，那么在创建节点过程中，zk会自动为给定节点名加上一个数字后缀，作为一个新的，完整的节点名。另外需要注意的是，这个数字后缀的上限是整型的最大值。
  • ephemeral（临时性节点）
    • 和持久节点不同的是，临时节点的生命周期和客户端的会话绑定在一起，也就是说，如果客户端会话失效，那么这个节点就会被清理掉。这里需要注意的是，客户端会话失效和TCP连接断开是两回事。zk规定了不能基于临时节点来创建子节点，即临时节点只能作为叶子节点。

  • ephemeral sequential(临时性顺序节点)

    • 临时顺序节点的基本特性和临时节点也是一致的，同样是在临时节点的基础上，添加了顺序的特性。

      集群架构

      zk设计了轻量级协议Zab（Zookeeper Atomic Broadcast，Zk广播协议）Zab分为两个阶段：

  • leader election 领导选举

    • zk集群启动时，会选出一台节点为leader，其他节点均为follower，当leader出现故障时，会自动选举出新的leader节点，并让所有节点恢复到一个正常的状态，选举结束后，会进入原子广播阶段。
  • Atomic Broadcase 原子广播
    • 该阶段会同步leader节点与follower节点之间的数据，确保leader与follower节点具有相同的状态。所有的写操作都会发送到leader节点，并通过广播的方式同步到follower节点。

一个zk集群通常由奇数个节点组成，一般情况下，数量是3~5个。每个节点都会在内存中维护当前的服务器状态，并在每个节点之间都会保持通信，目的就是告诉其他节点『自己还活着』。我们一般会提供奇数个节点比较节省资源。此外，zk客户端可以选择集群中任意一个节点来建立连接，而一旦客户端与某个节点之间断开联系，客户端会自动连接到集群的其他节点。

image.png

ZK应用场景

虽然zk有很多应用场景，但是一般情况下，在分布式系统中，常见的使用场景如下：

  • 分布式协调
  • 分布式锁
  • 元数据/配置信息管理
  • HA高可用性

    分布式协调

    这个其实是zk的经典用法，简单来说，就好比，在A系统发送一个请求到mq，之后B系统消费消息之后处理，此时zk可以实现分布式系统之间的协调工作，A系统发送请求之后，可以在zk上对某个节点的值注册一个监听器，一旦B系统处理玩了就修改zk那个节点的值，A系统立马就可以收到通知，完美解决。
    image.png

    分布式锁

    对某一个数据连续发出两个修改操作，两台机器同时收到了请求，但是只能一台机器先执行完另外一台机器才能执行。此时，就可以使用zk分布式锁，一个机器收到了请求之后，先获取zk上的一把分布式锁，就是可以去创建一个ZNode，接着执行操作，然后另外一个机器也尝试去创建那个znode，结果发现自己创建不了，因为被其他机器创建了，只能等待第一个机器执行完毕后，再去执行。（关于分布式锁，后续单开一篇文章进行学习）
    image.png

    元数据/配置信息管理

    zk可以用作很多系统的配置信息的管理，比如kafka，strom等很多分布式系统都会选用zk来做一些元数据，配置信息的管理（比如kafka的offset，dubbo注册中心支持zk）

image.png

HA高可用

这个是很常见的，比如hadoop，hdfs，yarn等很多大数据系统，都选择基于zk来开发高可用机制，就是一个重要系统一般会做一主多备，主服务挂了立马通过zk感知切换到备用服务。
image.png

业界其他的注册中心

说到这个, 先扯一下服务发现, 当我们的服务从单机走向微服务的时候, 就产生了服务发现.
一开始服务发现是通DNS协议实现的, 就是网路IP协议, 通过DNS + LVS基本就实现了http形式的服务发现, 这个时候IP通常是配置在LVS.之后大家开始玩起RPC服务, 服务的部署开始频繁.为了实现动态上下线, 整出来注册中心 目的其实就是推送IP列.

Zookeeper

Zoopkeeper 在国内很长一段时间都是注册中心一哥.大部分是因为Dubbo 在国能的盛行.

Eureka

Eureka是一家在线影片租赁提供商Netflix开源的, 这家公司的理念还是超前的.
很多Spring Cloud的组件都是Netflix做的, 这是Netflix的微服务生态.方便Spring开发人员构建微服务基础框架.而Eureka则借着微服务概念的流行,与SpringCloud生态的深度结合,也获取了大量的粉丝.

Nacos

Nacos 是阿里开源的, 功能其实也很多, 服务注册, 配置管理, 动态 DNS 服务, 元数据管理

比较：
image.png
CAP理论是分布式架构中重要理论

  • 一致性(Consistency) (所有节点在同一时间具有相同的数据)
  • 可用性(Availability) (保证每个请求不管成功或者失败都有响应)
  • 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)

由于C与A的特性无法共存.CAP 不可能都取,只能取其中2个,要么AP要么CP

总结：

  • Nacos大而全
  • Eureka 小而美
  • Consul其实跟Nacos比较相似.
  • zookeeper 性能好难扩展