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模式的配置文件中加入如下配置:

 

peerType=observer

 

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

 

server.1:localhost:2181:3181:observer

你可能感兴趣的:(Zookeeper)