观察者：在不影响写入性能的情况下缩放Zookeeper
虽然客户端直接连接到投票选举的Zookeeper成员执行良好，但这个架构很难扩展到大量的客户端。问题就是因为我么添加了更多的投票成员，写入性能下降。这是由于这样的事实：一个写入操作要求共识协议至少是整体的一半，因此投票的成本随着投票者越多会显著增加。
我们引入了一个新的Zookeeper节点类型叫做Observer，它帮助处理这个问题并进一步完善了Zookeeper的可扩展性。观察者不参与投票，它只监听投票的结果，不是导致了他们的共识协议。除了这个简单的区别，观察者精确的和追随者一样运行 – 客户端可能链接他们并发送读取和写入请求。观察者像追随者一样转发这些请求到领导者，而他们只是简单的等待监听投票的结果。正因为如此，我们可以尽可能多的增加观察者的数量，而不影响投票的性能。
观察这还有其他优势。因为他们不投票，他们不是Zookeeper整体的主要组件。因此他们可以故障，或者从集群断开连接，而不影响Zookeeper服务的可用性。对用户的好处是观察者可以连接到比追随者更不可靠的网络。事实上，观察者可以用于从其他数据中心和Zookeeper服务通信。观察者的客户端会看到快速的读取，因为所有的读取都在本地，并且写入导致最小的网络开销，因为投票协议所需的消息数量更小。
怎么使用观察者？
使用观察者设置Zookeeper全员非常简单，只需要在原来的配置文件上改两个地方。第一，每个节点的配置文件设置为观察者，必须放置这一行：
|
1 |
peerType=observer |
这一行告诉Zookeeper的服务是一个观察者。
第二，在每个服务配置文件里，必须在观察者定义行添加:observer。例如：
|
1 |
server.1:localhost:2181:3181:observer |
这个告诉其他服务server.1是一个观察者，并且他们不需要期望他选举。这是你在Zookeeper集群中添加观察者需要的所有配置。现在你可以连接到它好像是一个普通的追随者。尝试一下，通过运行：
|
1 |
bin/zkCli.sh -server localhost:2181 |
这里的localhost:2181是每个配置文件里指定的观察者的hostname和端口号。你应该查看一个命令行提示，通过类似于ls的操作查询Zookeeper服务。
用户实例
两个观察者用户实例在下面列出。事实上，无论你希望在哪里扩展Zookeeper全员的客户端数量，或你希望根据客户端需求负载隔离整体的关键部分，观察者是一个非常好的架构选择。
作为数据中心的桥梁：在两个数据中心之间形成ZK整体是一个问题，因为在数据中心之间的高延迟可能导致假性故障检测和分区。然而如果整体完全运行在一个数据中心，并且第二个数据中心只运行观察者，分区不是问题，因为全员保持连接。观察者的客户端可以维持看到并提出建议。
作为连接到消息总线：有些公司表示喜欢用ZK作为持续可靠的消息总线的组件。观察者给出一个自然集成的：一个插件机制可以用于观察者发布-订阅系统，而没有加载核心。
