前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Zookeeper详细使用解析!分布式架构中的协调服务框架最佳选型实践

Zookeeper详细使用解析!分布式架构中的协调服务框架最佳选型实践

原创
作者头像
攻城狮Chova
修改2021-08-25 11:42:24
4620
修改2021-08-25 11:42:24
举报
文章被收录于专栏:攻城狮Chovas

Zookeeper概念

  • Zookeeper是分布式协调服务,用于管理大型主机,在分布式环境中协调和管理服务是很复杂的过程,Zookeeper通过简单的架构和API解决了这个问题Zookeeper实现分布式锁分布式锁三要素: 加锁 解锁 锁超时
  • Zookeeper数据结构类似树结构,由节点Znode组成
  • Znode分为四种类型:
    • 持久节点(PERSISTENT): 默认节点类型,创建节点的客户端与Zookeeper断开连接后,节点依旧存在
    • 持久节点顺序节点(PERSISTENT_SEQUENTIAL): 持久节点顺序节点就是在创建持久节点时,Zookeeper根据创建节点的时间顺序给节点进行编号
    • 临时节点(EPHEMERAL): 创建节点的客户端与Zookeeper断开连接后,临时节点会被删除
    • 临时节点顺序节点(EPHEMERAL_SEQUENTIAL): 临时节点顺序节点就是在创建临时节点时,Zookeeper根据创建节点的时间顺序给节点进行编号
    • 应用Zookeeper的临时顺序节点,实现分布式锁

Zookeeper与Redis分布式锁比较:

分布式锁

Zookeeper

Redis

优点

1.有封装好的框架,容易实现 2.有等待锁队列,提升抢锁的效率

Set和Del指令性能高

缺点

添加和删除节点性能低

1.实现复杂,需要考虑原子性,误删,锁超时问题 2.没有等待锁的队列,只能客户端自旋来等锁,效率低

