分布式中间件-分布式协调服务zookeeper

文章目录

• • 什么是zookeeper?
  • • [ZooKeeper 的特点：](#ZooKeeper 的特点：)
    • [ZooKeeper 的应用场景：](#ZooKeeper 的应用场景：)
    • [ZooKeeper 的架构：](#ZooKeeper 的架构：)
    • [ZooKeeper 的数据模型：](#ZooKeeper 的数据模型：)
    • [ZooKeeper 的安装与部署：](#ZooKeeper 的安装与部署：)
    • 总结：
  • 核心架构
  • • [1. 服务端集群](#1. 服务端集群)
    • • 角色划分：
    • [2. 客户端](#2. 客户端)
    • [3. 数据模型](#3. 数据模型)
    • [4. 协议](#4. 协议)
    • [5. 操作](#5. 操作)
    • [6. 会话（Session）](#6. 会话（Session）)
    • 总结
  • 选主过程
  • • [1. 初始化阶段](#1. 初始化阶段)
    • [2. 投票过程](#2. 投票过程)
    • [3. 接收投票](#3. 接收投票)
    • [4. 判断是否达到过半数](#4. 判断是否达到过半数)
    • [5. Leader选举](#5. Leader选举)
    • [6. 领导者开始工作](#6. 领导者开始工作)
    • 具体细节
    • 总结
  • 服务发现
  • • [1. 注册服务](#1. 注册服务)
    • [2. 发现服务](#2. 发现服务)
    • [3. 获取服务列表](#3. 获取服务列表)
    • [4. 服务调用](#4. 服务调用)
    • 实现示例
    • • 服务提供者（ServiceB）:
      • 服务消费者（ServiceA）:
    • 注意事项
  • 数据一致性
  • • 数据同步过程
    • 数据同步的关键技术
    • • [事务日志（Transaction Log）](#事务日志（Transaction Log）)
      • 快照（Snapshot）
      • [Paxos 变体协议](#Paxos 变体协议)
    • 故障恢复中的数据同步
    • 数据同步的性能考量
    • 总结

什么是zookeeper?

ZooKeeper 是一个分布式协调服务，它为分布式应用程序提供了一套完整的协调服务功能，包括命名服务、状态同步、集群管理、配置维护以及分布式锁等功能。ZooKeeper 的设计目标是简化分布式应用程序的开发工作，使得开发者不需要从头开始实现这些复杂的协调机制。

ZooKeeper 的特点：

1. 一致性：客户端无论连接到哪个Server，看到的数据都是一致的。
2. 无单点故障：任何一台服务器的故障都不会影响客户端的正常访问。
3. 顺序性：来自同一个客户端的请求，按照其发送顺序依次执行。
4. 原子性：更新要么成功，要么失败。
5. 实时性：在一定的时间内，客户端能够看到最新的数据状态。

ZooKeeper 的应用场景：

• 配置中心：存储和管理分布式系统中的配置信息。
• 命名服务：为集群中的服务提供统一的命名，便于服务间的通信。
• 分布式锁：实现多个进程之间的互斥访问。
• 队列管理：实现队列管理中的同步机制。
• 集群管理：监控集群中的成员状态，当有新成员加入或者老成员退出时通知相关方。

ZooKeeper 的架构：

ZooKeeper 采用的是客户端/服务器架构模型，其中包含多个Server节点。每个Server节点都保存了一个数据状态副本，客户端可以连接到任何一个Server节点。当客户端请求写操作时，该请求会被广播给整个Server集群中的大多数节点来完成。

ZooKeeper 的数据模型：

ZooKeeper 提供了一种类似文件系统的API，但它并不用于存储大量数据。相反，它用来存储少量的数据，如配置信息、状态信息等。ZooKeeper 中的数据是以层级结构组织的，称为ZNodes（ZooKeeper 节点），每个ZNode都可以有自己的子节点。

ZooKeeper 的安装与部署：

ZooKeeper 可以单机运行，也可以组成一个集群。集群模式下，ZooKeeper 通过选举机制选出一个Leader节点来协调其他Follower节点的工作。Leader负责接收写请求，并将结果广播给Follower节点，以保证数据的一致性。

总结：

ZooKeeper 是一个非常有用的工具，特别是在构建复杂的分布式系统时。它通过提供一系列协调服务来简化开发者的任务，使得开发者可以专注于业务逻辑而不是底层的协调机制。不过，使用ZooKeeper也需要考虑它的性能和可靠性，尤其是在大规模集群环境中。

核心架构

ZooKeeper 的核心架构是由一组相互协作的服务端（Server）组成的集群，以及一组客户端（Client）共同构成的。为了更好地理解ZooKeeper的核心架构，我们可以从以下几个方面来看：

1. 服务端集群

ZooKeeper 的服务端集群通常由多个Server组成，这些Server共同维护着一个单一的状态。每个Server都有两个网络端口，一个是用于客户端连接的端口，另一个则是用于Server间通信的端口。

角色划分：

• Leader：负责处理客户端的读写请求，并且协调其他Follower节点，保证集群中数据的一致性和及时性。
• Follower：接收来自客户端的请求，转发给Leader处理；同时也会参与Leader选举过程。
• Observer：类似于Follower，但是不参与选举过程，主要用于增加集群的读取吞吐量。

2. 客户端

客户端可以连接到任意一个Server节点，一旦连接建立后，客户端就可以发送请求。客户端与服务端之间保持长连接，以保证交互的实时性和高效性。

3. 数据模型

ZooKeeper 的数据模型是一个层次化的文件系统，称为ZooKeeper命名空间。在这个命名空间中，数据单元被称为ZNode（ZooKeeper Node）。ZNode有两种类型：

• 持久节点（Persistent）：一旦创建就不会自动删除，除非显式删除。
• 临时节点（Ephemeral）：这些节点与创建它们的会话绑定，如果创建它们的客户端断开连接，那么这些节点就会被自动删除。

ZNode还可以进一步细分为普通节点和顺序节点（Sequential）。顺序节点是在创建时自动加上了一个递增的序号，用以标识创建顺序。

4. 协议

ZooKeeper 使用一种称为Zab（ZooKeeper Atomic Broadcast）的协议来保证数据的一致性和线性化。Zab协议有两种模式：

• 选主模式（Leader Election）：用于在集群中选择一个新的Leader。
• 广播模式（Broadcast）：用于在Leader确定之后，向所有Follower广播事务请求。

5. 操作

ZooKeeper 支持一系列的操作来管理ZNode和数据，包括但不限于：

• create：创建一个新的ZNode。
• delete：删除一个ZNode。
• get：获取指定ZNode的数据。
• set：设置指定ZNode的数据。
• exists：检查指定ZNode是否存在。
• setData：设置ZNode的数据。
• getData：获取ZNode的数据。
• getChildren：获取指定ZNode的所有子节点列表。

6. 会话（Session）

客户端与ZooKeeper Server之间的交互是基于会话的。会话的概念是ZooKeeper中特有的，它描述了客户端和服务端之间的一系列交互。每次客户端连接到ZooKeeper集群时都会创建一个新的会话，并且会话具有一定的有效期。

总结

ZooKeeper的核心架构设计旨在为分布式应用程序提供一种可靠的方式来进行状态管理和协调。通过其独特的数据模型和服务端角色分工，ZooKeeper能够在提供高可用性的同时，确保数据的一致性和线性化。

选主过程

ZooKeeper 在启动时会经历一个选主（Leader Election）的过程，以确定哪一台服务器作为Leader来协调集群中的其他成员。选主算法是基于一个称为ZAB（ZooKeeper Atomic Broadcast）协议的变体。以下是详细的选主过程描述：

1. 初始化阶段

当ZooKeeper集群启动时，每台服务器都会进入Looking状态，这意味着它们都在寻找集群中的Leader。

2. 投票过程

每台服务器初始化时会给自己投一票，然后将投票信息（包括当前服务器的ID和认为的最大ID）发送给集群中的其他服务器。投票信息中包含的信息是服务器的ID以及已知的最高ID（即已知的最高候选者ID）。

3. 接收投票

每台服务器都会接收到其他服务器发来的投票信息，并记录下来。服务器会根据收到的投票信息来更新自己的状态。

4. 判断是否达到过半数

每台服务器都会判断自己收到的投票信息是否已经达到了集群中服务器数量的一半以上（即( \lceil N/2 \rceil + 1 )，其中N是服务器总数）。如果某台服务器发现自己收到了足够多的支持票数，那么它就认为自己成为了Leader。

5. Leader选举

如果某台服务器发现自己收到了足够的票数并且成为Leader，它会向其他服务器发送消息，表明自己已经成为Leader。其他服务器接收到这条消息后，会将自己的状态从Looking转变为Follower，并且开始跟随Leader的指示进行工作。

6. 领导者开始工作

一旦Leader被选举出来，它就开始接受来自客户端的请求，并且协调其他Follower节点来保证数据的一致性。

具体细节

• 选举过程中，如果服务器崩溃：如果在选举过程中有服务器崩溃，那么崩溃的服务器将不再参与选举。此时剩下的服务器继续选举，只要剩下的服务器还能满足( \lceil N/2 \rceil + 1 )的要求，选举就可以继续进行。

• 选举过程中，如果出现平局：如果有两组或以上的服务器得到了相同数量的票数，那么暂时没有一方能获得过半数的支持。这时，新的选举轮次会开始，服务器们会重新发起投票，直到有一个明确的获胜者为止。

• 选举过程中，如果出现网络分区：如果网络问题导致集群分裂成多个分区，那么每个分区可能会独立进行选举，这会导致多个Leader的产生。这种情况需要等待网络恢复正常后，再通过重新选举来解决。

总结

ZooKeeper 的选主过程是一个动态的过程，它不仅在集群初始化时进行，而且在网络中断或服务器故障恢复后也会再次进行。这个过程确保了即使在部分服务器故障的情况下，集群也能够继续运作并提供服务。

服务发现

ZooKeeper 可以作为一个强大的服务发现工具，帮助分布式系统中的服务找到彼此。服务发现是指在一个分布式系统中，允许服务消费者自动查找并连接到服务提供者的过程。ZooKeeper 通过其提供的协调服务功能，可以很好地支持服务发现的需求。下面是使用ZooKeeper进行服务发现的基本流程和步骤：

1. 注册服务

当服务提供者启动时，它会在ZooKeeper中创建一个临时节点（Ephemeral Node），这个节点代表了服务提供者本身。由于临时节点是与创建它的客户端会话绑定的，因此如果服务提供者停止运行，对应的临时节点也会被自动删除。这种机制可以确保当服务提供者宕机时，服务发现系统可以及时感知并做出相应的调整。

/path/to/service/{serviceName} -> 创建临时节点

2. 发现服务

服务消费者在启动时，需要在ZooKeeper中注册一个Watcher来监听服务提供者的变更。Watcher是一种异步的通知机制，当服务提供者注册的节点发生变化时（如新增或删除服务提供者），ZooKeeper会通知所有注册了Watcher的服务消费者。

/path/to/service/{serviceName} -> 监听节点变化

3. 获取服务列表

当服务消费者收到服务提供者列表变化的通知后，它可以获取当前服务提供者列表，并从中选择一个或多个服务提供者进行通信。

/path/to/service/{serviceName} -> 获取子节点列表

4. 服务调用

服务消费者通过解析服务提供者的地址信息，直接调用服务提供者提供的服务。

实现示例

假设有一个名为ServiceA的服务，它需要发现并调用名为ServiceB的服务。具体实现可以如下：

服务提供者（ServiceB）:

1. 启动时 ：连接到ZooKeeper，并在/services/b路径下创建一个临时节点，例如/services/b/instance1。
2. 停止时：关闭连接，ZooKeeper会自动删除该临时节点。

服务消费者（ServiceA）:

1. 启动时 ：连接到ZooKeeper，并监听/services/b节点的变化。
2. 收到变化通知后 ：查询/services/b下的所有子节点，获取所有当前在线的服务提供者地址。
3. 调用服务：根据获取到的服务提供者地址，调用相应的服务。

注意事项

• 会话管理：服务提供者和服务消费者都需要维护与ZooKeeper的会话。如果会话超时未续期，ZooKeeper会认为客户端已经离线。
• 负载均衡：服务消费者可以选择轮询、随机选择等方式来分散请求，从而实现负载均衡。
• 容错机制：服务消费者需要实现重试、超时等容错机制，以防止单个服务提供者不可用导致整体服务不可用的情况。

通过ZooKeeper进行服务发现，不仅可以简化服务发现的实现，还能利用其提供的高可用性和一致性保障来增强系统的健壮性。

数据一致性

ZooKeeper 的数据同步是其能够保证分布式环境中数据一致性的关键所在。ZooKeeper 使用 ZAB (ZooKeeper Atomic Broadcast) 协议来实现数据的同步。以下是 ZooKeeper 数据同步的详细过程：

数据同步过程

1. 客户端请求：当客户端向 ZooKeeper 发送写请求时，请求会被发送到 Leader 节点。

2. Leader 广播请求：Leader 节点收到请求后，会将请求转化为一个事务请求，并广播给所有的 Follower 节点。每个事务请求包含一个全局唯一的事务 ID（zxid）。

3. Follower 处理请求：每个 Follower 节点收到请求后，会对请求进行投票。如果多数 Follower 节点（超过半数）确认了这个事务请求，那么这个请求就被认为是被提交的。

4. Leader 记录事务：当 Leader 收到多数 Follower 的确认后，它会记录这个事务，并将事务日志写入磁盘。

5. Follower 记录事务：Follower 节点同样会将确认的事务写入自己的事务日志，并应用到内存状态中。

6. 返回结果给客户端：一旦事务被提交，Leader 就会返回成功响应给客户端。注意，Leader 在返回结果之前就已经确认了事务的一致性。

7. 同步数据状态：所有节点将应用相同的事务序列，以保持数据的一致性。

数据同步的关键技术

事务日志（Transaction Log）

• ZooKeeper 使用事务日志来记录每一个事务的状态。当一个事务被提交后，Leader 和 Follower 会将事务记录写入事务日志中。

快照（Snapshot）

• ZooKeeper 还会定期创建快照，以记录当前的数据状态。快照与事务日志一起，确保了即使发生节点故障，数据也可以被恢复。

Paxos 变体协议

• ZooKeeper 的 ZAB 协议实际上是基于 Paxos 协议的一种变体。Paxos 协议是分布式系统中保证一致性的经典协议之一。

故障恢复中的数据同步

当 ZooKeeper 集群中出现故障时，数据同步仍然需要确保数据的一致性。在这种情况下，ZooKeeper 会执行以下步骤：

1. Leader 选举：当集群中的某个节点失效时，其他节点会重新进行 Leader 选举。

2. 恢复状态：新选举出来的 Leader 会从最近的快照和事务日志中恢复集群状态。

3. 同步状态：Leader 会将恢复后的状态同步给其他 Follower 节点，确保所有节点的状态一致。

数据同步的性能考量

虽然 ZooKeeper 的数据同步机制可以保证数据的一致性，但在实际应用中还需要考虑性能问题。为了提高性能，ZooKeeper 做了一些优化：

• 预写日志（Write-Ahead Logging, WAL）：在内存中修改数据之前先将事务记录写入磁盘的日志中，以防止内存中的数据因故障丢失。
• 多线程处理：Leader 节点可以使用多线程来处理不同的客户端请求，以提高并发处理能力。
• 心跳机制：Leader 会周期性地向 Follower 发送心跳消息，以维持集群的稳定性。

总结

ZooKeeper 的数据同步机制确保了在分布式环境中数据的一致性和可靠性。通过对事务的广播、确认以及最终的写入，ZooKeeper 能够有效地协调集群中的各个节点，使其始终保持一致的状态。此外，通过使用事务日志和快照技术，ZooKeeper 还能够在发生故障时快速恢复集群状态。