ZooKeeper - O'Reilly Media ----Zookeeper Internals (3)

观察者

我们已经关注了首领和跟随者的很多内容，但是这里还有第三种类型的服务器还没被讨论到：观察者。观察者和跟随者在一些方面是一样的。是他们都对首领的提议信息提交相应，但是和跟随者不同的是，观察者不会参与到我们之前讨论的选举进程中，它们只是简单的学习通过INFORM信息提交的提议。跟随者和观察者都称为学习者，因为首领都会告诉他们状态的变化。

 

         INFORM信息的原理

因为观察者不会通过投票来接受一个提议，首领不会像观察者发送提议，首观察者的信息不包括提议本身，仅仅是zxid.因此只是发送相应信息到观察者不是使得观察者能够应用这个提议。这也就是使用INFORM信息的原因，这个信息仅仅是一个包含被提交的提议的提交信息。

简单的说，跟随者会获取到两部分信息，而观察者只有一个。跟随者获取到广播的提议，然后是一个简单的ZXID的提交信息。相反的观察者只是获得了一个INFORM信息，也就是被提交的提议的内容。

 

参与到决定那些提议会被提交的投票过程中的服务器成为参与者（PARTICIPANT）。一个参与者可能是首领也可能是一个跟随者。相反的，观察服务器我们称呼为观察者。

 

观察者的一个主要原因是能够领过的对读请求进行扩展，通过增加更多的观察者，我们能够处理更多的读事务，同时不会牺牲写的吞吐量。注意到写的吞吐量是有法定人数数量来决定的。如果我们增加了更多的能够投票的服务器，会增大法定人数的数量，同时会减少写的吞吐量。然而添加观察者也不是完全没有代价的，每一个新的观察者包括增加每次提交操作的一条额外信息。这个代价比起增加可以进行投票的服务器来说小的很多。

 

观察者的另一个原因是形成一种可以孵化出多个数据中心的部署方式，跨越的散步在多个数据中心的参与者可能明显的降低系统的性能，这是由于不同数据中心连接的延迟。而使用观察者，更新操作可以在高吞吐率和低延迟的一个数据中心内完成，而通过观察者使得数据向其他数据中心传播。这样其他位置的客户端也可以使用这些数据了。注意到观察者并不消除数据中心之间的网络信息传输，因为观察者必须向首领推送更新请求和处理INFORM信息。它只是使得状态更新的提交可以在一个数据中心内完成，因为所有的参与者都是在一个数据中心内执行的。

 

服务器的框架

首领，跟随者和观察者最终都是服务器。我们实现一个服务器主要抽象就是请求处理器。一个请求处理器就是一个处理管道中不同状态的一个抽象，每一个服务器会实现细一些的请求处理器。我们可以认为每一个处理器就是增加到请求处理过程中的一个元素。当给定的请求被服务器处理管道中的所有处理器都处理完成后就可以认为该请求已经被处理完成了。

 

         请求处理器

ZooKeeper源码有一个叫做RequestProcessor的接口，这个接口的主要方法就是processRequest,输入一个Request参数。在一个请求处理器的管道中，请求处理的连续处理器通常使用对来来进行拆分，当一个处理器要向下一个处理器发送请求时，会将请求添加到队列中，该请求会一直保存到先一个处理器可以进行处理时取走。

 

独立模式的服务器

ZooKeeper中最简单的管道是独立模式的服务器（ZookeeperServer,不进行复制）。图9-6显示了该类型服务器的管道。该管道拥有三个请求处理器哦：PreRequestProcessor,SyncRequestProcessor和FinalRequestProcessor。

PreRequestProcessor接收一个客户端请求并执行，产生一个事务作为结果。重新会议一下，事务就是一个直接作用在ZooKeeper数据树上的操作的结果。事务数据以一个头和一个事务记录的格式添加到Request对象。这里要注意只有改变ZooKeeper状态的操作才会包含事务，都操作不会产生事务。对于读操作来说，Request对象中事务的属性为空。

 

下一个处理器就是SynRequestProcessor。SynReqeustProcessor负责将事务固话到硬盘，它本子上就是将事务添加到一个事务日记中和定时的生成镜像。我们下章在详细的描述硬盘的状态。

 

