ZooKeeper源码解析（五）：server端如何运行

server的启动机制：

classZooKeeperServerMain.runFromConfig

创建了连接工厂后开始启动server。

class NIOServerCnxnFactory.startup

其中start()函数会启动一个acceptThread使用reactor线程模型不断的使用Selector在serverchannel中select，一旦有请求进来就会返回一个线程处理这个请求。

class ZooKeeperServer.startup

我们来着重看一下setupRequestProcessors

这里加载了三个RequestProcessors，PrepReqiestprocessor->SyncRequestProcessor->FinalRequestProcessor，那么这些Processors有什么用呢？这里我们就需要理解ZooKeeper的请求链机制了，每一个Request请求抵达server后它需要被一个RequestProcessor 链处理后才会返回结果，这条链上的processor及其顺序是可以由server来定制的。这里只定制了三个processor我们再看看其它processor

AckRequestProcessor，将前一阶段的请求作为ACK转发给Leader。

CommitProcessor，将到来的请求与本地提交的请求进行匹配，这是因为改变系统状态的本地请求的

返回结果是到来的请求。

FinalRequestProcessor，通常是请求处理链的最后一个处理器。

FollowerRequestProcessor，将修改了系统状态的请求转发给Leader。

ObserverRequestProcessor，同FollowerRequestProcessor一样，将修改了系统状态的请求转发给

Leader。

PrepRequestProcessor，通常是请求处理链的第一个处理器。

ProposalRequestProcessor，将请求转发给AckRequestProcessor和SyncRequestProcessor。

ReadOnlyRequestProcessor，是ReadOnlyZooKeeperServer请求处理链的第一个处理器，将只读请

求传递给下个处理器，抛弃改变状态的请求。

SendAckRequestProcessor，发送ACK请求的处理器。

SyncRequestProcessor，发送Sync请求的处理器。

ToBeAppliedRequestProcessor，维护toBeApplied列表，下个处理器必须是FinalRequestProcessor

并且FinalRequestProcessor必须同步处理请求。

UnimplementedRequestProcessor，用于管理未知请求。

PrepRequestProcessor

请求被添加到一个阻塞队列，那么request最终被谁从队列中获取进行处理呢？这个processor继承了ZooKeeperCriticalThread线程类，它的run方法是这样的：

从图中可以看出，请求交由pRequest函数处理这里我们不展开了，这个函数会根据request.type也就是请求类型来执行不同逻辑，比如ping请求处理，acl请求处理，create节点请求处理

SyncRequestProcessor

它是用来将请求存入磁盘，其将请求批量的存入磁盘以提高效率，请求在写入磁盘之前是不会被转发到下个处理器的。它的processRequest方法和PrepRequestProcessor的一样，我们来看看它的run方法

FinalRequestProcessor

它不会单独开启线程处理请求，而是在processRequest中直接处理请求，逻辑和PrepRequestProcessor差不多