zookeeper

定义

开源的分布式协调服务，主要用于:数据订阅发布，集群管理，配置管理，分布式锁。

工作机制

• 服务端工作模式分为单机模式(standalone),仲裁模式(quorum)
• 客户端每次连接一台zk服务端进行操作
• 服务端与客户端交互，通过Session完成，session有其生命周期
• zookeeper操作的数据结构为树，树的节点分为临时节点与持久化节点

理解（难点）

从应用的角度而言，将关键数据抽离成第三方，已经达到了摆脱单机局限性的问题，但是如何保证抽离成的第三方本身继续摆脱单机局限性，大概便是它要处理的问题

• 解决集群(的数据)一致性的问题,无集群，失去其意义；
• 树型数据结构
• 数据与Session会话挂钩

数据一致性问题

ZAB协议

• Zookeeper基于paxos专门设计的一种支持崩溃恢复的原子广播协议;
• 通过该协议，zk基于主从模式的系统架构，来保持集群中各个副本之间数据的一致性;
• 两阶段提交:
  • 所有的事物，必须由唯一的Leader服务来处理，Leader将事物请求，转为为事务Proposal,并将该事务Proposal分发给所有的Follower服务器
  • 如果有半数的Follower服务器，进行了正向的反馈，则Leader就会像所有的Follower服务器发出Commit消息,要求将前一个Proposal进行提交;

ZAB协议的两种基本模式

• 崩溃恢复
  • 服务框架在首次启动时，触发
  • Leader服务器出现异常时，触发
  • 过半选举机制，选取新的Leader,其它及其从新的Leader上同步状态,过半机器同步完成后，进入消息广播;
• 消息广播
  • Leader服务器，对每个事务请求生成对应的Proposal,为器分配一个全局唯一的递增事务ID，再对其广播
  • Leader服务器为每一个Follower服务器，分配一个单独的队列,将Proposal一次放入，并根据FIFO策略进行消息发送
  • Follower接收到Proposal后，将其以事务日志的形式，写入本地磁盘，并反馈给Leader一个Ack响应;
  • Leader服务器收到超过半数Follower的Ack响应后，广播一个Commit消息给所有的Follower通知事务提交;
  • 每一个Follower，接收到Commit消息后，完成事务提交;

客户端如何与服务端协作

• 读请求
  • Leader、Follower、Observer均可以处理
• 写请求
  • Leader直接处理写请求：两阶段提交过程，只要有半数的节点写完了，就往客户端发送确认通知，之后的节点由leader逐个通知;
  • Follower、Observer接收到写请求，Follower将该写请求发送给Leader
  • Leader发送消息通知,经过后续的协商过程后，向Follower发送确认通知，Follower向客户端发送确认通知;

数据结构问题

数据结构性质

• 与Unix文件系统相似,整体上可以看作一棵树;
• 每个节点称作ZNode,每个ZNode默认能够存储1MB的数据
• 只能用绝对路径定位节点，而不能使用相对路径
• 节点分为临时节点、持久节点、有序节点三种，临时节点不允许有子节点，其子节点属性始终为null

数据结构存储

• 数据日志: 存储运行日志
• 快照文件： 用来存储ZooKeeper服务中的事务性操作日志,通过数据快照文件实现集群之间的数据同步功能。
  • zookeeper处理来自客户端的事务性会话请求时，首先在服务器内存中生成本次会话的数据快照,当集群可以执行该事务请求时，提交该请求，并将数据快照持久化到本地磁盘中。
  • 存储到本地磁盘的数据快照文件，是二进制格式，无法直接查看，可通过自带的SnapshotFormatter实现查看.