接下来也就是最后一个处理器是FinalRequestProcessor。当一个Request对象包含事务时，它会将这些改变应用到ZooKeeper数据树上。否则这个处理器只是读取数据树返回给客户端。

 

首领服务器

当我们切换到法定人数处理模式时，服务器的处理管道会有一定改变，我们先充首领服务器的处理管道入手，图9-77解释了首领服务器的处理管道

第一个处理器依然是PreRequestProcessor,但接下来的处理器变成了Proposal–RequestProcessor。这个处理器会产生提议并发送到跟随者。ProposalRequestProcessor将所有的请求推送到CommitRequestProcessor，同时将写操作推送到SyncRequestProcessor。

 

SynReqeustProcessor上独立模式服务器中的工作一样，将事务固话到硬盘中，然后会出发Ack-RequestProcessor，一个给生成承认并返回给自己的简单处理器。就像我们之前提到的，首领会期待法定人数中的每一个服务器返回承认，也包括自己。AckReqeustProcessor就负责处理这件事情。

 

ProposalRequestProcessor之后的另一个处理器是CommitReqeustProcessor。CommitRequestRequestProcessor会在接收到足够的承认后提交提议。承认实际上会在Leader类（Leader. ProcessAck()方法）中进行处理，会将要给提交的请求添加到CommitRequestProcessor的一个队列中。请求处理器的线程会处理这个队列。

 

接下来也就是最后一个处理器FinalRequestProcessor,该处理和单独模式中的是一样的。Final-RequestProcessor将更新请求应用到数据树和处理读请求。在FinalRequestProcessor之前，有一个简单的处理器叫ToBeAppliedRequestProcessor,即将应用的请求列表包含已经被法定人数承认，等待应用的请求，首领使用这个列表来和跟随者们进行同步，当处理承认时会将请求添加到这个列表中。ToBeAppliedRequestProcessor在FinalRequestProcessor处理完请求之后会将元素从这个列表中移除。

 

注意到只有更新请求会被增加到即将应用列表中来由ToBeAppliedRequestProcessor负责移除。ToBeAppliedRequestProcessor对于读操作来说不会执行任何操作，只是会让FinalRequest –Processor来进行处理。

 

跟随者和观察者服务器

我们接下来描述跟随者（FollowerRequestProcessor类）。图9-8显示了一个跟随者使用的请求处理器。注意到这里不是一个处理器序列，输入也有不同的格式：客户端请求，提议和响应。我们使用建通来指定跟随者采取的不同路径。

首先从FollwerRequestProcessor开始，该处理器接收并处理客户端请求。FollowerRequestProcessor将请求推送到CommitRequestProcessor,另外会将写请求推送到首领。CommitRequestProcessor将读请求直接提交到FinalRequestProcessor,而对于写请求来说，CommitRequestProcessor必须等待一个提交然后推送到FinalRequestProcessor。

 

当首领接收到一个新的写请求，直接收到或有一个学习者转发，会生成一个提议并推送到所有的跟随者。当接收到一个提议时，跟随者会发送到SyncRequestProcessor. SyncReqeustProcessor处理请求，在硬盘中进行记录然后推送到SendAckRequestProcessor。SendRequestProcesscor。SendAckReqeustProcessor承认首领的提议。当首领接收到足够的承认后就提交一个提议，发送提交信息到所有的跟随者（并发送INFORM信息到观察者）。当接收到一个提交信息，跟随者使用CommitReqeustProcessor进行处理。

 

为了保证执行的顺序会被保存下来，CommitRequestProcessor当处罚一个写请求时会暂停其他的请求。这以为着我们在其接收到一个写请求之后发送的读请求会被阻塞知道写请求通过CommitRequestProcessor。通过等待就保证了请求是按照接收到的顺序来执行的。

 

观察者服务器（ObserverZooKeeperServer服务器类）的请求处理管道和跟随者非常相像。但是由于观察者不需要承认这个提议，它不需要向首领发送承认信息或则是将事务固话到硬盘中。让观察者将事务固话到硬盘中也在讨论之中，因为这样会加快观察者的恢复。因此，可能在将来的发布版本中会有这个特性。