zookeeper相关总结

1. ZooKeeper 的架构

ZooKeeper 采用主从架构（Leader-Follower 模型），包括以下组件：

• Leader：负责处理所有写请求和协调事务一致性。
• Follower：处理读请求并转发写请求给 Leader。参与 Leader 选举和事务提交过程。
• Observer：只处理读请求，不参与写请求的投票和事务提交，主要用于扩展读取吞吐量。

2. ZAB 协议（ZooKeeper Atomic Broadcast）

ZooKeeper 使用 ZAB 协议来保证事务的一致性和容错性。ZAB 协议包括两个主要阶段：

2.1 恢复阶段

在这个阶段，ZooKeeper 集群会进行 Leader 选举，并确保系统中的所有节点都达成一致的初始状态。具体步骤如下：

• Leader 选举：当 ZooKeeper 集群启动或现有 Leader 失效时，系统会进行 Leader 选举。节点会相互通信，选出具有最大 zxid 的节点作为新的 Leader。
• 同步状态：新 Leader 会将其最新的状态同步到所有 Follower 节点，确保所有节点的数据状态一致。

2.2 广播阶段

在这个阶段，Leader 处理客户端的写请求，并将这些请求以事务的形式广播给所有 Follower 节点。具体步骤如下：

• 事务提议：Leader 收到写请求后，生成一个事务提议（proposal），并分配一个唯一的 zxid。
• 提议广播：Leader 将事务提议广播给所有 Follower 节点。
• 事务确认：Follower 节点接收到提议后，记录到本地日志，并向 Leader 发送确认（ACK）。
• 事务提交：当 Leader 收到多数 Follower 节点的确认后，提交事务，并将提交消息广播给所有 Follower 节点。
• 数据应用：所有节点按照 zxid 的顺序应用事务变更，更新本地数据状态。

3. 数据一致性

ZooKeeper 保证数据的一致性，通过以下机制实现：

• 原子广播：ZAB 协议确保所有节点以相同的顺序处理事务，保证数据的一致性。
• 多数确认：写操作需要得到多数节点的确认才能提交，避免单点故障导致的数据不一致。
• 数据同步：Leader 选举过程中，新 Leader 会将最新的数据状态同步给所有 Follower，确保数据一致。

4. Session 和 Watch

4.1 Session

客户端与 ZooKeeper 集群之间通过会话（Session）进行通信。每个会话都有一个唯一的会话 ID 和超时时间。在会话期间，客户端可以发送请求和接收响应。当会话失效（如客户端崩溃或网络中断）时，与该会话相关的临时节点会被自动删除。

4.2 Watch

ZooKeeper 提供了 watch 机制，允许客户端在 znode 上设置观察器，以便在数据发生变化时接收通知。watch 是一次性触发的，触发后需要重新设置。

5. ZooKeeper 的一致性模型

ZooKeeper 提供线性一致性和顺序一致性：

• 线性一致性：所有写请求在整个集群中按照严格的顺序进行处理，确保所有节点在同一时刻具有相同的数据状态。
• 顺序一致性：所有写请求按接收的顺序进行处理，读请求可能会返回旧数据，但保证读操作的顺序。

6. 实际应用中的 ZooKeeper

ZooKeeper 被广泛应用于分布式系统中，主要用于以下场景：

• 配置管理：存储和管理分布式系统的配置信息，确保所有节点读取一致的配置信息。
• 命名服务：提供分布式系统中唯一的命名服务，确保资源的唯一性。
• 分布式锁：通过临时节点实现分布式锁，确保多个客户端之间的互斥访问。
• 领导者选举：通过临时顺序节点实现领导者选举，确保分布式系统中唯一的领导者。

总结

ZooKeeper 通过主从架构、ZAB 协议、Session 和 Watch 机制，实现了高可用、强一致性的分布式协调服务。它在分布式系统中起到了关键作用，为配置管理、命名服务、分布式锁和领导者选举等场景提供了可靠的解决方案。

6 Zookeeper的节点

ooKeeper 提供了两种主要的节点类型：临时节点（Ephemeral Znode）和永久节点（Persistent Znode），它们各自有不同的用途和适用场景。

临时节点（Ephemeral Znode）

特点：

• 当创建临时节点的客户端会话结束（例如客户端崩溃或主动关闭），节点会被自动删除。
• 临时节点不能拥有子节点，即不能创建子节点。

适用场景：

