Zookeeper运行过程与机制剖析

Zookeeper是一个分布式协调服务的开源框架。Zookeeper的层次关系叫Znode，Zookeeper可用来监测Hadoop集群中每个节点的配置文件和状态的变化，Zookeeper可将配置同步到各个节点。Zookeeper可用来做HA。

服务状态

Follower的运行状态包括：LOOKING（当前节点不知道Leader是谁，在搜寻）；LEADING（当前节点成为了Leader）；FOLLOWING（Leader已经选举出来，非Leader节点跟随，也就是与之同步状态）。

选举制度

选举Leader一般是以zxid的最大者（能力最强者），每个Server都有myid和zxid，先比较zxid，若一样比较myid（肯定不一样），选择较大者。开启时（zxid都一样），一般按myid顺序开启，假如有1，2，3，4，5个，1开启后选自己（初始化内部投票Vote(id,zxid)到内存，zxid是该节点最后一次commit的事务id），发现小于半数，向其他Server发送广播报文（包含自己的mid、zxid和状态stat），发现没有任何响应进入循环等待中，保持LOOKING状态。2开启后选自己同样计算小于半数，发送报文，1收到后比较zxid和myid，发现2较大覆盖原来的Vote，并再次广播出去。此时收到广播的统计是否有过半赞同者，若否继续循环等待，若是则找到Leader切换状态，此例计算结果否，继续LOOKING，3启动后选举广播出去，1和2收到后都比较zxid和myid后选举3并广播报文，重复上面的步骤，自己选举成功，成为Leader（状态改为LEADING），1和2都计算知道了Leader，状态改为FOLLOWING（作为追随者）。4启动后是LOOKING状态广播Vote，因为都有了Leader，其他Server收到后广播自己的Vote不再更改选举，4收到广播后计算就知道了Leader是3，于是作为Follower（FOLLOWING状态）。5同样。

正常通讯中，客户端会向连接的Server发送心跳（TCP长连接），服务端Follower会向Leader发送心跳，如果没有超过一半的Follower保持心跳，则进入选举状态。具体是当一个Follower无法给Leader发送心跳时变为LOOKING状态，开始选举自己，并告知其他Follower，待其他Follower也变为LOOKING时响应选举，过程类似上面的，这里zxid可能不一样了，先比较zxid。如果Leader无法收到超过半数Follower的心跳，则自己开始LOOKING并给其他Server发送选举内容，收到Leader选举的Follower也变为LOOKING，开始选举，下面过程类似。

选举Leader时，如果Follower过多会影响性能（参与选举者多，通讯就多。投票默认走3888端口，数据通信走2888端口），此时可以让一些Learner作为Observer（和Follower的区别是不参与选举，状态是OBSERVING）。

事务处理

读数据比较简单，客户端连接到Leader、Follower和Observer是一样的。写数据时，请求称为事务请求，所有的都会转发到Leader，Leader负责生成zxid（Zookeeper Transaction ID，事务ID）及包含zxid的Proposal（提案），然后把该Proposal广播给所有Learner（包含Follower和Observer），Learner收到Proposal后先写入事务日志，成功后回应ACK（确定）给Leader。当Leader收到过半的ACK后，开始向Learner发送Commit消息，Leader开始将事务日志写入内存，收到Commit的也会将事务日志写入内存。Learner写入内存后更新自己的Commited的zxid。

写数据时，提交的事务和客户端上一次的版本关联，提交的事务发现Znode下的数据版本号已更新，这次客户端提交的事务失败（在你提交前别人修改过了，类似乐观锁）。

客户端连接

客户端连接到Zookeeper时，可连接多个Server，可随机选一个（也可轻量级负载均衡）。连接到一个Server后客户端也会保持这个Server的最新zxid，如果下次尝试连接其他Server，发现zxid不一致会放弃这个Server选择连接其他和客户端zxid一致的Server。