ZooKeeper 篇

概念

分布式应用程序的分布式协调服务。基于公开的简单原语可以实现更高级别的同步、配置维护、组和命名服务。

架构图

一主多从，更新数据首先更新到主节点，在同步到从节点，可在任意节点读取数据

数据模型和分层命名空间

ZooKeeper 提供的命名空间很像标准文件系统。名称由斜杆（/）分隔的一系列路径元素，每个节点都由路径标识。与为存储而设计的典型文件系统不同，ZooKeeper数据保存在内存中

特性

• 顺序一致性 - 来自客户端的更新将按照它们的顺序应用
• 原子性 - 更新成功或者失败。没有部分结果。
• 统一视图 - 无论客户端连接到哪个服务器，都将看到相同的视图
• 可靠性 - 应用一旦更新，它将持续到客户端覆盖更新
• 及时性 - 系统的客户视图保证在一定时间范围是最新的

节点

• 持久节点（有序、无序）
• 临时节点（有序、无序）
• 节点存储
  
  Zxid(64位) = epoch（32位） + 事务ID（32位）
  cZxid -> 创建的IDmZxid -> 修改的ID
  PZxid -> 当前目录下最大的创建ID
  ephemeralOwner -> 临时节点下存储的session

集群

• 集群搭建
  service.id（myid） = ip：port（通信端口）：port（选举端口）
• 集群角色
  leader 处理事务请求
  follower 处理读请求，转发事物请求，参与选举投票
  observice 不参与选举投票的follower，协助follower处理更多的客户端请求
• 集群事务
  基于改进版的2PC，半数通过则提交

paxos

基于消息传递的一致性算法
paxos解析

ZAB 协议

Zookeeper专门设计的一种支持崩溃恢复的原子广播协议

• 崩溃恢复模式 - 选举Leader + 恢复数据
  照成原因
  （1）leader 失去过半节点的联系
  （2）leader 挂了
  投票机制
  每次投票传入（myid，zxid，epoch）
  myid 服务器id
  Zxid(64位) = epoch（32位） + 事务ID（32位）
  epoch 朝代，每次选举后 + 1
  （1）优先检查zxid，越大优先为leader
  （2）zxid相同，比较myid大小，越大优先为leader

• 消息广播模式 - 数据同步
  

2pc + 队列 + 多数成功

watch

客户端先向Zookeeper服务端成功注册想要监听的节点状态，同时客户端本地会存储该监听器相关的信息在WatchManager中，当Zookeeper服务端监听的数据状态发生变化时，Zookeeper就会主动通知发送相应事件信息给相关会话客户端，客户端就会在本地响应式的回调相关Watch的Handler。

分布式锁

临时顺序节点 + watch，最小的获取锁，后面的节点watch前一个节点，一旦最小的释放了锁，只给第二个节点发事件回调

官方网站
漫画：如何用Zookeeper实现分布式锁？
漫画：什么是ZooKeeper？
思维导图地址