ZooKeeper-9.5 服务器的构成- 高飞网

9.5 服务器的构成

2018-06-07 17:38:05.0

    群首、追随者和观察者根本上都是服务器。在实现服务器时使用的主要抽象概念是请求处理器。每一个服务器实现了一个请求处理器的序列。

注意:请求处理器

    ZooKeeepr代码里有一个叫RequestProcessor的接口。这个接口的主要方法是processRequest,它接受一个Requst参数。在一条请求处理器的链上,对相邻处理器的处理通常通过队列现实解耦合。当一个处理器有一条请求需要下一个处理器进行处理时,它将这条请求加入队列。然后,它将处于等待状态直到下一个处理器处理完此消息。

9.5.1 独立服务器

    ZooKeeper中最简单的流水线是ZooKeeperServer,它包含了三种请求处理器:

    PreRequestProcessor接受客户端的请求并执行这个请求,处理结果则是生成一个事务。事务信息会以头部记录和事务记录的方式添加到Request对象中。同时还要注意,只有改变ZooKeeper状态的操作才会产生事务,对于读操作并不会产生任何事务。

    下一请求操作器是SyncRequestProcessor。它负责将事务持久化到磁盘上。实际上就是将事务数据追加到事务日志中,并生成快照数据。

    最后一个请求处理器是FinalRequestProcessor。如果Request中包含事务数据,该处理器将会接受对ZooKeeper数据树的修改,否则,该处理器会从数据中读取数据并返回给客户端。

9.5.2 群首服务器

    在仲裁模式时,服务器的处理器链有些不同,首先介绍群首的操作链(LeaderZooKeeperServer)。


    第一个处理器同样是PreRequestProcessor,而之后的处理器则为ProposalRequestProcessor。该处理器会准备一个提议,并将该提议发送给跟随者。ProposalReuqestProcessor将会把所有请求转发给CommitRequestProcessor,而且对于写操作请求,还会将请求转发给SyncRequestProcessor处理器。

    SyncRequestProcessor处理器所执行的操作与独立服务器中的一样,即持久化事务到磁盘上。执行完之后,触发AckRequestProcessor处理器,这个处理器是一个简单请求处理器,它仅仅生成确认消息并返回给自己。在仲裁模式下,群首需要收到每个服务器的确认消息,也包括群首自己,而AckRequestProcessor处理器就是负责这个。

    在ProposalRequestProcessor处理器之后的处理器为CommitRequestProcessor。CommitRequestProcessor会将收到足够多的确认消息提议进行提交。实际上,确认消息是由Leader类处理的(Leader.processAck()方法),这个方法会将提交的请求加入到CommitRequestProcessor类中的一个队列中。这个队列由请求处理器线程进行处理。

    下一个处理器也是最后一个为FinalRequestProcessor处理器,其作用与独立服务器一样。它处理更新类型的请求,并执行读取请求。在FinalReuqstProcessor处理器之前还有一个简单的请求处理器,这个处理器会从提议列表中删除那些待接受的提议,这个处理器叫ToBeAppliedRequestProcessor。待接收请求列表包括那些已经被仲裁法定人数所确认的请求,并等待被执行。群首使用这个列表与追随者之间进行同步,并将收到确认消息的请求加入到这个列表中。之后ToBeAppliedRequestProcessor处理器就会在FinalRequestProcessor处理器执行后删除这个列表中的元素。

    注意,只有更新请求才会加入到待接受请求列表中,然后由ToBeAppliedRequestProcessor处理器从该列表移除。ToBeAppliedRequestProcessor处理器不会对读请求进行任何额外的处理操作,而是由FinalRequestProcessor处理器进行操作。

9.5.3 追随者和观察者服务器


    FollowerRequestProcessor处理器接收并处理客户端请求。之后转发给CommitRequestProcessor,同时也会转发写请求到群服务器。它会直接转发读请求给FinalRequestProcessor,而对于写请求,会先等事务提交后,再转。




















上一篇:9.4 观察者
下一篇:9.6 本地存储