Zookeeper基本概念及灵魂Paxos(分布式一致性算法)

ZK的两个状态

可用状态，不可用状态。ZK号称200ms即可快速选出新主的高可用性

ZK的角色

Leader，Follower，Observer。为了可以快速选主，主从角色要小，查询角色可以很多。ZK重点是在读取上，而不是写

ZK节点

ZK节点类文件系统的形式，包括持久节点，临时节点，序列节点。

ZK的特征及保障

ZK相关id

cZxid,mZxid,pZxid分别时创建，修改，最后一次操作的事务id,前32位代表的是主节点的纪元。后面的位数记录操作次数

ZK的灵魂-Paxos

Paxos被认为是到目前为止唯一的分布式一致性算法，其它的算法都是Paxos的改进或简化。Paxos有一个前提：没有拜占庭将军问题。就是说Paxos只有在一个可信的计算环境中才能成立，这个环境是不会被入侵所破坏的。

基础约定：
1、节点总数一定
2、消息id只能增长，不能后退
3、消息超过半数恢复才可以生效
4、节点只承认消息id,比自身id大的消息。比自身id小直接拒绝
消息发布：
1、消息发布，当节点发现消息id大于自身时，向所有节点发送
2、超过半数，消息生效
（暗含2PC提交）
消息发布冲突：
1、三个节点a,b,c
2、a节点发布消息1，b节点发布消息2，结果c节点首先收到了a节点的消息。
3、达到半数通过，消息1生效
4、b节点消息2，发送到c节点。c节点看到id比自身小，拒绝了该消息
5、b节点可以向a,c节点，首先同步消息1，之后再发布一次消息2

Paxos与ZK

转自：Zookeeper全解析——Paxos作为灵魂

ZAB原子广播协议，数据可靠，可用一致性

朴实的原理概述：队列+2PC
作用在可用状态，并且有leader时
原子性：成功或者失败，没有中间状态
广播：分布式多节点，所有节点都知道该状态

1、create(ooxx),客户端向F1发起创建请求
2、create(ooxx),F1向Leader发送创建请求
3、Leader创建事务ID，Zxid:9
4-1:log，绿色的线。Leader向F1，F2发送日志
4-1：ok,F1返回ok,F2未返回。但是超过半数
4-2：write Leader向F1，F2写入数据（F2在进行操作完之后，最终也会执行队列中的4-2write操作，达成最终一致性）
之后Leader返回F1 ok,F1返回客户端OK

如果有client调用F2,可以调用sync同步leader消息。如果不调用，可能获得到旧的数据

Leader快速恢复原理

1、第一次启动集群，过半后，直接需选举id最大的成为Leader
2、leader挂了之后。 最先发现集群挂的节点n3，向其他节点发送leader挂了的消息，并且把自身的id和事务id发送过去。
其他的节点收到消息后，返回n3。如果其他节点发现事务id小于自身，驳回。
其他节点在收到消息并回复后，自身事务id被动+1，并且也给其他节点发送自身id和事务id。
其他节点发现该节点的id和事务id比自己大时，会给他投票。该节点时被动的接受票

（1、基于选举管道的两两通信
2、任意一个节点，都可以触发准leader对其他节点发布自身的，使他被动成为leader
3、推选制，比较Zxid，如果一致，比较myid）

watch callback

1、不需要client之间进行心跳验证，使用watch
2、首先get节点，之后watch该节点，在client1挂掉后，可以将事件回调给client2