zookeeper

1、谈一谈你对分布式应用的理解

概念：

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

单体应用：

所有功能都写在一个项目了;打包成一个可运行的war包;部署这个war包就可以完成整个网站所有功能

分布式应用：

不同的功能写在不同的项目里；打包成多个可运行的war包；由多个运行的服务共同完成整个网站的完整功能

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JcXKWpH4-1639100659790)(img/6.png)]

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

2、什么是分布式？什么是集群？

分布式：一组计算机为了共同完成业务功能通过网络协作的多节点系统。把系统按照模块拆分成多个子系统(做不同的事)
集群：同一个工程部署到多台服务器上(做相同的事)

3、什么是zookeeper

引出：

​ 拆分成分布式后有多个模块，模块之间是不是需要进行管理？

概念：

	ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它主要是用来解决分布式应用中经常遇到的一些问题。
	ZooKeeper从字面意思理解，【Zoo - 动物园，Keeper - 管理员】动物园中有很多种动物，这里的动物就可以比作分布式环境下多种多样的服务，而ZooKeeper做的就是管理这些服务。

架构：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fTh8YIrF-1639100659792)(img/7.png)]

​ ZooKeeper集群由一组Server节点组成，这一组Server节点中存在一个角色为Leader的节点，其他节点都为Follower。关于zookeeper架构有如下几个要点：

1、读操作，直接读取其中一个Follwer并直接返回（集群嘛，数据都一样）
2、写操作，zookeeper集群会做如下两步处理:
- 这些请求会被发送到Leader节点上
- Leader节点上数据变更会同步到集群中其他的Follower节点
3、Leader节点在接收到数据变更请求后，首先将变更写入本地磁盘，以作恢复之用。当所有的写请求持久化到磁盘以后，才会将变更应用到内存中。
   注意：持久化到硬盘的数据，只是用于服务重启时数据恢复
4、当Leader节点出现故障无法正常相应时，集群会自动重新选举一Follwer节点作为Leader

4、zookeeper的存储结构和分层命名空间

​ ZooKeeper有一个分层的命名空间，结构类似文件系统的目录结构，非常简单而直观。其中，ZNode是最重要的概念

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-q7I7My2d-1639100659793)(img/8.png)]

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

ZNode分类及特性：

1、永久节点和临时节点（Ephemeral）

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

2、有序节点**（**Sequence Nodes）

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

3、节点的更新与监听（watches）

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

5、zookeeper的三种使用方式

zookeeper的部署分为单机模式、集群模式和伪集群模式。

一般来讲：

• 单机模式用于本地测试；
• 集群模式用于生产环境；
• 伪集群模式用于对zookeeper集群的学习

集群一般是公司中的运维负责搭建

6、zookeeper 怎么保证主从节点的状态同步

	zookeeper 的核心是原子广播，这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 zab 协议。 zab 协议有两种模式，分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，zab 就进入了恢复模式，当领导者被选举出来，且大多数 server 完成了和 leader 的状态同步以后，恢复模式就结束了。状态同步保证了 leader 和 server 具有相同的系统状态。

7、说一下 zookeeper 的通知机制

	客户端端会对某个 znode 建立一个 watcher 事件，当该 znode 发生变化时，这些客户端会收到 zookeeper 的通知，然后客户端可以根据 znode 变化来做出业务上的改变。

8、zookeeper的使用场景都有哪些

咱们学的是只有注册中心该应用场景，其它的场景也需要大家知道，因为面试时面试官可能会问你zookeeper的其他应用场景

1、注册中心

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

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

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

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

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

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

• 注册中心,例如zookeeper

  • 优点：调用方无需配置被调用方的IP地址，当被调用方的信息变化可以自动更新。
  • 流程:
    • 注册，app2启动时将IP、端口等信息发送到注册中心
    • app1启动时去注册中心拉取app2的信息(IP、端口等信息)
    • 发起调用（例如HTTP请求）
  • 分布式框架dubbo推荐使用zookeeepr作为注册中心。

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eKPB2vPk-1639100659794)(img/9.png)]

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

