观察者:在不影响写入性能的情况下扩展ZooKeeper
尽管ZooKeeper通过使客户端直接连接到该集合的投票成员而表现良好,但是此体系结构使其很难扩展到大量客户端。
问题在于,随着我们添加更多的投票成员,写入性能会下降。
这是由于以下事实:写操作需要(通常)集合中至少一半节点的同意,因此,随着添加更多的投票者,投票的成本可能会显着增加。
我们引入了一种称为Observer的新型ZooKeeper节点,该节点有助于解决此问题并进一步提高ZooKeeper的可伸缩性。
观察员是合奏的非投票成员,他们仅听取投票结果,而听不到投票结果。
除了这种简单的区别之外,观察者的功能与跟随者的功能完全相同-客户端可以连接到观察者,并向其发送读写请求。观察者像追随者一样将这些请求转发给领导者,但是他们只是等待听到投票的结果。因此,我们可以根据需要增加观察员的数量,而不会影响投票的表现。
观察者还有其他优点。
因为他们不投票,所以它们不是ZooKeeper合奏中的关键部分。
因此,它们可以在不损害ZooKeeper服务可用性的情况下发生故障或与群集断开连接。
给用户带来的好处是,观察者可以通过比跟随者更不可靠的网络链接进行连接。
实际上,观察者可以用来与另一个数据中心的ZooKeeper服务器进行对话。
观察者的客户端将看到快速读取,因为所有读取均在本地提供,并且由于缺少表决协议而需要的消息数量较小,因此写入会导致网络流量最小。
如何使用观察者
设置使用Observers的ZooKeeper集成非常简单,只需对配置文件进行两次更改即可。
首先,在要成为观察者的每个节点的配置文件中,必须放置以下行:
peerType=observer
这行告诉ZooKeeper服务器将成为观察者。其次,在每个服务器配置文件中,必须将:observer添加到每个Observer的服务器定义行。例如:
server.1:localhost:2181:3181:observer
这告诉所有其他服务器server.1是观察者,并且他们不应该期望它投票。这是将Observer添加到ZooKeeper群集所需的所有配置。
现在,您可以像普通的追随者一样连接到它。通过运行以下命令进行尝试:
$ bin/zkCli.sh -server localhost:2181
其中,localhost:2181是每个配置文件中指定的Observer的主机名和端口号。
您应该看到一个命令行提示符,通过它可以发出诸如ls之类的命令来查询ZooKeeper服务。
如何使用观察者 Master
观察者的作用很简单,就像合奏中没有投票权的成员一样,与追随者共享学习者界面,并且内部流水线稍有不同。
双方都在仲裁端口与领导者保持联系,从而通过他们了解合奏中的所有新提议。
默认情况下,观察者通过仲裁的仲裁端口连接到仲裁的负责人,这就是他们从中获悉集成中所有新提议的方式。
允许观察者连接到关注者有好处,而不是将其插入到提交流中而不是连接到领导者。
它可以将支持观察员的工作从领导者转移到其他人,而使其可以专注于协调提交的提交。
这意味着在领导者处于高负载时,尤其是在网络负载较高时(例如,当许多学习者需要同步时,在领导者选举之后可能会发生的)网络负载较高时,性能会更好。
当有大量观察者时,它减少了维护在Leader上的总网络连接。激活追随者以支持观察者可以使观察者的总数扩展到数百。
另一方面,由于大量观察者将花费更短的时间来完成同步并开始为客户端流量提供服务,因此观察者可用性得到了改善。
通过让集合的所有成员都知道跟随者将使用哪个端口来监听观察者连接,可以激活此功能。
以下条目添加到服务器配置文件后,将指示观察者在端口2191上连接到对等方(领导者和关注者),并指示跟随者创建一个ObserverMaster线程来侦听并在该端口上服务。
observerMasterPort=2191
用例范例
下面列出了观察者的两个示例用例。
实际上,无论您希望扩展ZooKeeper集成客户端的数量,还是希望将集成的关键部分与处理客户端请求的负载隔离开的地方,观察者都是一个不错的体系结构选择。
(1)作为数据中心的桥梁
在两个数据中心之间形成ZK集成是一个有问题的工作,因为数据中心之间的延迟高差异可能导致错误的故障检测和分区错误。
但是,如果该集成完全在一个数据中心中运行,而第二个数据中心仅运行观察者,则分区不会出现问题,因为该集成仍然保持连接状态。观察员的客户可能仍会看到并发布建议。
(2)作为到消息总线的链接
一些公司表达了将ZK用作持久可靠消息总线组件的兴趣。
观察者会为此工作提供一个自然的整合点:可以使用插件机制将观察者看到的建议流附加到发布-订阅系统,而又不会加载核心组件。
参考资料
https://zookeeper.apache.org/doc/r3.6.2/zookeeperObservers.html