Zookeeper的数据模型

  • 类似数据结构中的树,文件系统中的目录数据一致性: 强一致性 弱一致性 顺序一致性:Zookeeper,依靠事务ID和版本号,保证数据的更新和读取是有序的Zookeeper应用场景1.创建docker-compose.yml zoo: image: zookeeper restart: always hostname: zoo ports: - 2181:2181 environment: - ZOO_MY_ID: 1 - ZOO_SERVER: server.1(id)=zoo(IP):2888:3888 2.执行docker-compose up -dZookeeper三种工作模式
  • Zookeeper的数据存储基于节点Znode
  • Znode的引用方式是路径引用,每一个Znode节点拥有唯一的路径Znode中的元素
  • data: Znode存储的数据信息
  • ACL: 记录Znode的访问权限,即哪些进程和IP可以访问本节点
  • stat: Znode的各种元数据(数据的数据)
  • child: 当前节点的子节点引用 Zookeeper的应用场景是读多写少的应用场景:Znode不用来存储大规模的业务数据,用于存储少量的状态和配置信息(Znode存储数据不能超过1MB)Zookeeper基本操作
  • 创建节点:create
  • 删除节点:delete
  • 判断节点是否存在:exists
  • 获得一个节点的数据:getData
  • 设置一个节点的数据:setData
  • 获取节点下的所有子节点:getChildren exists,getData,getChildren属于读操作,Zookeeper客户端在请求读操作时,可以选择是否设置watchZookeeper事件通知
  • Watch可以理解成注册在特定Znode上的触发器
  • 当Znode发生改变的时候,调用create,delete,setData方法,将会触发Znode上注册的对应事件,请求的Watch的客户端会接收到异步通知
  • Zookeeper事件通知的交互过程:
    • 客户端调用getData方法,watch的参数是true,服务端接收到请求,返回节点数据,在对应的Hash表中插入被Watch的Znode路径以及Watcher列表
    • 当被Watch的Znode删除,服务端会查找Hash表,找到该Znode对应的所有Watcher,异步通知客户端,并且删除Hash表中对应的key-valueZookeeper的一致性
  • Zookeeper Service集群是一主多从结构
  • 在更新数据时,首先更新到主服务器,再同步到从服务器
  • 在读数据时,直接读取任意节点
  • 采用ZAB协议,为了保证主从节点数据的一致性ZAB协议
  • ZAB(Zookeeper Automic Broadcast): 解决Zookeeper集群崩溃恢复,主从数据同步问题
  • ZAB三种节点状态:
    • Looking:选举状态
    • Following:Following节点(从节点)所处的状态
    • Leading:Leading(主节点)所处的状态
  • 最大ZXID: 节点本地的最新事务编号,包含epoch计数两部分ZAB集群崩溃恢复
  • 当Zookeeper的主节点服务器宕机后,集群就会进行崩溃恢复,分成三个阶段:
    • Leader election(选举阶段):
      • 集群中的节点处于Looking状态,各自向其它节点发起投票,投票当中包含自己服务器的ID和最新事务ID(ZXID)
      • 节点用自身的ZXID和其它节点收到的ZXID作比较,如果发现其它节点的ZXID比自身大,即数据比自己新,就重新发起投票,投票给目前已知最大ZXID所属节点
      • 每次投票后,服务器都会统计投票数量,判断是否某个节点得到半数以上的投票,这样的节点将会成为准Leader,状态变为Leading,其它节点状态变为Following
    • Discovery(发现阶段):
      • 在从节点发现最新的ZXID和事务日志,目的是为了防止在意外情况,选举产生多个Leader
      • Leader接收所有Follower发送的最新的epoch值,Leader从中选出最大的epoch,基于此值+1,生成新的epoch分发给各个Follower
      • 各个Follower接收到最新的epoch,返回ACK(响应码)给Leader,带上各自最大的ZXID和历史事务日志,Leader选出最大的ZXID,并更新自身历史日志
    • Synchronization(同步阶段): - 将Leader收集得到的最新历史事务日志,同步给集群中的所有Follower,只有当半数Follower同步成功,这个准Leader才能成为正式Leader.集群崩溃恢复正式完成ZAB主从数据同步
  • Broadcast Zookeeper常规情况下更新数据的时候,由Leader广播到所有的Follower:
    • 客户端发出写入数据请求给任意的Follower
    • Follower把写入数据请求转发给Leader
    • Leader采取二阶段提交方式:(先保留提交日志,再提交数据)先发送Propose广播给Follower
    • Follower接收到Propose消息,写入日志成功后,返回ACK消息给Leader
    • Leader接收到半数以上的ACK消息,返回成功给客户端,并且广播commit请求给Follower
  • 分布式锁: 应用Zookeeper的临时顺序节点,实现分布式锁
  • 服务注册与发现: 利用Znode和Watcher,实现分布式服务注册与发现,如Dubbo
  • 共享配置和状态信息: Redis的分布式解决方案Codls,利用Zookeeper存放数据路由表和codls-proxy节点元信息,同时colds-config发起的命令都会通过Zookeeper同步到各个存活的codls-proxy
  • 高可用实现: Kafka,HBase,Hadoop都依靠Zookeeper同步节点信息,实现高可用基于Docker创建Zookeeper
  • 单机模式: 存在单点故障
  • 集群模式: 在多台服务器上部署Zookeeper集群
  • 伪集群模式: 在同一台服务器上运行多个Zookeeper实例,仍然有单点故障问题,其中配置的端口号要错开Zookeeper三种端口号
  • 2181: 客户端连接Zookeeper集群使用的监听端口号
  • 3888: 选举Leader使用
  • 2888: 集群内机器通讯使用(Leader和Follower之间数据同步使用的端口号,Leader监听此端口)

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • Zookeeper概念
  • Zookeeper的数据模型
相关产品与服务
容器镜像服务
容器镜像服务(Tencent Container Registry,TCR)为您提供安全独享、高性能的容器镜像托管分发服务。您可同时在全球多个地域创建独享实例,以实现容器镜像的就近拉取,降低拉取时间,节约带宽成本。TCR 提供细颗粒度的权限管理及访问控制,保障您的数据安全。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档