基本概念

角色

Leader:仅一台，通过选举完成，提供读写服务
Follower:参与Leader选举以及”过半写成功”策略，提供读写服务
Observer:仅提供读服务(我们有吗)

会话 session

zk对外默认端口2181，客户端启动时和zk服务器建立TCP连接，这样客户端的会话也就开始了。
客户端通过心跳检测（？？？）保持有效的会话，并且接收服务器Watch事件通知。（？？？ws这样和ss交互）
通过sessionTimeout来设置客户端会话的超时时间。

数据节点 znode

数据模型是一棵树,数据存储在内存中

分为持久节点和临时节点。
持久节点创建了之后要显式才能删除。
临时节点在客户端会话结束之后就被删除。

版本

pass

事件监听器 Watcher

zk允许用户在指定的znode上注册监听器，在特定事件触发时，zk会通知给对应的客户端。（看源码）

ACL

pass

ZAB协议

zk使用一个单一的主进程来接受并处理客户端所有事务请求，用ZAB的原子广播协议将服务器的数据状态变更以事务proposal广播给所有副本进程。

一个广播进程的好处:
1.相对于多进程互相广播通知，节省开销，更适合客户端大并发
2.更容易保证全局变更序列的顺序性

两种基本模式：崩溃恢复和消息广播

消息广播:集群中过半Follower与Leader完成同步，就进入了消息广播模式
恢复模式:服务启动或者Leader网络中断，重启等情况，进入恢复模式选举新Leader

消息广播

消息广播过程是一个原子广播协议(这是什么???),类似于2PC过程

消息广播过程中，leader会为每个事务请求生成对应的proposal来广播，分配全局单调递增的ID，即事务ID（ZXID）
要保证消息的前后顺序，就要保证Proposal按照ZXID先后顺序来处理

zxid通常是一个64位数字
高32位是Leader周期epoch编号，每次选leader时+1
低32位是计数器，每次产生proposal时+1，每次选leader时置为0

消息广播与传统2PC的不同
1.避免了follower中断，leader不用必须等待每个follower的ack
2.leader收到过半follower的ack就可提交事务了

消息广播缺陷
leader挂了或者leader失去了过半的follower，这引出崩溃恢复

崩溃恢复

解决消息广播时,leader挂了或者leader失去了过半的follower的问题

基本特性

1.leader已经commit的proposal必须被所有follower commit

Paste_Image.png

图示为leader在提交C2之后，发给follower之前挂了，那么follower也要commit c2（？？？follower怎么知道c2的）

这样避免了leader上commit了follower没有commit的数据不一致问题

2.丢弃只在leader上提出的proposal

Paste_Image.png

图示Leader提出P3就挂了，其他服务器都没收到P3，那P3就可以丢掉了(???不丢不行)

如果此时有服务器接收到了P3，那么就不能丢了

处理请求

Follow接收到请求：转给Leader(???看代码)
Leader接收到请求：生成事务proposal发起广播

算法流程

选leader

简而言之就是选取拥有最新zxid的机器成为leader
书中这一块并不清晰,比如准Leader是什么，迭代过程是怎样的

同步

Leader把初始化历史记录给各个follower让其commit

广播

崩溃回复后，各节点同步，可以开始广播

Server的三种状态：

LOOKING：当前Server不知道leader是谁，正在搜寻
LEADING：当前Server即为选举出来的leader
FOLLOWING：leader已经选举出来，当前Server与之同步

思考

zk的一致性特性如何保证的

消息广播以及崩溃恢复

zookeeper生成全局唯一的递增编号是如何实现的

ZXID

Watcher的意义

client端对感兴趣的znode绑定监听器，监听增删改之类的事件

问题

主进程广播是和谁绑定的，leader？
选leader的过程以及崩溃恢复的基本特性这个需要再考究。感觉不全面或者和看到的说法有出入

refer:

<选主流程>http://cailin.iteye.com/blog/2014486/
http://blog.csdn.net/xhh198781/article/details/10949697
《从PAXOS到Zookeeper …》