网站查询空间商,网站后台html页面,微信商城网站哪家做的好,英文网站备案1. ZooKeeper 的架构
ZooKeeper 采用主从架构#xff08;Leader-Follower 模型#xff09;#xff0c;包括以下组件#xff1a;
Leader#xff1a;负责处理所有写请求和协调事务一致性。Follower#xff1a;处理读请求并转发写请求给 Leader。参与 Leader 选举和事务提…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被选举出来时系统进入恢复模式。恢复模式的主要步骤包括
选举新的leader通过选举算法选择一个新的leader节点。数据同步新选出的leader从follower节点中收集最新的数据状态并将这些状态同步到所有的follower节点。确认同步完成当所有follower节点与leader节点的数据状态一致后系统退出恢复模式进入广播模式。
广播模式 消息广播主要是针对写请求。
zookeeper客户端会随机连接到zookeeper集群中的某个节点如果是读请求就直接从当前节点中读取数据如果是写请求那么节点就会向 Leader 发送写请求由Leader依赖zab协议处理。
zab协议对于写操作的处理有些类似于分布式事务的两阶段提交。
在两阶段提交里写操作分为投票prepare阶段和提交commit阶段。当一个写请求到达时协调中心会将请求发给所有的参与者如果所有的参与者都写入成功那么就提交这个写请求反之只要有一个参与者写入失败就会回滚。在所有的参与者返回结果之前协调中心会一直阻塞耗时比较久。
zab协议在此基础上做了修改将节点角色分为leader和follower只需要半数以上的follower写入成功即可。
广播模式主要处理正常情况下的数据同步。在广播模式下所有的写请求都首先发送到leader节点leader节点会将这些请求以事务的形式广播给所有的follower节点。广播模式的主要步骤包括
事务提议leader节点接收到写请求后生成一个事务提议Proposal并将其广播给所有的follower节点。事务确认follower节点接收到事务提议后写入本地日志并发送确认ACK给leader节点。事务提交leader节点收到大多数follower节点的确认后将事务提交并再次广播提交消息Commit给所有的follower节点。事务应用follower节点接收到提交消息后将事务应用到本地数据状态。
2 ZooKeeper 的 CP 特性 一致性Consistency ZooKeeper 确保在任何时刻所有节点的数据都是一致的。每次写操作必须得到集群中多数节点的确认才能提交保证了数据的强一致性。ZAB 协议ZooKeeper Atomic Broadcast通过事务日志和数据快照机制确保所有节点的数据状态一致。 分区容忍性Partition Tolerance ZooKeeper 能够容忍网络分区保证集群在部分节点失联或网络故障时继续运行。在发生网络分区时只有包含多数节点的分区能够选举出新的 Leader 并继续处理写请求防止数据不一致。 1ZooKeeper中的一致性
ZooKeeper通过多数确认机制确保数据一致性的描述实际上应该是线性一致性Linearizability或顺序一致性Sequential Consistency而不完全等同于强一致性Strong Consistency在某些特定上下文中的严格定义。让我们更详细地探讨这个问题。 ZooKeeper通过多数确认机制、单一leader处理写请求、事务日志和数据同步等机制提供了线性一致性和顺序一致性。这些一致性模型在实践中通常被认为是“强一致性”的有效形式确保了系统在面对网络分区和节点故障时仍然能够保持数据的一致性。
zxid 和数据一致性
在 ZooKeeper 中zxidZooKeeper Transaction ID是一个全局唯一的事务标识符用于标记和排序所有的事务操作。每一个 zxid 表示一个特定的状态变更如创建节点、删除节点、修改节点数据等它是确保 ZooKeeper 数据一致性和顺序性的关键机制。
zxid 的作用
全局顺序zxid 确保所有事务在 ZooKeeper 集群中具有全局顺序所有节点以相同的顺序处理事务从而保证数据一致性。Leader 选举在 Leader 选举过程中节点会比较 zxid以确定哪个节点具有最新的数据状态优先选择拥有最大 zxid 的节点作为新 Leader。数据恢复当节点重新加入集群或在崩溃后恢复时zxid 用于识别和同步缺失的事务确保节点的数据与 Leader 保持一致。 zxid 是 ZooKeeper 保证数据一致性和顺序性的核心机制。通过 zxidZooKeeper 能够在分布式环境中实现以下目标
全局有序性所有节点按照相同的顺序处理事务确保数据一致性。故障恢复在 Leader 失效或网络分区恢复后使用 zxid 同步和恢复数据保证系统的可靠性。一致性视图客户端在读取数据时能够看到一个一致的视图因为所有写操作都是按照 zxid 的顺序提交和应用的
2ZooKeeper 不强调可用性Availability
由于 ZooKeeper 优先保证一致性和分区容忍性因此在某些情况下系统可能会牺牲部分可用性。例如
Leader 选举期间当现任 Leader 失效或发生网络分区时ZooKeeper 需要时间进行 Leader 选举。在选举过程中集群无法处理写请求导致短暂的不可用。多数确认机制写操作需要得到多数节点的确认才能提交如果多数节点不可用则写操作无法完成导致系统部分不可用。
3实际应用中的平衡
虽然 ZooKeeper 是一个 CP 系统但在实际应用中ZooKeeper 通过优化 Leader 选举和数据同步过程尽量减少不可用的时间提供尽可能高的可用性。这使得 ZooKeeper 在需要强一致性和分区容忍性的分布式系统中成为一个可靠的协调服务。
总结
ZooKeeper 是一个 CP 系统在 CAP 定理中优先保证一致性和分区容忍性。一致性通过多数确认机制和 ZAB 协议确保数据一致性。分区容忍性在网络分区时通过选举新的 Leader 保持系统运行。可用性在某些情况下会被牺牲以确保系统的一致性和分区容忍性。
3 Leader选举过程
初始状态
在ZooKeeper集群启动或Leader失效时会触发Leader选举。每个节点都处于LOOKING状态表示正在寻找新的Leader。
投票机制 发起投票 每个节点假设节点为ZK1, ZK2, ZK3, ZK4, ZK5会发起一个投票首先投票给自己。投票包括节点ID和节点的事务IDzxid表示节点处理到的最新事务。 投票交换 每个节点会将自己的投票发送给其他所有节点。节点接收到其他节点的投票后会比较投票内容。 投票比较 比较规则首先比较zxidzxid大的节点优先如果zxid相同则比较节点ID节点ID大的优先。如果接收到的投票比当前节点的投票更优根据比较规则则当前节点更新自己的投票改为投票给优先级更高的节点。 计数投票 每个节点维护一个投票计数统计每个节点获得的投票数。
