Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Apache Zookeeper 分布式服务框架

1,180 views

Published on

Apache Zookeeper 分布式服务框架

Published in: Technology
  • Be the first to comment

Apache Zookeeper 分布式服务框架

  1. 1. 2015.05王先明 Apache Zookeeper 分布式服务框架
  2. 2. 1 Zookeeper ︎︎︎特性 2 Zookeeper 原理理 3 Zookeeper 设计
  3. 3. Zookeeper特性1
  4. 4. 分布式&Google
  5. 5. Google的Chubby的一个开源实现 源自Yahoo分布式协调服务 Apache下的顶级项目 Hadoop和HBase的重要组件 基于对Paxos算法的实现
  6. 6. Zookeeper 共享锁服务 配置管理 统一命名服务 队 列 管 理 集 群 管 理 Zookeeper保证数据的强一致性,任何 时候集群中每个节点的数据都相同。一 个用户创建一个节点作为锁:检测该节 点是否存在,若存在,代表已被上锁, 否则可创建一个节点,代表拥有该锁 将配置信息保存在Zookeeper的某个目录节点中, 一旦配置信息发生变化,每台应用机器就会收到 Zookeeper的通知,然后从Zookeeper获取新的 配置信息应用到系统中 分布式应用通常要有一套完整的命名规则, 而用树形结构是一个理想的选择,树形结 构是一个有层次的目录结构, 既友好又 不会重复便于识别和记住 Zookeeper能够维护当前的集群中机器的 服务状态,能够帮你选出一个“总管”来 管理集群,这就是Zookeeper的另一个功 能Leader Election 同步队列 创建目录/synchronizing,每个成员都加入/ synchronizing/member_i并监控/ synchronizing/start,判断i值等于成员个 数,若小于则等待/synchronizing/start出 现,若相等则创建/synchronizing/start FIFO队列 在/queue-fifo下创建SEQUENTIAL子目录/ x(i),保证所有成员入队时都有编号,出队时 通过getChildren()方法返回当前队列中所有 元素,然后消费其中最小的一个
  7. 7. 如何实现分布式锁服务 2. 利用临时顺序节点实现共享锁的一般做法 3. 利用临时顺序节点实现共享锁的改进实现 1. 利用节点名称的唯一性来实现共享锁
  8. 8. 无需重新编译,缺点显而易见,要往上百台机器上重新部署应用,简直是一个噩梦。就是配置修改往往 无法做到实时生效 配置信息通常存储方式 2. 写入文件中 方案简单,但每次修改配置都要重新编译、部署应用程序。显然这种方案很不方便,也不可靠,更无法 做到修改实时生效 1. 写入代码中 直接修改数据库,然后重启分布式应用程序或者刷新分布式应用的缓存。面临着单点失效问题(数据库 服务器停机) 3. 写入数据库中
  9. 9. Zookeeper 配置信息存储时序 ⽤用户 Zookeeper服务器器集群 分布式应⽤用程序后台配置管理理系统 1:注册节点配置变更更Watch 2:修改配置 3:修改Zookeeper对应节点配置内容 4:注册节点配置变更更, 触发Watch通知变化 5:修改配置
  10. 10. 单点故障传统解决方案 Master Slave Master Slave PING ACK 备用节点主节点 从节点 从节点
  11. 11. 单点故障传统解决方案 Master Slave Master Slave PING ACK 备用节点主节点 从节点 从节点 XX XX
  12. 12. 单点故障传统解决方案 Master Slave Master Slave PING ACK 备用节点主节点 从节点 从节点 网络故障
  13. 13. 单点故障Zookeeper解决方案 Master B Slave Master A Slave 主节点B主节点A 从节点 从节点 Zookeeper Zookeeper数据结构 /master-000001 /master-000002 编号最⼩小的节点将获得锁, 成为⼯工作Master Master B Master A /master /
  14. 14. 单点故障Zookeeper解决方案 Master B Slave Master A Slave 主节点B主节点A 从节点 从节点 X XX Zookeeper Zookeeper数据结构 /master /master-000001 /master-000002 编号最⼩小的节点将获得锁, 成为⼯工作Master Master B Master AX /master /
  15. 15. 单点故障Zookeeper解决方案 Master B Slave Master A Slave 主节点B主节点A 从节点 从节点 Zookeeper Zookeeper数据结构 /master-000002 /master-000003 编号最⼩小的节点将获得锁, 成为⼯工作Master Master A Master B /master /
  16. 16. Zookeeper原理理2
  17. 17. Zookeeper 保证 2. 原子性:更新要么成功,要么失败,不会出现部分更新 3. 单一性:无论客户端连接哪个Server,都会看到同一个视图 1. 顺序一致性:按照客户端发送请求的顺序更新数据 4. 可靠性:一旦数据更新成功,将一直保持,直到新的更新 5. 及时性:客户端会在一个确定的时间内得到最新的数据
  18. 18. Zookeeper 服务过程 Zookeeper Services Follower Leader Follower Client Client Client Client Client Client write read read read read read Server Server Server
  19. 19. Zookeeper 角色&状态 角色 描述 领导者(Leader) Leader负责进行投票的发起和决议,更新系统状态 学习者 (Learner) 跟随者 (Follower) Follower用于接收客户请求并向Client返回结果,在选主的过 程中参与投票 观察者 (Observer) Observer可以接收Client连接,将写请求转发给Leader节 点,但Observer不参与投票过程,只同步Leader的状态 客户端(Client) 请求发起方
  20. 20. Zookeeper 状态同步 Leader Follower 2. Leader确定同步点,发送同步消息 3. 完成同步点,通知Leader,并修改自己状态 1. Follower连接Leader,发送最大zxid
  21. 21. Zab广播模式 Follower Follower Propose Leader Request Commit ACK Propose Commit ACK The flow of message with protocol
  22. 22. Zab广播模式 Follower Leader Follower Follower Follower FollowerClient Zookeeper Ensemble Server: Leader && Follower 1. request 6. response 2. request 5. Commit 4. ack 3. Propose
  23. 23. Follower 工作流程 向Leader发送请求 /接收Leader回应 接收Client请求 PING REVALIDATE SYNC/UPTODATE Proposal Y判断 是否写请求 返回结果给Client 开始 N
  24. 24. Leader 工作流程 开始 请求类型 接收Learner请 求,是否同步 恢复数据(恢 复模式) N 与Learner同步 Y PING REQUEST ACK REVALIDATE 加入处理队列 更新session时 间(延长) 发起 Leader 选举 保持与Follower 的心跳 Y 是否有超过半数 的Follower同意 Commit 是否有超过半数 的Follower N Y
  25. 25. Zookeeper 谁是Leader? Zab 协议(Zookeeper Atomic Broadcast Protocol) 当任一Client通过某集群节点向集群发起读写请求时,该集群节点会向Leader节点发出投 票请求,如果投票通过(超过一半节点同意)则该请求被执行,否则该请求被驳回。通过Paxos 算法,Zookeeper的保持了数据模型的一致性,同时保持了任何操作的原子性。
  26. 26. Zab恢复模式 Server1 Server2 X Server3 C1 P1 P2 P1 P2 C1 P3 C2 P1 P2
  27. 27. P1 P2 Zab恢复模式 Server1 Server2 Server3 X P10000001 P10000002 C10000001 C1 P3 C2 P1 P2 P1 P2 C1 C2 P10000001 P10000002 C10000001 C1 C2
  28. 28. Paxos一致性 Leader Server1 Follower Server2 Follower Server3 P1 <01, “/zk”> P2 <02, “/a”> P3 <03, “/a/b”> P1 P1 P1 <01, “/zk”> P1 <01, “/zk”> < t , v > Zxid 事务epoch counter 高32位 低32位 X X
  29. 29. Paxos一致性 Leader Server1 Follower Server2 Leader Server3 P1 <01, “/zk”> P2 <02, “/a”> P3 <03, “/a/b”> P2i P1 <01, “/zk”> P2i <02, “/c”> P1 <01, “/zk”> P2i <02, “/c”> < t , v > Zxid 事务epoch counter 高32位 低32位 X XX
  30. 30. Paxos一致性 Leader Server1 Follower Server2 Leader Server3 P1 <01, “/zk”> P2 <02, “/a”> P3 <03, “/a/b”> P3 P1 <01, “/zk”> P2i <02, “/c”> P3 <03, “/a/b”> P1 <01, “/zk”> P2i <02, “/c”> < t , v > Zxid 事务epoch counter 高32位 低32位 X
  31. 31. Zab一致性 Leader Server1 Follower Server2 Follower Server3 P1 <01, “/zk”> P2 <02, “/a”> P3 <03, “/a/b”> P1 P1 P1 <01, “/zk”> P1 <01, “/zk”> < t , v > Zxid 事务epoch counter 高32位 低32位 X X
  32. 32. Zab一致性 Leader Server1 Follower Server2 Leader Server3 P1 <01, “/zk”> P2 <02, “/a”> P3 <03, “/a/b”> P2i P1 <01, “/zk”> P2i <10, “/c”> P1 <01, “/zk”> P2i <10, “/c”> < t , v > Zxid 事务epoch counter 高32位 低32位 X XX
  33. 33. Zab一致性 Leader Server1 Follower Server2 Leader Server3 P1 <01, “/zk”> P2 <02, “/a”> P3 <03, “/a/b”> P3 P1 <01, “/zk”> P2i <10, “/c”> P1 <01, “/zk”> P2i <10, “/c”> < t , v > Zxid 事务epoch counter 高32位 低32位 X
  34. 34. Leader 选举 - Basic Paxos 投票 开始 N Y Y N 投票 结束 向集群(包括自 己)发起询问 Y N 第一次询问? 将自已(id, zxid)作为 Leader推荐给集群 接收询问,验证 是否自己发起? 获取对方id(myid),存入 已询问列表,获取对方提议的 Leader信息(id,zxid),存 入当前投票记录表,统计选举 结果,获取最大的zxid,并将 zxid所示的Server作为下次推 荐的Leader zxid是否有超过 半数支持 将zxid所示的Server 作为当前的Leader, 并根据投票结果修改 自己状态
  35. 35. 投票 开始 Y判断是否已经 选出Leader N 将自已epoch+1,推荐 自己(zxid,id)作为 Leader发送给集群 进入下一个周期 投票 结束 N Y 判断自己当前 epoch是否合法 更新自己epoch为对方推 荐的zxid,epoch,id。 向对方发送ACK N Y 一个周期内是否 收到其它节点回复 Leader 选举 - Fast Paxos
  36. 36. 为什么引入Observer? 角色 描述 领导者(Leader) Leader负责进行投票的发起和决议,更新系统状态 学习者 (Learner) 跟随者 (Follower) Follower用于接收客户请求并向Client返回结果,在选主的过 程中参与投票 观察者 (Observer) Observer可以接收Client连接,将写请求转发给Leader节 点,但Observer不参与投票过程,只同步Leader的状态 客户端(Client) 请求发起方
  37. 37. Zookeeper设计3
  38. 38. 关键数据结构-Znode Znode的几个主要属性: 属性 描述 cZxid 节点的创建时间所对应的Zxid格式时间戳 mZxid 节点的修改时间所对应的Zxid格式时间戳 cTime 节点的创建时间 mTime 节点的修改时间 version 节点数据版本号 cVersion 子节点数据版本号 aVersion 节点ACL版本号 dataLength 节点数据长库 numChilren 子节点数目
  39. 39. 关键数据操作-Znode Znode的几个主要操作: 属性 描述 create 创建节点(存在父节点) delete 删除节点(没有子节点) exists 测试节点是否存在,并返回节点数据信息 getACL / setACL 获取ACL / 设置ACL getChildren 获取所有子节点(列表) getData / setData 获取节点相关数据 / 设置节点相关数据 sync 同步Client视图(与Zookeeper同步)
  40. 40. 方法 String create(final String path, byte data[], List all, CreateMode createMode) 描述 返回:创建一个znode节点 参数:路径,znode内容,ACL,znode类型 方法 void delete(final String path, int version) 描述 返回:删除一个znode节点 参数:路径,版本号;如版本号不一致无法删除,如版本号为-1,跳过版本号检查,直接删除 方法 Stat exists(final String path, Watcher watcher) 描述 返回:判断某个znode节点是否存在 参数:路径,Watcher;当znode节点变更时,触发当前的watcher 方法 Stat exists(String path, boolean watch) 描述 返回:判断某个znode节点是否存在 参数:路径,监控标记;创建Zookeeper实例时指定的watcher 方法 Stat setData(final String path, byte data[], int version) 描述 返回:设置某个znode节点上的数据 参数:路径,数据,版本号;如版本号为-1,跳过版本号检查 方法 byte[] getData(final String path, Watcher watcher, Stat stat) 描述 返回:获取某个znode节点上的数据 参数:路径,数据,版本号等信息 方法 List getChildren(final String path, Watcher watcher) 描述 返回:获取某个znode节点下所有子节点 参数:路径,Watcher;该方法有多个重载
  41. 41. 关键数据触发Watch Watch机制,注册与触发: 设置watch watch触发器(trigger) create delete setData Znode child Znode child Znode exists NodeCreated NodeDeleted NodeDataChanged getData NodeDeleted NodeDataChanged getChildren NodeChildrenCha nged NodeDeleted NodeChildrenCha nged
  42. 42. Zookeeper 会话管理 Zookeeper Ensemble Follower Leader Session 0xAB Server Server FollowerServer FollowerServer FollowerServer ClientAPP ClientAPP ClientAPP ClientAPP Session 0x10 Session 0x06 Session 0x1B
  43. 43. Zookeeper 状态变迁 开始 结束 Alive NotAlive NewZookeeper() CONNECTEDCONNECTING CLOSEED Watcher.Event.KeepState Disconnected Watcher.Event.KeepState SyncConnected Zookeeper.close() Watcher.Event.KeepState Expired
  44. 44. Zookeeper 核心思想 Using versions to prevent inconsistencies due to concurrent updates 1 2 3 Client C1 writes the first version of /config Client C2 reads /config and writes the second version Client C1 tries to write a change to /config, but the request fails because the version does not match 1 2 3 Client C1 Client C2 setData /config x if version==1 Zookeeper /config version=1 /config version=2 getData /config x version==2 setData /config y if version==2 /config version=3 /config version=3 setData /config z if version==2 Incorrect version Failed! TIME
  45. 45. Zookeeper 基础组件 Zookeeper Services Write Request Atomic Broadcast Response txn Request Processor Replicated Database txn Read Request
  46. 46. To Be Continued… Thanks

×