【zookeeper】

功能：是一个分布式协调服务，可用于服务发现，分布式锁，分布式领导选举，配置管理等。

Zookeeper 提供了一个类似于Linux 文件系统的树形结构（可认为是轻量级的内存文件系统，但只适合存少量信息（纯内存数据），完全不适合存储大量文件或者大文件），同时提供了对于每个节点的监控与通知机制。

 

zk集群必须部署奇数台：选举需要，zookeeper中的过半机制保证了zookeeper集群的数据一致性。

leader选举算法采用了paxos协议：：当多数server写成功，则任务数据写成功。如果有3个server则2个写成功即可，当有4个或5个server，则3个写成功即可。

 

角色划分：
　　Leader：支持读写，唯一支持写的节点，              

　　　　它会发起并维护与各Follwer及Observer 间的心跳。所有的写操作必须要通过Leader 完成再由Leader 将写操作广播给其它服务器。只要有超过半数节点（不包括observeer 节点）写入成功，该写请求就会被提交（类 2PC 协议）。

　　Follower：只读，支持选举

　　　　存在多个Follower，它会响应Leader 的心跳

　　　　Follower 可直接处理并返回客户端的读请求，同时会将写请求转发给Leader 处理；

　　　　负责在Leader 处理写请求时对请求进行投票。

　　Observer：只读，无选举权

　　　Zookeeper 需保证高可用和强一致性，为了支持更多的客户端，需要增加更多Server； Server增多，投票阶段延迟增大，影响性能；引入Observer，Observer 不参与投票； Observers 接受客户端的连接，并将写请求转发给leader 节点； 加入更多Observer 节点，　　提高伸缩性，同时不影响吞吐率。

 

数据同步ZAB协议：实现分布式数据一致性

• 消息广播：
  • Zookeeper 使用单一的主进程 Leader 来接收和处理客户端所有事务请求；
  • 采用 ZAB 协议的原子广播协议，将事务请求以 Proposal 提议广播到所有 Follower 节点，当集群中有过半的Follower 服务器进行正确的 ACK 反馈，那么Leader就会再次向所有的 Follower 服务器发送commit 消息，将此次提案进行提交。这个过程可以简称为 2pc 事务提交，整个流程可以参考下图，注意 Observer 节点只负责同步 Leader 数据，不参与 2PC 数据同步过程。

• 崩溃恢复：重新选择Leader

　　　　但是一旦 Leader 服务器出现崩溃，或者由于网络原理导致 Leader 服务器失去了与过半 Follower 的通信，那么就会进入崩溃恢复模式，需要选举出一个新的 Leader 服务器。在这个过程中可能会出现两种数据不一致性的隐患，需要 ZAB 协议的特性进行避免。

• • Leader 服务器将消息 commit 发出后，立即崩溃
  • Leader 服务器刚提出 proposal 后，立即崩溃

　　　　ZAB 协议的恢复模式使用了以下策略：

　　　　　　1、选举 zxid 最大的节点作为新的 leader

　　　　　　2、新 leader 将事务日志中尚未提交的消息进行处理

集群脑裂问题：

　　　　

使用约束：

 

zNode：

　　zNode存储数据量较小：通常不大于1M

　　有四种形式的目录节点

　　　　1. PERSISTENT：持久的节点。

　　　　2. EPHEMERAL：暂时的节点。

　　　　3. PERSISTENT_SEQUENTIAL：持久化顺序编号目录节点。

　　　　4. EPHEMERAL_SEQUENTIAL：暂时化顺序编号目录节点。

---

 

应用：分布式锁原理，参考：https://www.runoob.com/w3cnote/zookeeper-locks.html

    

应用：服务注册：