ZooKeeper学习之Observer模式及其配置

除了leader和follow模式之外，还有第三种模式：observer模式。observer和follower在一些方面是一样的。详细点来讲，他们都向leader提交proposal。但与follower不同，observer不参与投票的过程。它简单的通过接收leader发过来的INFORM消息来learn已经commit的proposal。因为leader都会给follower和observer发送INFORM消息，所以它们都被称为learner。

INFORM消息背后的原理
因为observer不会接收proposal并参与投票，leader不会发送proposal给observer。leader发送给follower的commit消息只包含zxid，并没有proposal本身。所以，只发送commit消息给observer则不会让observer得知已提交的proposal。这就是使用INFORM消息的原因，此消息本质上是一个包含了已被commit的proposal的commit消息。

简而言之，follower会得到两个消息，而observer只会得到一个。follower通过广播得到proposal的内容，接下来获得一个简单commit消息，此消息只包含了zxid。相反，observer得到一个包含了已被commit的proposal的INFORM消息。

参与了决定是否commit一个proposal的投票的server就称为PARTICIPANT server，leader和follower都属于这种server。observer则称为OBSERVER server。

使用observer模式的一个主要的理由就是对读请求进行扩展。通过增加更多的observer，可以接收更多的请求的流量，却不会牺牲写操作的吞吐量。注意到写操作的吞吐量取决于quorum的size。如果增加更多的server进行投票，quorum会变大，这会降低写操作的吞吐量。然而增加observer并不会完全没有损耗，每一个新的observer在每提交一个事务后收到一条额外的消息，这就是前面提到的INFORM消息。这个损耗比起加入follower来投票来说损耗更少。

使用observer的另一个原因是跨数据中心部署。把participant分散到多个数据中心可能会极大拖慢系统，因为数据中心之间的网络的延迟。使用observer的话，更新操作都在一个单独的数据中心来处理，并发送到其他数据中心，让其他数据中心的client消费数据。阿里开源的跨机房同步系统Otter就使用了observer模式，可以参考。

注意observer的使用并无法完全消除数据中心之间的网络延迟，因为observer不得不把更新请求转发到另一个数据中心的leader，并处理INFORM消息，网络速度极慢的话也会有影响，它的优势是为本地读请求提供快速响应。

配置
为了使用observer模式，在任何想变成observer模式的配置文件中加入如下配置：

Java代码  收藏代码

peerType=observer 

并在所有server的配置文件中，配置成observer模式的server的那行配置追加:observer，例如：

Java代码  收藏代码

server.1:localhost:2181:3181:observer