2、分布式锁

为什么使用分布式锁：

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JW0Atpfx-1639100659795)(img/10.png)]

基于zookeeper的分布式锁原理：

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VcovjntU-1639100659796)(img/11.png)]

3、配置中心

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

• 直接放到项目配置文件里，会有如下缺点：
  • 容易导致敏感信息泄露（例如线上的用户名、密码……）
  • 一但配置信息变化（例如数据库密码变化），需要重新打包上线
• 配置中心，将配置信息维护到配置中心里
  • 流程：
    • 服务启动的时候直接来配置中心获取配置信息
    • 配置信息变化时直接修改配置中心里的数据，配置中心将新的配置信息推送给服务(tomcat),无需重启服务。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XLmrHqEq-1639100659797)(img/12.png)]

9、zookeeper 宕机与dubbo 直连的情况

	在实际生产中，假如zookeeper 注册中心宕掉，一段时间内服务消费方还是能够调用提供方的服务的，实际上它使用的本地缓存进行通讯，这只是dubbo 健壮性的一种体现。

10、Zookeeper队列管理（文件系统、通知机制）

两种类型的队列：

1、同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。

2、队列按照 FIFO 方式进行入队和出队操作。 第一类，在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。 第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。在特定的目录下创建PERSISTENT_SEQUENTIAL节点，创建成功时Watcher通知等待的队列，队列删除序列号最小的节点用以消费。此场景下Zookeeper的znode用于消息存储，znode存储的数据就是消息队列中的消息内容，SEQUENTIAL序列号就是消息的编号，按序取出即可。由于创建的节点是持久化的，所以不必担心队列消息的丢失问题

11、zookeeper的数据复制

Zookeeper作为一个集群提供一致的数据服务，自然，它要在所有机器间做数据复制。

数据复制的好处：

1、容错：一个节点出错，不致于让整个系统停止工作，别的节点可以接管它的工作； 
2、提高系统的扩展能力 ：把负载分布到多个节点上，或者增加节点来提高系统的负载能力； 
3、提高性能：让客户端本地访问就近的节点，提高用户访问速度。

12、Zookeeper工作原理

Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。
Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。
当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

13、Zookeeper 下 Server工作状态

每个Server在工作过程中有三种状态：

• LOOKING：当前Server不知道leader是谁，正在搜寻
• LEADING：当前Server即为选举出来的leader
• FOLLOWING：leader已经选举出来，当前Server与之同步

14、机器中为什么会有leader？

​ 在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行，其他的机器可以共享这个结果，这样可以大大减少重复计算，提高性能，于是就需要进行leader选举。

15、zk节点宕机如何处理

	Zookeeper本身也是集群，推荐配置不少于3个服务器。Zookeeper自身也要保证当一个节点宕机时，其他节点会继续提供服务。 如果是一个Follower宕机，还有2台服务器提供访问，因为Zookeeper上的数据是有多个副本的，数据并不会丢失； 如果是一个Leader宕机，Zookeeper会选举出新的Leader。 ZK集群的机制是只要超过半数的节点正常，集群就能正常提供服务。只有在ZK节点挂得太多，只剩一半或不到一半节点能工作，集群才失效。 所以 3个节点的cluster可以挂掉1个节点(leader可以得到2票>1.5) 2个节点的cluster就不能挂掉任何1个节点了(leader可以得到1票<=1)

问，因为Zookeeper上的数据是有多个副本的，数据并不会丢失； 如果是一个Leader宕机，Zookeeper会选举出新的Leader。 ZK集群的机制是只要超过半数的节点正常，集群就能正常提供服务。只有在ZK节点挂得太多，只剩一半或不到一半节点能工作，集群才失效。 所以 3个节点的cluster可以挂掉1个节点(leader可以得到2票>1.5) 2个节点的cluster就不能挂掉任何1个节点了(leader可以得到1票<=1)