zookeeper知识点总结

Zookeeper简介

Zookeeper 是 Google 的 Chubby一个开源的实现，是 Hadoop 的分布式 协调 服务 service
包含一个简单的原语集，分布式应用程序可以基于它实现：
攘其外状态下

• （1：）Zookeeper: - - 个领导者(Leader) ，多个跟随者(Follower) 组成的集群。
• （2：）集群中只要有半数以上节点存活，Zookeeper集 群就能正常服务。
• （3：）全局数据一致:每个Server保存一份相同的数据副本，Client无论连接到哪个 Server，数据都是一致的
• （4：）可靠性:如果消息被其中一台服务器接受，那么将被所有服务器接收
  更新请求顺序进行，来自同一个Client的更新请求按其发送顺序依次执行。
• （5：）数据更新原子性，一次数据更新要 么成功，要么失败。不存在中间状态
• （6：）实时性，保证客户端再一定事件间隔范围内获取服务器的更新信息。

---

• 大部分分布式应用需要一个主控、协调器或控制器来管理物理分布的子进程（如资源、任务分配等）

• 目前，大部分应用需要开发私有的协调程序，缺乏一个通用的机制 协调程序的反复编写浪费，且难以形成通用、伸缩性好的协调器

-ZooKeeper：提供通用的分布式锁服务，用以协调分布式应用

-Keepalived监控节点不好管理

-Keepalive 采用优先级监控

-没有协同工作

-功能单一

-Keepalive可扩展性差

-Hadoop,使用Zookeeper的事件处理确保整个集群只有一个NameNode,存储配置信息等.

-HBase,使用Zookeeper的事件处理确保整个集群只有一个HMaster,
察觉HRegionServer联机和宕机,存储访问控制列表等.

Zookeeper特点

提供集群模式的服务

---

原子性

• 准确的反馈成功或失败

一致性

• 每个server都有统一的数据视图

可用性

• 节点故障不影响使用
• 网络分区/脑裂：过半通过
• 3台机器 挂一台 2>3/2
• 4台机器 挂2台 2！>4/2

顺序性：

• List item
• 队列FIFO

主从模型

• 一写多读

角色模型

• 集群状态（可用/不可用）
• 主从分工

攘其外：

• 统一视图
  -会话session
  -数据模型Znode
  —目录结构
  —节点类型
• 事件监听Watcher

原理：

• 原子消息广播协议ZAB
• paxos
  journalnode
  sentinel
  zookeeper  ZAB
• zxid ,myid：
• ZXID:epoch+ID

广播模式原理
恢复模式原理：无主模型：zab： zxid ,myid

应用场景

• 统一命名
• 配置管理
• 集群管理

角色模型

集群状态

• 选举模式 安其内
• 广播模式 壤其外

Server状态

• LOOKING：当前Server不知道leader是谁，正在搜寻
• LEADING：当前Server即为选举出来的leader
• FOLLOWING：leader已经选举出来，当前Server与之同步

主从分工

• 领导者（leader）
• 负责进行投票的发起和决议，更新系统状态
• 学习者（learner）
• 包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并向客户端返回结果，在选主过程中参与投票
• Observer
• 可以接受客户端连接，将写请求转发给 leader，但observer不参加投票过程，只同步leader
  的状态，observer的目的是为了扩展系统，提高读取 速度

客户端（client）

• 请求发起方

会话session

• 客户端与集群节点建立TCP连接后获得一个session 如果连接的Server出现问题，在没有超过Timeout时间时，可以连接其他节点
  同一session期内的特性不变

Session是由谁来创建的？

• Leader：产生一个唯一的session，放到消息队列，让所有server知道 （过半）

事件监听Watcher

Watcher 在 ZooKeeper 是一个核心功能，Watcher 可以监控目录节点的数据变化以及子目录的变化，一旦这些状态发生变化，服务器就会通知所有设置在这个目录节点上的Watcher，从而每个客户端都很快知道它所
关注的目录节点的状态发生变化，而做出相应的反应 可以设置观察的操作：exists,getChildren,getData
可以触发观察的操作：create,delete,setData

回调client方法
业务核心代码在哪里？

• client
  

模式：

• 恢复模式
  —无主，无服务
  —选举leader
• 广播模式
• —主从模式
  —leader维护事物的唯一和有序性
  —队列机制

广播模式

广播模式需要保证proposal被按顺序处理，因此zk采用了递增的事务id号(zxid)来保证。 所有的提议 (proposal)都在被提出的时候加上了zxid。 实现中zxid是一个64为的数字，它高32位是epoch用来标识
leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，低32位是个递增计数

恢复模式

• Leader选举：
  首先，是在一种无主的模型下
  毛遂自荐：自我投票
  需要对事实，对黑白，对正反的自我判断
• 公开、公正、公平或者说准确的选出有能力者
• 公平竞争：zxid事务id最大的持有的数据最新
• 说出事实真相：传递投票

总结：

• 攘其外

主从模型

• 消息队列
• zxid

---

• 数据模型：znode
• 事件通知：Watcher
• session

必先：快速
安其内

• 无主模型

• 选举：
  判定（zxid，myid）
  投票传递性