分布式协调服务的角色

担任协调者

• 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储存在内存中，而且特别小