zookeeper原理解析

参考倪超 《从Paxos到Zookeeper:分布式一致性原理与实践》一书
zookeeper采用zab协议作为数据一致性的核心算法。所以我们要先去理解zab协议
zab协议的核心是定义了那些会改变zookeeper服务器数据状态的事务请求的处理方式:

所有的事务请求必须由一个全局唯一的服务器来协调处理，这个服务器被称为leader，而余下的服务器称为follower。
leader将客户端的事务请求转换为一个事务Proposal(提议)，并将改proposal分发给集群中所有的follower服务器。
之后等待所有follower服务器的反馈，一旦超过半数的服务器提供正确的反馈，leader会再次向所有的follower服务器发送commit消息，
要求将前一个proposal提交。

什么是事务请求和非事务请求？
事务请求指创建节点，更新节点，删除节点等类似的请求，笔者个人理解就是写请求。相对而言从zookeeper集群获取数据的读请求就是非事务请求。

leader选举流程



zookeeper机器的三种状态：looking，leading，following

zookeeper集群有三个角色：leader，follower，observer。

各个角色的作用如下：
leader（领导者）：事务请求的唯一调度者和处理者，保证集群事务的顺序性。更新系统状态
follower（跟随者）：用于接受客户端请求并想客户端返回结果，处理非事务请求。参与leader选举投票和proposal投票
observer（观察者）：与follower类似，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度。

zookeeper集群对于读写数据的请求处理

zookeeper集群中的每个节点都保留了一份完整的数据，也包括leader节点。
对于事务请求（写操作），leader还会创建对应的proposal提议，并发送给所有的follower进行投票，投票过半数才会提交。

写流程
客户端连接到集群中某一个节点
客户端发送写请求
服务端连接节点，把该写请求转发给leader
leader处理写请求，一半以上的从节点也写成功，返回给客户端成功。
读流程
客户端连接到集群中某一节点
读请求，直接返回。