尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

Zookeeper - 核心架构拆解:Leader Follower Observer

Zookeeper - 核心架构拆解:Leader Follower Observer 大家好欢迎来到我的技术博客 在这里我会分享学习笔记、实战经验与技术思考力求用简单的方式讲清楚复杂的问题。 本文将围绕Zookeeper这个话题展开希望能为你带来一些启发或实用的参考。 无论你是刚入门的新手还是正在进阶的开发者希望你都能有所收获文章目录Zookeeper 核心架构拆解Leader、Follower、ObserverLeader 的角色与选举机制Leader 的主要职责Leader 的选举机制Follower 的作用与协作机制Follower 的主要职责Follower 与 Leader 的协作机制Observer 的作用与适用场景Observer 的主要职责Observer 的适用场景Leader、Follower 和 Observer 的协作机制数据同步流程事务广播机制ZooKeeper 的数据模型与会话管理ZNode 的类型会话管理机制ZooKeeper 的监听机制与事件通知Watcher 的工作原理事件通知机制ZooKeeper 的典型应用场景分布式锁配置管理服务注册与发现组成员管理ZooKeeper 的优势与局限性优势局限性适用场景Zookeeper 核心架构拆解Leader、Follower、ObserverZooKeeper 是一个高效的分布式协调服务广泛用于分布式系统中的配置管理、命名服务、分布式锁等场景。其核心架构由三种角色组成Leader、Follower和Observer。这三种角色共同协作确保系统的高可用性和一致性。在 ZooKeeper 集群中Leader 负责处理写请求并协调数据同步Follower 既参与写请求的投票也响应读请求而 Observer 则主要用于扩展读请求的处理能力而不参与投票。ZooKeeper 的设计目标是提供高可用性、顺序一致性以及最终一致性。它基于ZABZooKeeper Atomic Broadcast协议实现分布式一致性确保所有节点上的数据保持同步。ZAB 协议的核心思想是通过选举机制选出一个 Leader并由该 Leader 负责广播事务性操作而 Follower 和 Observer 则负责接收这些操作并更新本地数据。本篇文章将深入探讨 ZooKeeper 的核心架构分析 Leader、Follower 和 Observer 各自的作用及其协作方式并通过 Java 示例代码展示如何在实际应用中使用 ZooKeeper。此外我们还将介绍 ZooKeeper 的数据模型、会话管理、监听机制以及典型应用场景帮助读者全面理解其工作原理和使用方式。Leader 的角色与选举机制在 ZooKeeper 集群中Leader是整个系统的核心角色负责处理所有写请求并协调数据同步。ZooKeeper 使用ZABZooKeeper Atomic Broadcast协议来确保数据的一致性而 Leader 在其中扮演着至关重要的角色。Leader 的主要职责处理写请求所有客户端的写操作如创建节点、更新数据、删除节点都必须经过 Leader。Leader 会将这些操作封装成事务并广播给所有 Follower。协调事务提交Leader 会确保事务在大多数 Follower 成功提交后才真正生效以保证数据的一致性。维护集群状态Leader 会定期向 Follower 发送心跳信息以确认它们的状态。如果某个 Follower 失去响应Leader 会将其从同步队列中移除。发起选举当 Leader 宕机或与大多数 Follower 失去联系时ZooKeeper 会触发选举机制重新选出新的 Leader。Leader 的选举机制ZooKeeper 使用Fast Paxos的变种算法来选举 Leader确保在集群中大多数节点存活的情况下能够快速选出新的 Leader。选举过程主要包括以下几个步骤投票阶段Looking当集群启动或 Leader 失效时所有节点进入 Looking 状态并向其他节点发送投票请求。每个节点会根据自身的数据版本zxid和服务器 IDmyid决定支持哪个节点成为 Leader。收集投票各个节点接收来自其他节点的投票并根据投票规则决定是否更改自己的投票目标。达成共识当某个节点获得大多数节点的投票支持时它会被选为新的 Leader其他节点则成为 Follower 或 Observer。Leader 的选举机制确保了 ZooKeeper 在面对故障时能够快速恢复同时避免了脑裂Split-Brain问题保证了系统的高可用性。Follower 的作用与协作机制在 ZooKeeper 集群中Follower是 Leader 的协作节点负责参与事务投票和响应读请求。虽然 Follower 不具备处理写请求的权限但它们在保证数据一致性和集群可用性方面发挥着关键作用。Follower 的主要职责事务投票每当客户端提交一个写请求时Leader 会将该请求封装成事务并广播给所有 Follower。Follower 收到事务后会在本地执行该事务并返回确认信息。只有当大多数 Follower 成功提交该事务Leader 才会将其正式提交到数据树中。数据同步Follower 会持续从 Leader 接收最新的事务日志并同步本地数据以确保所有节点的数据一致性。处理读请求Follower 可以直接响应客户端的读请求而无需经过 Leader从而提高系统的读取性能。Follower 与 Leader 的协作机制ZooKeeper 采用ZABZooKeeper Atomic Broadcast协议来确保所有节点的数据一致性。Follower 与 Leader 之间的协作主要包括以下几个步骤事务广播Leader 接收到客户端的写请求后会生成一个事务提案Proposal并将其广播给所有 Follower。事务确认Follower 接收到提案后会在本地执行该事务并向 Leader 发送确认信息Ack。事务提交当 Leader 收到大多数 Follower 的确认信息后它会向所有 Follower 发送提交指令Commit确保事务在所有节点上生效。这种协作机制确保了 ZooKeeper 在分布式环境中的一致性同时避免了单点故障带来的影响。Observer 的作用与适用场景在 ZooKeeper 集群中Observer是一种特殊的节点角色它类似于 Follower但不参与事务投票。Observer 的主要作用是提升系统的读取能力同时减少对 Leader 的投票压力。Observer 的主要职责响应读请求Observer 可以像 Follower 一样处理客户端的读请求从而分担集群的读取负载。数据同步Observer 会从 Leader 接收事务日志并同步本地数据以保持数据一致性。不参与投票与 Follower 不同Observer 不参与事务投票因此不会影响 Leader 的选举和事务提交流程。Observer 的适用场景Observer 通常用于读多写少的场景以提升系统的整体吞吐量。例如大规模读取操作在需要处理大量读请求的系统中可以增加多个 Observer以提高读取性能。跨地域部署当 ZooKeeper 集群分布在多个地理位置时可以在远程数据中心部署 Observer以减少网络延迟对读取操作的影响。降低投票压力在大规模集群中增加 Observer 可以减少 Follower 的数量从而降低 Leader 的投票压力提高写操作的效率。Observer 的引入使得 ZooKeeper 在保持高一致性的同时也能支持更高的并发读取能力为分布式系统的扩展性提供了有力支持。Leader、Follower 和 Observer 的协作机制在 ZooKeeper 集群中Leader、Follower 和 Observer共同协作确保数据的一致性和系统的高可用性。它们之间的交互主要依赖于ZABZooKeeper Atomic Broadcast协议该协议确保所有事务操作在集群内正确广播并提交。数据同步流程当客户端提交一个写请求时请求首先由 Leader 接收并封装成事务提案Proposal。随后Leader 会将该提案广播给所有 Follower。Follower 接收到提案后在本地执行该事务并向 Leader 发送确认信息Ack。只有当大多数 Follower 返回确认信息Leader 才会提交该事务并通知所有 Follower 执行提交操作。Observer 的作用类似于 Follower但它们不参与投票。因此Leader 会向 Observer 发送事务日志确保它们能够同步数据但不会等待它们的确认信息。这种机制使得 Observer 可以提升系统的读取性能而不会影响事务的提交速度。事务广播机制ZAB 协议的核心是事务广播Atomic Broadcast它确保所有事务按照相同的顺序在所有节点上执行。Leader 负责生成事务提案并通过FIFO 顺序发送给 Follower。Follower 接收到提案后会按照相同的顺序执行并确保数据的一致性。如果某个节点Follower 或 Observer与 Leader 失去连接它会尝试重新连接并同步最新的事务日志。这种机制确保即使在节点故障的情况下集群仍然能够保持数据的一致性。通过这种协作机制ZooKeeper 能够在分布式环境中提供高可用性和强一致性使得系统能够在面对故障时快速恢复同时保持数据的正确性。ZooKeeper 的数据模型与会话管理ZooKeeper 提供了一个层次化的数据模型类似于文件系统的目录结构。它的核心数据单元是ZNodeZooKeeper Node每个 ZNode 都可以存储数据并且可以拥有子节点。这种结构使得 ZooKeeper 能够高效地管理分布式系统中的配置信息、状态数据和元数据。ZNode 的类型ZooKeeper 支持多种类型的 ZNode主要包括以下几种持久节点PERSISTENT一旦创建除非显式删除否则该节点会一直存在。临时节点EPHEMERAL当创建该节点的客户端会话结束时该节点会被自动删除。顺序节点SEQUENTIAL节点名称会自动附加一个递增的序号确保唯一性。ZNode 还可以组合使用例如EPHEMERAL_SEQUENTIAL表示临时顺序节点。会话管理机制ZooKeeper 通过会话Session来管理客户端与服务器之间的连接。客户端与 ZooKeeper 建立连接后会获得一个唯一的会话 IDSession ID和会话超时时间Session Timeout。如果客户端在超时时间内未与服务器通信会话将被视为失效所有与该会话相关的临时节点都会被删除。客户端可以通过心跳机制与 ZooKeeper 保持连接。ZooKeeper 服务器会定期检测客户端的心跳如果在超时时间内未收到心跳会认为客户端已断开连接并触发会话失效处理。会话管理机制确保了 ZooKeeper 能够在分布式系统中提供可靠的协调服务同时支持客户端的断线重连功能。ZooKeeper 的监听机制与事件通知ZooKeeper 提供了监听机制Watcher允许客户端注册监听器以便在数据发生变化时接收通知。这种机制使得分布式系统中的各个组件能够及时响应状态变更从而实现高效的协调和同步。Watcher 的工作原理Watcher 是 ZooKeeper 客户端可以注册的一种回调机制。当某个 ZNode 的数据或子节点发生变化时ZooKeeper 会向注册了 Watcher 的客户端发送通知。Watcher 本质上是一种一次性触发的机制即每次通知后客户端需要重新注册 Watcher 才能继续监听后续变化。Watcher 的注册方式主要有以下几种getData(path, watcher, stat)监听某个节点的数据变化。exists(path, watcher)监听某个节点是否存在。getChildren(path, watcher)监听某个节点的子节点变化。事件通知机制ZooKeeper 的事件通知机制基于事件驱动模型当 ZNode 发生变化时ZooKeeper 服务器会将事件推送给客户端。常见的事件类型包括NodeCreated节点被创建。NodeDeleted节点被删除。NodeDataChanged节点数据发生变化。NodeChildrenChanged节点的子节点发生变化。客户端收到事件通知后可以根据具体的业务逻辑进行处理。例如在分布式锁实现中当锁节点被释放时等待的客户端可以收到通知并尝试重新获取锁。通过 Watcher 和事件通知机制ZooKeeper 为分布式系统提供了强大的协调能力使得各个组件能够实时响应数据变化提高系统的响应速度和一致性。ZooKeeper 的典型应用场景ZooKeeper 凭借其高可用性和强一致性被广泛应用于分布式系统中的多个关键场景。以下是几个典型的使用案例分布式锁ZooKeeper 提供了实现分布式锁的有效机制。利用临时顺序节点EPHEMERAL_SEQUENTIAL多个客户端可以竞争创建顺序节点最小编号的节点持有锁其他客户端监听前一个节点的删除事件以实现锁的释放和重新竞争。importorg.apache.zookeeper.*;importorg.apache.zookeeper.data.Stat;importjava.io.IOException;importjava.util.List;importjava.util.Collections;publicclassDistributedLockimplementsWatcher{privatefinalZooKeeperzk;privatefinalStringlockPath;privateStringcurrentPath;publicDistributedLock(ZooKeeperzk,StringlockPath){this.zkzk;this.lockPathlockPath;}publicvoidacquireLock()throwsKeeperException,InterruptedException{// 创建临时顺序节点currentPathzk.create(lockPath/lock_,newbyte[0],ZooDefs.Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);System.out.println(Created: currentPath);ListStringchildrenzk.getChildren(lockPath,false);Collections.sort(children);StringshortestPathlockPath/children.get(0);if(currentPath.equals(shortestPath)){System.out.println(Acquired lock: currentPath);}else{StringprevPathlockPath/children.get(Collections.binarySearch(children,currentPath.substring(lockPath.length()1))-1);synchronized(this){zk.exists(prevPath,this);wait();// 等待锁释放}System.out.println(Lock released, acquired: currentPath);}}Overridepublicvoidprocess(WatchedEventevent){if(event.getType()Event.EventType.NodeDeleted){synchronized(this){notify();// 唤醒等待的线程}}}publicvoidreleaseLock()throwsKeeperException,InterruptedException{zk.delete(currentPath,-1);System.out.println(Released lock: currentPath);}publicstaticvoidmain(String[]args)throwsIOException,KeeperException,InterruptedException{ZooKeeperzknewZooKeeper(localhost:2181,3000,event-{});DistributedLocklocknewDistributedLock(zk,/locks);lock.acquireLock();// 执行业务逻辑Thread.sleep(2000);lock.releaseLock();zk.close();}}配置管理ZooKeeper 可以用于存储和同步分布式系统的配置信息。通过 Watcher 机制客户端可以监听配置节点的变化并在配置更新时自动获取最新配置确保所有节点保持一致。服务注册与发现在微服务架构中ZooKeeper 可以作为服务注册中心。服务提供者启动时在 ZooKeeper 中创建临时节点服务消费者则监听这些节点的变化以发现可用服务。组成员管理ZooKeeper 可以用于管理分布式系统中的组成员关系。当节点加入或离开集群时ZooKeeper 会通知所有成员以便进行相应的调整。ZooKeeper 的这些应用场景使其成为构建高可用、强一致性的分布式系统的重要工具。ZooKeeper 的优势与局限性ZooKeeper 作为分布式协调服务具有高可用性、强一致性和顺序一致性等优势使其成为分布式系统中的核心组件。然而它也存在一定的局限性如性能瓶颈和扩展性限制。优势高可用性ZooKeeper 采用 Leader-Follower 架构确保即使部分节点故障系统仍能正常运行。强一致性基于 ZAB 协议ZooKeeper 保证所有事务操作按顺序执行确保数据一致性。顺序一致性所有客户端的写操作都会被顺序处理保证数据更新的顺序性。轻量级ZooKeeper 的数据模型简单适合存储元数据和协调信息。局限性性能瓶颈ZooKeeper 的写操作需要经过 Leader导致写性能受限。扩展性限制ZooKeeper 集群的节点数量不宜过多通常建议在 5~7 个节点以内。数据存储限制ZooKeeper 不适合存储大量数据每个节点的数据大小通常限制在 1MB 以内。适用场景ZooKeeper 适用于需要高一致性和协调服务的场景如分布式锁、配置管理、服务注册与发现等。对于需要高吞吐量或大规模数据存储的场景可以选择其他分布式存储系统如etcd或Consul。ZooKeeper 在分布式系统中扮演着重要的协调角色其核心架构确保了系统的稳定性和一致性。随着分布式架构的演进ZooKeeper 也在不断优化以适应更复杂的应用需求。 感谢你读到这里 技术之路没有捷径但每一次阅读、思考和实践都在悄悄拉近你与目标的距离。 如果本文对你有帮助不妨 点赞、收藏、分享给更多需要的朋友 欢迎在评论区留下你的想法、疑问或建议我会一一回复我们一起交流、共同成长 关注我不错过下一篇干货我们下期再见✨
返回列表