• 会话状态管理：例如在分布式系统中，客户端可以创建临时节点来表示自己的在线状态或工作状态。当客户端会话结束时，对应的临时节点会自动删除，用于动态管理和监控客户端的在线状态。
• 分布式锁：使用临时节点实现分布式锁时，锁的持有和释放与客户端的会话状态绑定，确保在客户端会话结束时自动释放锁

永久节点（Persistent Znode）

特点：

• 永久节点在创建后会一直存在，直到明确被删除。
• 永久节点可以拥有子节点，可以作为一个持久的目录结构来组织和存储数据。

适用场景：

• 配置管理：存储和管理分布式系统的配置信息，例如数据库连接信息、系统参数等。
• 命名服务：提供分布式系统中唯一的命名服务，例如服务注册和发现中的节点注册。
• 状态信息：存储和展示系统的状态信息，例如集群节点的运行状态、统计信息等。

1 Zookeeper的工作原理

ZooKeeper 的核心是原子广播，这个机制保证了各个 Server 之间的同步。实现这个机制的协议叫做 Zab 协议。Zab 协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。

Zab协议是为分布式协调服务Zookeeper专门设计的一种 支持崩溃恢复 的 原子广播协议 ，是Zookeeper保证数据一致性的核心算法。Zab借鉴了Paxos算法，但又不像Paxos那样，是一种通用的分布式一致性算法。它是特别为Zookeeper设计的支持崩溃恢复的原子广播协议。

基于该协议，zk实现了一种主备模型（即Leader和Follower模型）的系统架构来保证集群中各个副本之间数据的一致性。

这里的主备系统架构模型，就是指只有一台客户端（Leader）负责处理外部的写事务请求，然后Leader客户端将数据同步到其他Follower节点。

zab协议分为消息广播和崩溃恢复两种模式。

崩溃模式

Leader和Folower以一定间隔进行心跳连接，当超过一半的Follower与Leader失去联系，则认为Leader失效，zookeeper集群进入崩溃恢复模式。

崩溃恢复主要包括两部分：Leader选举 和 数据恢复。

恢复模式主要处理节点故障和leader选举。当leader节点出现故障或新的leader被选举出来时，系统进入恢复模式。恢复模式的主要步骤包括：

1. 选举新的leader：通过选举算法选择一个新的leader节点。
2. 数据同步：新选出的leader从follower节点中收集最新的数据状态，并将这些状态同步到所有的follower节点。
3. 确认同步完成：当所有follower节点与leader节点的数据状态一致后，系统退出恢复模式，进入广播模式。

广播模式

消息广播主要是针对写请求。

zookeeper客户端会随机连接到zookeeper集群中的某个节点，如果是读请求，就直接从当前节点中读取数据；如果是写请求，那么节点就会向 Leader 发送写请求，由Leader依赖zab协议处理。

zab协议对于写操作的处理有些类似于分布式事务的两阶段提交。

在两阶段提交里，写操作分为投票（prepare）阶段和提交（commit）阶段。当一个写请求到达时，协调中心会将请求发给所有的参与者，如果所有的参与者都写入成功，那么就提交这个写请求，反之，只要有一个参与者写入失败就会回滚。在所有的参与者返回结果之前，协调中心会一直阻塞，耗时比较久。

zab协议在此基础上做了修改：将节点角色分为leader和follower，只需要半数以上的follower写入成功即可。

广播模式主要处理正常情况下的数据同步。在广播模式下，所有的写请求都首先发送到leader节点，leader节点会将这些请求以事务的形式广播给所有的follower节点。广播模式的主要步骤包括：

1. 事务提议：leader节点接收到写请求后，生成一个事务提议（Proposal），并将其广播给所有的follower节点。
2. 事务确认：follower节点接收到事务提议后，写入本地日志，并发送确认（ACK）给leader节点。
3. 事务提交：leader节点收到大多数follower节点的确认后，将事务提交，并再次广播提交消息（Commit）给所有的follower节点。
4. 事务应用：follower节点接收到提交消息后，将事务应用到本地数据状态。

2 ZooKeeper 的 CP 特性

1. 一致性（Consistency）：

   • ZooKeeper 确保在任何时刻，所有节点的数据都是一致的。每次写操作必须得到集群中多数节点的确认才能提交，保证了数据的强一致性。
   • ZAB 协议（ZooKeeper Atomic Broadcast）通过事务日志和数据快照机制，确保所有节点的数据状态一致。

