分布式协调服务的角色
担任协调者
- 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储存在内存中，而且特别小
