ZooKeeper 观察者
观察者：在不影响写入性能的情况下扩展 ZooKeeper
尽管 ZooKeeper 通过让客户端直接连接到 ensemble 的投票成员而表现得非常好，但这种架构很难扩展到大量客户端。问题是随着我们添加更多投票成员，写入性能下降。这是因为写入操作需要（通常）集成中至少一半节点的协议，因此随着更多选民的加入，投票的成本会显着增加。
我们引入了一种名为Observer的新型 ZooKeeper 节点，它有助于解决这个问题并进一步提高 ZooKeeper 的可扩展性。观察者是一个整体中没有投票权的成员，他们只听到投票结果，而不是导致他们的协议协议。除了这个简单的区别之外，观察者的功能与追随者完全相同——客户端可以连接到它们并向它们发送读写请求。观察者像追随者一样将这些请求转发给领导者，但他们只是等待听到投票结果。正因为如此，我们可以在不影响投票性能的情况下尽可能多地增加观察者的数量。
观察者还有其他优势。因为他们不投票，所以他们不是 ZooKeeper 集合的关键部分。因此，它们可能会失败，或者与集群断开连接，而不会损害 ZooKeeper 服务的可用性。对用户的好处是观察者可能通过比追随者更不可靠的网络链接进行连接。事实上，Observers 可用于与来自另一个数据中心的 ZooKeeper 服务器通信。Observer 的客户端将看到快速读取，因为所有读取都在本地提供，并且写入导致最小的网络流量，因为在没有投票协议的情况下所需的消息数量更少。
如何使用观察者
设置使用 Observers 的 ZooKeeper 集成非常简单，只需要对配置文件进行两次更改。首先，在每个要成为 Observer 的节点的配置文件中，必须放置以下行：
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 服务。
如何使用观察者大师
观察者的功能很简单，就像集成中没有投票权的成员一样，与追随者共享学习者界面，并且只拥有稍微不同的内部管道。两者都沿着仲裁端口与领导者保持连接，通过该连接他们了解集合中的所有新提议。
默认情况下，Observers 会沿着其 quorum 端口连接到 quorum 的 Leader，这就是他们了解 ensemble 上所有新提案的方式。允许观察者连接到追随者有好处，而不是作为插入提交流而不是连接到领导者的一种方式。它将支持观察者的负担从领导者身上转移，并允许它专注于协调写入的提交。这意味着当领导者处于高负载下时性能更好，特别是高网络负载，例如在领导者选举后，当许多学习者需要同步时可能发生。当有大量观察者时，它会减少在 Leader 上维护的总网络连接。激活追随者以支持观察者允许观察者的总数扩展到数百个。在另一端，
可以通过让 ensemble 的所有成员知道 Followers 将使用哪个端口来侦听 Observer 连接来激活此功能。以下条目，当添加到服务器配置文件时，将指示观察者连接到端口 2191 上的对等方（领导者和追随者），并指示追随者创建一个 ObserverMaster 线程以在该端口上侦听和服务。
observerMasterPort=2191
示例用例
下面列出了观察者的两个示例用例。事实上，无论您希望扩展 ZooKeeper 集成的客户端数量，或者希望将集成的关键部分与处理客户端请求的负载隔离开来，观察者都是一个很好的架构选择。
- 作为数据中心的桥梁：在两个数据中心之间形成 ZK 集成是一项有问题的工作，因为数据中心之间延迟的高差异可能导致误报故障检测和分区。但是，如果 ensemble 完全在一个数据中心运行，而第二个数据中心只运行 Observers，则分区不会有问题，因为 ensemble 保持连接。观察者的客户仍然可以看到和发布提案。
- 作为到消息总线的链接：一些公司表示有兴趣使用 ZK 作为持久可靠消息总线的组件。观察者将为这项工作提供一个自然的集成点：插件机制可用于将观察者看到的提案流附加到发布-订阅系统，同样无需加载核心集成。