Observers: Scaling ZooKeeper Without Hurting Write Performance

Posted 2022-12-09 徐同学呀

文章目录

• • Observers: Scaling ZooKeeper Without Hurting Write Performance
  • How to use Observers
  • How to use Observer Masters
  • Example use cases

Observers: Scaling ZooKeeper Without Hurting Write Performance

观察者: 在不影响写性能的情况下扩展 ZooKeeper

Although ZooKeeper performs very well by having clients connect directly to voting members of the ensemble, this architecture makes it hard to scale out to huge numbers of clients. The problem is that as we add more voting members, the write performance drops. This is due to the fact that a write operation requires the agreement of (in general) at least half the nodes in an ensemble and therefore the cost of a vote can increase significantly as more voters are added.

虽然 ZooKeeper 通过让客户直接连接到整体中有投票权的成员而表现得非常好，但是这种架构使得它很难扩展到大量的客户。问题是，随着我们添加更多的投票成员，写作性能下降。这是因为写操作需要集合中至少一半节点的同意，因此随着更多选民的加入，投票成本会显著增加。

We have introduced a new type of ZooKeeper node called an Observer which helps address this problem and further improves ZooKeeper’s scalability. Observers are non-voting members of an ensemble which only hear the results of votes, not the agreement protocol that leads up to them. Other than this simple distinction, Observers function exactly the same as Followers - clients may connect to them and send read and write requests to them. Observers forward these requests to the Leader like Followers do, but they then simply wait to hear the result of the vote. Because of this, we can increase the number of Observers as much as we like without harming the performance of votes.

我们引入了一种新型的 ZooKeeper 节点，称为 Observer，它有助于解决这个问题并进一步提高 ZooKeeper 的可伸缩性。观察员是集体的无表决权成员，他们只听取投票结果，而不听取达成协议的协议。除了这个简单的区别之外，观察者的功能与跟随者完全相同——客户端可以连接到他们，并向他们发送读写请求。观察者像追随者那样将这些请求转发给领导者，他们只是等待投票结果。正因为如此，我们可以随心所欲地增加观察员人数，同时又不影响投票结果。

Observers have other advantages. Because they do not vote, they are not a critical part of the ZooKeeper ensemble. Therefore they can fail, or be disconnected from the cluster, without harming the availability of the ZooKeeper service. The benefit to the user is that Observers may connect over less reliable network links than Followers. In fact, Observers may be used to talk to a ZooKeeper server from another data center. Clients of the Observer will see fast reads, as all reads are served locally, and writes result in minimal network traffic as the number of messages required in the absence of the vote protocol is smaller.

Observers 还有其它优势。因为他们不投票，所以他们不是动物园管理员合唱团的重要成员。因此，它们可以失败，或者断开与集群的连接，而不会影响 ZooKeeper 服务的可用性。对用户的好处是，观察者可以连接比追随者更不可靠的网络链接。事实上，观察者可能被用来与另一个数据中心的 ZooKeeper 服务器进行对话。观察者的客户端能够快速读取，因为所有的读取都是在本地完成的，写入的结果是最小的网络流量，因为在没有投票协议的情况下所需的消息数量较少。

How to use Observers

Setting up a ZooKeeper ensemble that uses Observers is very simple, and requires just two changes to your config files. Firstly, in the config file of every node that is to be an Observer, you must place this line:

设置一个使用 observer 的 ZooKeeper 集成非常简单，只需要对配置文件做两处修改。首先，在每个要成为观察者的节点的配置文件中，你必须放置下面这行:

peerType=observer

This line tells ZooKeeper that the server is to be an Observer. Secondly, in every server config file, you must add :observer to the server definition line of each Observer. For example:

这一行告诉 ZooKeeper 服务器是一个观察者。其次，在每个服务器配置文件中，必须在每个 Observer 的服务器定义行中添加: Observer。例如:

server.1:localhost:2181:3181:observer

This tells every other server that server.1 is an Observer, and that they should not expect it to vote. This is all the configuration you need to do to add an Observer to your ZooKeeper cluster. Now you can connect to it as though it were an ordinary Follower. Try it out, by running:

这告诉每个其他服务器，server. 1是一个观察者，他们不应该期望它投票。这就是在 ZooKeeper 集群中添加 Observer 所需的全部配置。现在你可以连接到它，就像它是一个普通的追随者。通过连接客户端尝试一下:

$ bin/zkCli.sh -server localhost:2181

where localhost:2181 is the hostname and port number of the Observer as specified in every config file. You should see a command line prompt through which you can issue commands like ls to query the ZooKeeper service.

