dreamsofa的专栏

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

本地存储 我们已经提到了事务日记和快照，还有SyncRequestProcessor就是在处理提议时写这些文件的处理器。接下来我们再在这方面深入一下。   日记和硬盘使用 回忆一下服务器使用事务日记来固话事务。在接受一个提议之前，服务器（跟随者或者是首领）会将提议中的事务固话到事务日记上，事务日记是服务器本地硬盘上的一个文件，用来按顺序的保存事务。服务器会不时的关闭当前文件，创建一个新的文

第九章 ZooKeeper Internals 本章相对于其它章有点不同，不会详细的解释如何来构建ZooKeeper应用，而是描述ZooKeeper内部是如何工作，将会在高层面来描述内部的协议，在提供高性能的同时的容错机制。本章帮助加对ZooKeeper工作的深层理解。内在的理解对计划部署ZooKeeper来说是非常重要的，因此本章也作为下一章的背景知识。   就如我们前面几章描述的，Zoo

Zab:广播状态改变 当接收到一个写请求时，跟随者会将请求推送到首领，首领解析执行请求后将执行的结果以事务的形式表现为一个状态更新广播出去。一个事务包含了一个服务器在提交该事务时必须应用到其数据数上的改变的精确集合。数据树是Zookeeper保持状态的数据结构（见DataTree）。 接下来的问题就是一个服务器如何确定一个事务是已经被提交了的。这里使用了一个叫Zab：the zookeeper