2. 分区容忍性（Partition Tolerance）：

   • ZooKeeper 能够容忍网络分区，保证集群在部分节点失联或网络故障时继续运行。
   • 在发生网络分区时，只有包含多数节点的分区能够选举出新的 Leader 并继续处理写请求，防止数据不一致。

 1）ZooKeeper中的一致性

ZooKeeper通过多数确认机制确保数据一致性的描述，实际上应该是线性一致性（Linearizability）或顺序一致性（Sequential Consistency），而不完全等同于强一致性（Strong Consistency）在某些特定上下文中的严格定义。让我们更详细地探讨这个问题。 ZooKeeper通过多数确认机制、单一leader处理写请求、事务日志和数据同步等机制，提供了线性一致性和顺序一致性。这些一致性模型在实践中通常被认为是“强一致性”的有效形式，确保了系统在面对网络分区和节点故障时，仍然能够保持数据的一致性。

zxid 和数据一致性

在 ZooKeeper 中，zxid（ZooKeeper Transaction ID）是一个全局唯一的事务标识符，用于标记和排序所有的事务操作。每一个 zxid 表示一个特定的状态变更（如创建节点、删除节点、修改节点数据等），它是确保 ZooKeeper 数据一致性和顺序性的关键机制。

zxid 的作用

• 全局顺序：zxid 确保所有事务在 ZooKeeper 集群中具有全局顺序，所有节点以相同的顺序处理事务，从而保证数据一致性。
• Leader 选举：在 Leader 选举过程中，节点会比较 zxid，以确定哪个节点具有最新的数据状态，优先选择拥有最大 zxid 的节点作为新 Leader。
• 数据恢复：当节点重新加入集群或在崩溃后恢复时，zxid 用于识别和同步缺失的事务，确保节点的数据与 Leader 保持一致。

 zxid 是 ZooKeeper 保证数据一致性和顺序性的核心机制。通过 zxid，ZooKeeper 能够在分布式环境中实现以下目标：

• 全局有序性：所有节点按照相同的顺序处理事务，确保数据一致性。
• 故障恢复：在 Leader 失效或网络分区恢复后，使用 zxid 同步和恢复数据，保证系统的可靠性。
• 一致性视图：客户端在读取数据时，能够看到一个一致的视图，因为所有写操作都是按照 zxid 的顺序提交和应用的

2）ZooKeeper 不强调可用性（Availability）

由于 ZooKeeper 优先保证一致性和分区容忍性，因此在某些情况下，系统可能会牺牲部分可用性。例如：

• Leader 选举期间：当现任 Leader 失效或发生网络分区时，ZooKeeper 需要时间进行 Leader 选举。在选举过程中，集群无法处理写请求，导致短暂的不可用。
• 多数确认机制：写操作需要得到多数节点的确认才能提交，如果多数节点不可用，则写操作无法完成，导致系统部分不可用。

3）实际应用中的平衡

虽然 ZooKeeper 是一个 CP 系统，但在实际应用中，ZooKeeper 通过优化 Leader 选举和数据同步过程，尽量减少不可用的时间，提供尽可能高的可用性。这使得 ZooKeeper 在需要强一致性和分区容忍性的分布式系统中成为一个可靠的协调服务。

总结

• ZooKeeper 是一个 CP 系统，在 CAP 定理中优先保证一致性和分区容忍性。
• 一致性：通过多数确认机制和 ZAB 协议确保数据一致性。
• 分区容忍性：在网络分区时，通过选举新的 Leader 保持系统运行。
• 可用性：在某些情况下会被牺牲，以确保系统的一致性和分区容忍性。

3 Leader选举过程

初始状态

在ZooKeeper集群启动或Leader失效时，会触发Leader选举。每个节点都处于LOOKING状态，表示正在寻找新的Leader。

投票机制

1. 发起投票：

   • 每个节点（假设节点为ZK1, ZK2, ZK3, ZK4, ZK5）会发起一个投票，首先投票给自己。投票包括节点ID和节点的事务ID（zxid，表示节点处理到的最新事务）。

2. 投票交换：

   • 每个节点会将自己的投票发送给其他所有节点。
   • 节点接收到其他节点的投票后，会比较投票内容。

3. 投票比较：

   • 比较规则：首先比较zxid，zxid大的节点优先；如果zxid相同，则比较节点ID，节点ID大的优先。
   • 如果接收到的投票比当前节点的投票更优（根据比较规则），则当前节点更新自己的投票，改为投票给优先级更高的节点。

4. 计数投票：

   • 每个节点维护一个投票计数，统计每个节点获得的投票数。