其中 localhost: 2181是在每个配置文件中指定的 Observer 的主机名和端口号。您应该会看到一个命令行提示符，可以通过它发出 ls 之类的命令来查询 ZooKeeper 服务。

How to use Observer Masters

Observers function simple as non-voting members of the ensemble, sharing the Learner interface with Followers and holding only a slightly different internal pipeline. Both maintain connections along the quorum port with the Leader by which they learn of all new proposals on the ensemble.

观察者的功能很简单，就像集合中没有投票权的成员一样，与追随者共享学习者界面，只有一个略微不同的内部管道。两者都保持在仲裁端口与领袖的连接，通过他们了解整个系统的所有新建议。

By default, Observers connect to the Leader of the quorum along its quorum port and this is how they learn of all new proposals on the ensemble. There are benefits to allowing Observers to connect to the Followers instead as a means of plugging into the commit stream in place of connecting to the Leader. It shifts the burden of supporting Observers off the Leader and allow it to focus on coordinating the commit of writes. This means better performance when the Leader is under high load, particularly high network load such as can happen after a leader election when many Learners need to sync. It reduces the total network connections maintained on the Leader when there are a high number of observers. Activating Followers to support Observers allow the overall number of Observers to scale into the hundreds. On the other end, Observer availability is improved since it will take shorter time for a high number of Observers to finish syncing and start serving client traffic.

默认情况下，观察员连接到领导人的仲裁端口，这是他们如何了解所有新的提案的方式。也允许观察者连接到追随者，作为一种插入提交流代替连接到领导者的方式，这种方式有很多好处。它将支持观察者的重担从领导者身上转移开，并允许它专注于协调写操作的提交。

这意味着当领导者处于高负载时，特别是高网络负载时，比如在领导者选举后，当许多学习者需要同步时，性能会更好。它减少了总网络连接维护的领导时，有大量的观察员。

激活追随者以支持观察者，这样观察者的总数就可以扩展到数百人。另一方面，观察者的可用性得到了提高，因为大量的观察者完成同步并开始服务客户端流量所需的时间更短。

This feature can be activated by letting all members of the ensemble know which port will be used by the Followers to listen for Observer connections. The following entry, when added to the server config file, will instruct Observers to connect to peers (Leaders and Followers) on port 2191 and instruct Followers to create an ObserverMaster thread to listen and serve on that port.

这个特性可以通过让集合的所有成员知道 Followers 将使用哪个端口来侦听 Observer 连接来激活。下面的配置项添加到服务器配置文件中时，将指示观察者连接端口2191上的对等点(leader 和 Followers) ，并指示 Followers 创建一个 ObserverMaster 线程来监听和服务于该端口。

observerMasterPort=2191

Example use cases

Two example use cases for Observers are listed below. In fact, wherever you wish to scale the number of clients of your ZooKeeper ensemble, or where you wish to insulate the critical part of an ensemble from the load of dealing with client requests, Observers are a good architectural choice.

下面列出了观察者的两个用例。事实上，无论你希望扩展你的 ZooKeeper 集合的客户数量，或者你希望将集合的关键部分从处理客户请求的负担中隔离开来，观察者都是一个很好的架构选择。

• As a datacenter bridge: Forming a ZK ensemble between two datacenters is a problematic endeavour as the high variance in latency between the datacenters could lead to false positive failure detection and partitioning. However if the ensemble runs entirely in one datacenter, and the second datacenter runs only Observers, partitions aren’t problematic as the ensemble remains connected. Clients of the Observers may still see and issue proposals.

  作为一个数据中心桥: 在两个数据中心之间形成一个 ZK 集合是一个有问题的尝试，因为数据中心之间的高延迟差异可能导致错误的故障检测和分区。但是，如果集成在一个数据中心中完全运行，而第二个数据中心只运行观察者，那么分区就不会有问题，因为集成仍然是连接的。观察员的客户仍然可以看到并提出建议

• As a link to a message bus: Some companies have expressed an interest in using ZK as a component of a persistent reliable message bus. Observers would give a natural integration point for this work: a plug-in mechanism could be used to attach the stream of proposals an Observer sees to a publish-subscribe system, again without loading the core ensemble.

  作为消息总线的链接: 一些公司表示有兴趣将 ZK 用作持久可靠消息总线的组件。观察员会给这项工作一个自然的集成点: 可以使用插件机制将观察员看到的建议流附加到发布-订阅系统，同样不需要加载核心集成。

原文链接：https://zookeeper.apache.org/doc/current/zookeeperObservers.html