zookeeper应用场景 & 源码部分分析 & zab 协议

数据发布订阅/ 配置中心

实现配置信息的集中式管理和数据的动态更新

实现配置中心有两种模式：

push：服务器主动将数据的更新发送给客户端

pul：客户端主动去发起请求去获取新的配置数据

长轮训

通过http请求建立一个长轮训的机制，客户端主动去监控服务的配置的变化，发生变化后主动将配置拉取到本地

zookeeper采用的是推拉相结合的方式

客户端向服务器端注册自己需要关注的节点。一旦节点数据发生变化，那么服务器端就会向客户端发送watcher事件通知。客户端收到通知后，主动到服务器端获取更新后的数据

一般客户端都会维护一个类似properties的配置文件，客户端第一次项目启动时会主动去服务端 pull 所关注的配置信息，并生成一个缓存文件保存到本地，后续有配置更新时再去更新之前的配置文件，客户端依赖的配置都是从缓存文件中读取，防止每次启动服务再pull，提高效率

配置数据特征：

1. 数据量比较小
2. 数据内容在运行时会发生动态变更
3. 集群中的各个机器共享配置

     

 

负载均衡

请求/数据分摊多个计算机单元上

分布式锁

通常实现分布式锁有几种方式

• redis setNX 命令实现

• 数据库方式实现

创建一个表， 通过索引唯一的方式

create table (id , methodName …)   methodName 增加唯一索引

insert 一条数据 methodName == XXX 成功的获取锁，失败的等待或者返回，释放锁则使用delete 语句删除这条记录，如果出现delete失败会导致后面所有的进程都无法获取到锁

mysql for update innerDB 引擎，设置行锁，这种属于独占锁

• zookeeper实现

排他锁，A/B/C 三个客户端都去 Locks创建一个临时子节点，成功则获取到锁，其他客户端等待

     

 

共享锁（读锁）

     

 

实现共享锁，使用java api的方式

命名服务

master选举

7*24小时可用， 99.999%可用

master-slave模式

使用zookeeper解决

分布式队列

zookeeper集群角色

leader

leader是zookeeper集群的核心。

1. 事务请求的唯一调度者和处理者，保证集群事务处理的顺序性
2. 集群内部各个服务器的调度者

follower

1. 处理客户端非事务请求，以及转发事务请求给leader服务器
2. 参与事务请求提议（proposal）的投票（客户端的一个事务请求，需要半数服务器投票通过以后才能通知leader commit； leader会发起一个提案，要求follower投票）
3. 参与leader选举的投票

observer

观察zookeeper集群中最新状态的变化并将这些状态同步到observer服务器上

增加observer不影响集群中事务处理能力，同时还能提升集群的非事务处理能力

zookeeper的集群组成

zookeeper一般是由 2n+1台服务器组成

leader选举

leaderElection/AuthFastLeaderElection/FastLeaderElection

QuorumPeer   startLeaderElection

源码分析

源码地址：https://github.com/apache/zookeeper.git

需要的条件： jdk 1.7以上 、ant 、idea

FastLeaderElection

serverid : 在配置server集群的时候，给定服务器的标识id（myid）

zxid  : 服务器在运行时产生的数据ID， zxid的值越大，表示数据越新

Epoch: 选举的轮数

server 的状态：Looking、 Following、Observering、Leading

第一次初始化启动的时候： LOOKING

1. 所有在集群中的server都会推荐自己为leader，然后把（myid、zxid、epoch）作为广播信息，广播给集群中的其他server, 然后等待其他服务器返回
2. 每个服务器都会接收来自集群中的其他服务器的投票。集群中的每个服务器在接受到投票后，开始判断投票的有效性
   1. 判断逻辑时钟(Epoch) ，如果Epoch大于自己当前的Epoch，说明自己保存的Epoch是过期。更新Epoch，同时clear其他服务器发送过来的选举数据。判断是否需要更新当前自己的选举情况
   2. 如果Epoch小于目前的Epoch，说明对方的epoch过期了，也就意味着对方服务器的选举轮数是过期的。这个时候，只需要讲自己的信息发送给对方

 

ZAB协议

拜占庭问题

paxos协议主要就是如何保证在分布式环网络环境下，各个服务器如何达成一致最终保证数据的一致性问题

ZAB协议，基于paxos协议的一个改进。

zab协议为分布式协调服务zookeeper专门设计的一种支持崩溃恢复的原子广播协议

zookeeper并没有完全采用paxos算法， 而是采用zab Zookeeper atomic broadcast

zab协议的原理

• 崩溃恢复

• 原子广播

1. 在zookeeper 的主备模式下，通过zab协议来保证集群中各个副本数据的一致性
2. zookeeper使用的是单一的主进程来接收并处理所有的事务请求，并采用zab协议，把数据的状态变更以事务请求的形式广播到其他的节点
3. zab协议在主备模型架构中，保证了同一时刻只能有一个主进程来广播服务器的状态变更
4. 所有的事务请求必须由全局唯一的服务器来协调处理，这个的服务器叫leader，其他的叫follower

leader节点主要负责把客户端的事务请求转化成一个事务提议（proposal），并分发给集群中的所有follower节点，再等待所有follower节点的反馈。一旦超过半数服务器进行了正确的反馈，那么leader就会commit这条消息

zab协议的工作原理

什么情况下zab协议会进入崩溃恢复模式

1. 当服务器启动时
2. 当leader服务器出现网络中断、崩溃或者重启的情况
3. 集群中已经不存在过半的服务器与该leader保持正常通信

zab协议进入崩溃恢复模式会做什么

1. 当leader出现问题，zab协议进入崩溃恢复模式，并且选举出新的leader。当新的leader选举出来以后，如果集群中已经有过半机器完成了leader服务器的状态同（数据同步），退出崩溃恢复，进入消息广播模式
2. 当新的机器加入到集群中的时候，如果已经存在leader服务器，那么新加入的服务器就会自觉进入数据恢复模式，找到leader进行数据同步

问题

假设一个事务在leader服务器被提交了，并且已经有过半的follower返回了ack。 在leader节点把commit消息发送给folower机器之前leader服务器挂了怎么办？

zab协议需要保证 已经被leader提交的事务也能够被所有follower提交

zab协议需要保证 在崩溃恢复过程中跳过哪些已经被丢弃的事务