ZooKeeper的10大内部原理其四：观察者

ZooKeeper的10大内部原理其四：观察者

⾄此，已经介绍了群⾸和追随者。还有⼀类没有介绍的服务器：观察者。观察者和追随者之间有⼀些共同点。具体说来，他们提交来⾃群⾸的提议。不同于追随者的是，观察者不参与我们之前介绍过的选举过程。他们仅仅学习经由INFORM消息提交的提议。由于群⾸将状态变化发送给追随者和观察者，这两种服务器也都被称为学习者。

注意：深⼊INFORM消息

因为观察者不参与决定提议接受与否的投票，群首不需要发送提议到观察者，群首发送给追随者的提交消息只包含zxid⽽不包含提议本身。因此，仅仅发送提交消息给观察者并不能使其实施提议。这是我们使用INFORM消息的原因。INFORM消息本质上是包含了正在被提交的提议信息的提交消息。

简单来说，追随者接受两种消息⽽观察者只接受⼀种消息。追随者从⼀次⼴播中获取提议的内容，并从接下来的⼀条提交消息中获取zxid。相比之下，观察者只获取⼀条包含已提交提议的内容的INFORM消息。

参与决定那条提议被提交的投票的服务器被称为PARTICIPANT服务器。⼀个PARTICIPANT服务器可以是群⾸也可以是追随者。⽽观察者则被称为OBSERVER服务器。

引⼊观察者的⼀个主要原因是提⾼读请求的可扩展性。通过加⼊多个观察者，我们可以在不牺牲写操作的吞吐率的前提下服务更多的读操作。写操作的吞吐率取决于仲裁数量的⼤⼩。如果我们加⼊更多的参与投票的服务器，我们将需要更⼤的仲裁数量，⽽这将减少写操作的吞吐率。增加观察者也不是完全没有开销的。每⼀个新加⼊的观察者将对应于每⼀个已提交事务点引⼊的⼀条额外消息。然⽽，这个开销相对于增加参与投票的服务器来说⼩很多。

采⽤观察者的另外⼀个原因是进⾏跨多个数据中⼼的部署。由于数据中⼼之间的⽹络链接延时，将服务器分散于多个数据中⼼将明显地降低系统的速度。引⼊观察者后，更新请求能够先以⾼吞吐率和低延迟的⽅式在⼀个数据中⼼内执⾏，接下来再传播到异地的其他数据中⼼得到执⾏。值得注意的是，观察者并不能消除数据中⼼之间的⽹络消息，因为观察者。必须转发更新请求给群⾸并且处理INFORM消息。不同的是，当参与的服务器处于同⼀个数据中⼼时，观察者保证提交更新必需的消息在数据中⼼内部得到交换。

ZooKeeper的10大内部原理其四：观察者

</article>