一、概述

1.特点：不参与投票也不选举，但是会监听投票结果，然后根据投票结果来执行对应请求

场景：三个机房，杭州，青岛，美国，杭州有7001个 zk 服务节点，青岛有4000个 zk 服务节点，美国有4000 zk 服务节点

问题：选举节点个数过多，网络对选举的效率影响较大

选举A作为leader的，选择B作为leader的，在杭州分别有4000个和3000个，青岛有1800个，2200个，美国2000个，2000个

此时理论上选择A作为leader有4000+1800+2000=7800个，B作为leader的有3000+2200+2000=7200个，即总的节点数有15001个，A作为leader有7800，大于15001的一半，且大于B作为leader的数量，是可以的

但是实际中，在接收青岛或者美国的所有节点的反馈信息，由于网络问题，可能会存在部分节点的信息收到，

如收到青岛反馈：A作为leader有1000，B作为leader有2000；美国反馈：A作为leader有800，B作为leader有1000

那么总的A作为leader有5800，B作为leader有6000，但是B还是不会作为leader，理由是B作为leader有6000个，没有满足节点数量过半的要求，即 6000 < 15001/2

针对以上的问题，处理方式，青岛和美国的节点都作观察者，只有杭州的节点拥有选举权

 

 

2.观察者适用场景：网络不好或者异地网络结构；集群庞大节点个数比较多，

　　　　　　一般有70%左右的作为观察者，不进行参与选举，只执行结果

3.观察者的存活与否并不影响整个集群

4.设置观察者：首先在需要修改的节点上，关闭zk的服务，然后修改zoo.cfg，添加 peerType=observer