Zookeeper崩溃恢复过程(Leader选举)

1. 崩溃恢复

	a). leader选择过程可以保证新leader是ZXID最大的节点
	b). ZAB协议确保丢弃那些只在leader上被提出的事务，场景 leader发出PROPOSAL收到ACK，但是发出COMMIT前产生崩溃，则新的群组会丢弃这条消息

2. Leader选举过程

2.1 服务器状态

LOOKING 系统刚启动或Leader崩溃后选举状态，认为当前集群中没有leader，因此要进入选举流程
FOLLOWING 跟随者状态，角色是Follower
LEADING 领导者状态，leader
OBSERVING 观察者状态(只支持查询，不参与选举)，Observer

2.2 投票数据结构-Vote

id		被推举的Leader的SID值
zxid	被推举的Leader的事务ID
electionEpoch	逻辑时钟，用来判断多个投票是否在同一轮选举周期中。该值在服务端是一个自增序列。
				每次进入新一轮的投票后，都会对该值进行加1操作。
peerEpoch		被推举的Leader的epoch值
state			当前服务器的状态

2.3 QuorumCnxManager-Server Socket负责选举

a). 每台服务器启动时都会启动一个QuorumCnxManager--Server Socket,负责服务器之间的Leader选举过程。
b). 内部维护几个队列，每个队列又是按SID分组的队列集合
	recvQueue	选票接收队列
	queueSendMap	待发送的消息，内部按SID为每台机器分配了一个单独队列，保证互补影响
	sendWorkerMap	负责消息发送，也按SID进行了分组
	lastMesageSent	最近发送的消息，按SID进行分组
c). 建立连接, 集群中机器需要进行两两连接，规则"只允许SID大的机器主动和其它机器进行连接，否则断开连接"来防止重复连接

d). 当服务器检测到当前服务器状态变成LOOKING时，就会触发leader选举
	0).如果已存在leader，则发送选票后会被告知leader的信息，直接连接即可，不需要进行后续步骤

	1). 自增选举轮次，在FastLeaderElection实现中有一个logicalclock属性，用来标识当前Leader选举轮次，ZK规定所有投票必须
		在同一个轮次，server开始新一轮投票前会进行自增操作。

	2). 初始化选票(第一次先投票给自己)，参照前面的Vote结构
	3). 发送初始化选票

	4). zk从reeviveQueue接收外部投票
		如果zk发现自己无法获得任何投票，则马上检查是否与其他zk保持了有效连接，无则建立，并再次发送自己当前的内部投票

	5). 判断选举轮次(接收到的外部投票)
		I). 外部投票轮次大于内部投票	立即更新自己的选举轮次(logicalclock),并清空已收到的所有投票，然后使用初始化的投票来PK(第6步)
				是否变更内部投票，最终再将内部投票发送出去。
		II). 外部投票的轮次小于内部投票	zk直接忽略该投票，不做任何处理，返回步骤4
		III). 内外部轮次一致	开始选票PK
	
	6). 选票PK	比较顺序从先到后依次是  轮次 > ZXID > SID ,3种比较都是 "外部大于内部，则进行投票变更”
	
	7). 投票变更	用外部投票的信息覆盖内部投票，变更完成后，再次将这个投票信息发送出去
	
	8). 选票归档	无论是否进行了选票变更，都会将刚刚收到的那份外部投票放入选票集合"recvset"中，recvset内部按SID存在本轮次收到的所有外部投票
	9). 统计投票	完成选票归档以后，就开始统计投票。如果确定已经有超过半数的服务器认可了该内部投票，则终止投票。
			否则返回步骤4.
	
	10). 如果可以终止投票(再等待200ms来确定是否有更优的投票)，则更新服务器状态		
			首先判断投票选出的Leader是否是自己，然后更具情况更新自己状态为LEADING/FOLLOWING/OBSERVING
	
	11). 选出Leader后，所有learner向leader发送LEARNERINFO消息，等待超过半数的learner连接完成后(取他们最大的epoch当做leader的epoch值)

	12). leader向learner发送LEADERINFO消息，learner从中解析出epoch和ZXID,然后向Leader反馈一个ACKEPOCH
	
	13). Leader接收到该Learner的ACK后就开始与其进入”数据同步“环节