Zookeeper-分布式协调服务

分布式协调服务的角色

担任协调者
  • leader选举
  • 负载均衡
  • 服务发现
将多级协调的职责从服务中分离出来
  • 比如kafka 中的各个角色在zk中注册 producer需要知道有几个broker,需要从zk中读取

zookeeper 在百科中的应用

  • leader的选举(避免单点故障,hdfs,yarn,mepreduce等)
  • 命名(dubbo)
  • 分布式的锁
  • 发布订阅
  • 负载均衡(kafka)
  • 配置管理
  • zk 还可以存储元数据,作为多副本的服务,数据都是动态的

zookeeper 的数据模型、整体架构

  • 层级化的内存命名空间
  • 类似于文件储存系统
  • 每个几点称为znode
  • 每个znode拥有data,type,version,children和acl等属性
  • 数据访问具有原子性
数据模型
znode
  • znode的四种类型:persistent (一旦创建就不会删除), ephemeral (临时节点), persistent-sequential ,ephemeral_sequential
watcher
  • 发布订阅机制,意思就是向一个znode的注册监听,当他变化时,它会向client发送消息
  • 可通过一系列的操作设置watcher
  • 客户收到的消息有很多种
  • 一点触发监听就没有了(watcher一旦监听之后就被下线了)
session
  • client和zookeeper建立连接的通道
  • 客户端随机选择一个节点连接session,
  • session具有容错性(连接的zookeeper宕机了,client就会连接其他)
  • session 有其他事件(syncConnection exprired)
基本语法操作
image.png

zookeeper内部实现

  • 集群必须是奇数个
  • 分为leader 和 follower
  • 连接的都是client
  • 每个zk的保存的数据都是一样的
  • leader的选择用的是选举模式(paxos协议)
  • client可以访问任何一个zk节点

zookeeper 读写操作

  • 读操作在任意一个节点都是一样的,因为在任何一个节点都是一样的
  • 如果是写操作的时候,client连接的zk节点会向leader发送请求,然后leader向其他follower发送广播,然后大家一起进行写操作

zookeeper 的observer

  • 这个不参与选举
  • 只是从leader 同步数据到本地
  • observer 和 follower也被称为learner
    原因:
    1、在不要求选举的时候扩展集群
    2、部署多个zk节点

zookeeper的选举

  • zab 协议(选举的协议)

zookeeper 的leader 的工作原理

  • 如果client发送了一个更新请求,reader会先去征求follower的意见,如果大部分同意,就去操作client请求

zookeeper 的本地储存

  • zookeeper 会将操作日志存在本地磁盘(是追加写的)

zookeeper的典型应用案例

  • leader的选举(hdfs,hbase,yarn等)
    如果你的有多个服务,必须选举出一个leader,
    或者选举出了之后当有一天leader挂了,则需要用它来选举follower出另一个leader
    如果手动实现的话,将需要进行选举的服务分别创建一个等父节点的znode,谁创建的chidren的znode的编号最小 谁是leader
  • 集中式配置管理
    利用znode可以储存数据来存取配置信息,配合watcher应用更好
  • 分布式队列
  • 负载均衡
    只要应用于kafka(也是kafka依赖的主要原因)

关键问题

  • zookeeper 不一定能准时的取到最新的消息(zk采用的是最终一致性,如果想最新就需sync)
  • zookeeper 的watcher 在被监听一次就下线了,如果想再次监听必须再次注册
  • zookeeper 不能作为文件储存,因为zk储存在内存中,而且特别小
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容