zookeeper

http://stblog.baidu-tech.com/?p=1164

用于分布式下一致性相关问题的解决方案。可以理解为由集群组成的可靠的单master。可将传统方案中的master使用zookeeper代替，且不用担心单点问题。

应用场景：树状结构的命名服务、节点数据变更的消息通知、分布式共享锁、配置数据的集中存放、集群中节点机器的状态管理及状态变更通知

zookeeper实现分布式锁：通过zookeeper的节点状态进行条件判断，如果不满足，则在客户端本地加锁等待Object.wait()。利用zookeeper的实时通知机制，当zookeeper的节点满足条件状态时，客户端会同步获得通知，然后在本地解锁Object.notifyAll()。从而实现了分布式加锁、阻塞、解锁。

三类角色： leader（处理写请求，单点）、follower（处理客户端请求，参与投票）、observer（不投票，只处理客户端请求）

恢复模式：服务重启或者leader宕机后，通过paxos算法，从follower中重新选出leader，并以leader为准，进行数据同步。此时服务不可用。

paxos选举算法：

1、每次选举，都是针对某个txid（transaction id）进行。

2、每个follower首先广播询问，获取其它所有server的txid、提议value，txid必须相同，value存储到提议列表中

3、follower从提议列表中获取value，如果这个value被大于一半的follower支持，则直接使用此value，否则，继续发出广播询问。并且将此value作为回答其它follower轮训的提议。

4、循环执行3，直到收敛

paxos的精髓：解决了集群中，非全联通情况下的一致性问题。对于正常全联通情况，每台机器只需要广播获取其它各台机器的数据，然后比较获取最大值即可。这样各个节点得到的结论应该是一样的。问题在于，某些节点之间是不联通的。于是某个节点无法获知全局数据，只能通过paxos中循环投票，收敛至全局最优解。

同步流程：选举完成后，各个follower向leader发送同步请求，带上自己的最大zxid。leader通过zxid确定同步点，将这之后的commit log交给follower进行同步。所有节点都保存一份系统状态数据，非强一致（getData不保证最新数据，可以先sync一下保证数据的同步状态），有同步延时。

多节点可读可写，部分节点延时同步，最终一致性。follower和observer负责监听客户请求和处理读请求。对于所有写请求，都一律转发至leader进行选举和数据同步。observer不参与投票，只做数据同步，提高写请求的效率。