zookeepe - 写数据 - cluster(7)

概述

    本文的主要目的是分析zookeeper的整个数据写入过程,相信大家或多或少都听说过zookeeper是一个集中式的单点写入过程,所有的写入请求都会转发到Leader来完成数据的写入过程,而且在整个写入过程当中会涉及到二次提交(proposal/commit)过程,希望通过这篇文章能够帮助感兴趣的人建立一个整体的流程印象。

    延伸阅读关于Paxos的协议可以阅读延伸的文章《拜占庭将军问题》,其实zookeeper的二阶段提交就是这个模型的实现,公式证明看不懂但是思路可以看得懂。

    最后整个文章读起来比较费力,如果有兴趣真正搞懂整个写入过程,还是需要抽出一整块时间来阅读的,我本人这篇文章从理清楚过程到画图大概花了一个星期左右,这还是建议阅读别人的文章的基础上的,参考文章中列出的几篇文章还是非常不错的,可以相互补充着来看,因为整个过程涉及的代码太多了,所以就建议大家看参考文献中的文章吧,虽然有一些小出入但是整体来说是非常全面的。

    zookeeper中涉及的事务操作主要包括下面几大类:

        1)写操作(OpCode.create,OpCode.delete,OpCode.setData,OpCode.setACL)

        2)Session的创建和关闭操作(OpCode.createSession和OpCode.closeSession)

        3)OpCode.multi操作。

过程分析

    在正式进入过程分析之前,先得有一个宏观的印象,那就是zookeeper的写入过程当中,当我们连接的是Follower的对象的时候,写入会转发到Leader,最后由Leader完成写入并同步到所有Follower当中,Follower是不具备处理数据写入功能,Follower其实只是对写入的一个转发而已,从下面这个图片就可以看明白了。

《zookeepe - 写数据 - cluster(7)》 数据写入过程

    另外,在zookeeper的FollowerZookeeperServer和LeaderZookeeperServer当中,都有一个调用链的概念,在接收报文后会通过调用链进行处理后回送报文,其中leader端和Follower端的调用链是有区别的,具体差别就是下图的样子。

《zookeepe - 写数据 - cluster(7)》 Leader调用链
《zookeepe - 写数据 - cluster(7)》 Follower调用链

    在整个交互过程中比较核心的两类报文,Request对象是调用链处理过程中传输的对象,QuoromPacket是follower和leader交互过程涉及的报文。

《zookeepe - 写数据 - cluster(7)》 Request报文

《zookeepe - 写数据 - cluster(7)》 QuorumPacket报文

整个核心的数据写入过程都在下面这个图当中,核心的关注点要关注几个角色之间交互报文以及两阶段提交过程。

《zookeepe - 写数据 - cluster(7)》 zookeeper写入过程

下面过程分析的数字编号不是对应上图当中的编号,而是宏观上按顺序把整个过程进行分解,当然每个过程都是可以在上图中找到对应的连接线的(源码层面可以看ZooKeeper源码分析:Quorum请求的整个流程)。

    1、client向follower发送packet报文,然后进入follower的消息处理链当中,也就是FollowerRequestProcessor当中。

    2、Follower的处理过程:FollowerRequestProcessor做两个事情:负责沿着调用链处理也就是执行CommitProcessor当中,在这个时候follower的处理就暂时停留在了CommitProcessor当中;负责将报文通过follower.request()发送到leader当中,此时报文的type为Leader.REQUEST

    3、Leader的处理过程:Leader端由LearnerHandler(负责和follower建立的连接)进行处理,核心处理逻辑其实就两个:逻辑一依次通过调用链PrepRequestProcessor -> ProposalRequestProcessor->SyncRequestProcessor(CommitProcessor),其中CommitProcessor其实处理到一半没有继续往下执行;逻辑二是PrepRequestProcessor -> ProposalRequestProcessor->发送Leader.PROPOSAL报文给Follower。

    4、Follower的处理过程:Follower在接收到Leader的Proposal报文以后,通过调用链SyncRequestsProcessor->SendAckRequestProcessor发送Leader.ACK报文给Leader。

    5、Leader的处理过程:Leader在收到Follower的ack报文以后,会判断是否超过半数已经回复了相应报文,也就是对应的tryToCommit的处理逻辑,里面其实就是判断是否超过半数的follower回复了,如果超过半数回复了那么就进入了第二个阶段(Commit/Inform)阶段发送给Follower,当然leader本身会在之前的CommitProcessor当中继续操作(也就是在步骤3当中执行到一半的过程),沿着调用调用CommitProcessor->ToBeAppliedRequestProcessor->FinalRequestProcessor完成数据的写入。

    6、Follower收到Leader.COMMIT/INFORM报文之后开始进行数据的持久化,并将响应报文发送给client,整个过程就结束了。

参考文章

    ZooKeeper学习之server端实现的基本骨架

    ZooKeeper源码分析:Quorum请求的整个流程

    ZooKeeper 核心模块代码浅析

    原文作者:晴天哥_374
    原文地址: https://www.jianshu.com/p/79f3dafc09cf
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