Zookeeper观察者


观察者:在不影响写入性能的情况下缩放Zookeeper

虽然客户端直接连接到投票选举的Zookeeper成员执行良好,但这个架构很难扩展到大量的客户端。问题就是因为我么添加了更多的投票成员,写入性能下降。这是由于这样的事实:一个写入操作要求共识协议至少是整体的一半,因此投票的成本随着投票者越多会显著增加。

我们引入了一个新的Zookeeper节点类型叫做Observer,它帮助处理这个问题并进一步完善了Zookeeper的可扩展性。观察者不参与投票,它只监听投票的结果,不是导致了他们的共识协议。除了这个简单的区别,观察者精确的和追随者一样运行 - 客户端可能链接他们并发送读取和写入请求。观察者像追随者一样转发这些请求到领导者,而他们只是简单的等待监听投票的结果。正因为如此,我们可以尽可能多的增加观察者的数量,而不影响投票的性能。

观察这还有其他优势。因为他们不投票,他们不是Zookeeper整体的主要组件。因此他们可以故障,或者从集群断开连接,而不影响Zookeeper服务的可用性。对用户的好处是观察者可以连接到比追随者更不可靠的网络。事实上,观察者可以用于从其他数据中心和Zookeeper服务通信。观察者的客户端会看到快速的读取,因为所有的读取都在本地,并且写入导致最小的网络开销,因为投票协议所需的消息数量更小。

怎么使用观察者

使用观察者设置Zookeeper全员非常简单,只需要在原来的配置文件上改两个地方。第一,每个节点的配置文件设置为观察者,必须放置这一行:

peerType=observer

这一行告诉Zookeeper的服务是一个观察者。第二,在每个服务配置文件里,必须在观察者定义行添加:observer。例如:

server.1:localhost:2181:3181:observer

这个告诉其他服务server.1是一个观察者,并且他们不需要期望他选举。这是你在Zookeeper集群中添加观察者需要的所有配置。现在你可以连接到它好像是一个普通的追随者。尝试一下,通过运行:

bin/zkCli.sh -server localhost:2181

这里的localhost:2181是每个配置文件里指定的观察者的hostname和端口号。你应该查看一个命令行提示,通过类似于ls的操作查询Zookeeper服务。

用户实例

两个观察者用户实例在下面列出。事实上,无论你希望在哪里扩展Zookeeper全员的客户端数量,或你希望根据客户端需求负载隔离整体的关键部分,观察者是一个非常好的架构选择。

  • 作为数据中心的桥梁:在两个数据中心之间形成ZK整体是一个问题,因为在数据中心之间的高延迟可能导致假性故障检测和分区。然而如果整体完全运行在一个数据中心,并且第二个数据中心只运行观察者,分区不是问题,因为全员保持连接。观察者的客户端可以维持看到并提出建议。
  • 作为连接到消息总线:有些公司表示喜欢用ZK作为持续可靠的消息总线的组件。观察者给出一个自然集成的:一个插件机制可以用于观察者发布-订阅系统,而没有加载核心。

 

马军伟
关于作者 马军伟
写的不错,支持一下

先给自己定个小目标,日更一新。