转载来源：https://www.cnblogs.com/sunddenly/p/4143306.html
1、ZooKeeper中Observer
1.1 ZooKeeper角色
通过前面的介绍，我想你们都已经知道了在ZooKeeper集群当中有两种角色Leader和Follower。Leader能够接受client请求，也接收其余Server转发的写请求，负责更新系统状态。 Follower也能够接收client请求，若是是写请求将转发给Leader来更新系统状态，读请求则由Follower的内存数据库直接响应。 ZooKeeper集群如图1.1所示。html
图 1.1 ZooKeeper集群服务数据库
但在ZooKeeper的3.3.3版本之后，ZooKeeper中又添加了一种新角色Observer。Observer的做用同Follower相似，惟一区别就是它不参与选主过程。那么，咱们就能够根据该特性将ZK集群中的Server分为两种：服务器
(1) 投票Server：Leader、Follower网络
(2) 非投票Server：Observerpost
1.2 为何引入Observer
(1) ZooKeeper可伸缩性 性能
那么，ZooKeeper为何要引入Observer这个角色呢？其实在ZooKeeper中引入Observer，主要是为了使ZooKeeper具备更好的可伸缩性。那么，何为可伸缩性？关于伸缩性，对于不一样的人意味着不一样的事情。 而在这里是说，若是咱们的工做负载能够经过给系统分配更多的资源来分担，那么这个系统就是可伸缩的；一个不可伸缩的系统却没法经过增长资源来提高性能，甚至会在工做负载增长时，性能会急剧降低。测试
在Observer出现之前，ZooKeeper的伸缩性由Follower来实现，咱们能够经过添加Follower节点的数量来保证ZooKeeper服务的读性能。可是随着Follower节点数量的增长，ZooKeeper服务的写性能受到了影响。为何会出现这种状况？在此，咱们须要首先了解一下这个"ZK服务"是如何工做的。优化
(2) ZK服务过程 spa
ZooKeeper服务中的每一个Server可服务于多个Client，而且Client可链接到ZK服务中的任一台Server来提交请求。如果读请求，则由每台Server的本地副本数据库直接响应。如果改变Server状态的写请求，须要经过一致性协议来处理，这个协议就是咱们前面介绍的Zab协议。设计
简单来讲，Zab协议规定：来自Client的全部写请求，都要转发给ZK服务中惟一的Server—Leader，由Leader根据该请求发起一个Proposal。而后，其余的Server对该Proposal进行Vote。以后，Leader对Vote进行收集，当Vote数量过半时Leader会向全部的Server发送一个通知消息。最后，当Client所链接的Server收到该消息时，会把该操做更新到内存中并对Client的写请求作出回应。该工做流程以下图1.2所示。
图1.2 ZK 写请求工做流程图
从图中咱们能够看出， ZooKeeper 服务器在上述协议中实际扮演了两个职能。它们一方面从客户端接受链接与操做请求，另外一方面对操做结果进行投票。这两个职能在 ZooKeeper集群扩展的时候彼此制约。例如，当咱们但愿增长 ZK服务中Client数量的时候，那么咱们就须要增长Server的数量，来支持这么多的客户端。然而，从Zab协议对写请求的处理过程当中咱们能够发现，增长服务器的数量，则增长了对协议中投票过程的压力。由于Leader节点必须等待集群中过半Server响应投票，因而节点的增长使得部分计算机运行较慢，从而拖慢整个投票过程的可能性也随之提升，写操做也会随之降低。这正是咱们在实际操做中看到的问题——随着 ZooKeeper 集群变大，写操做的吞吐量会降低。
(3) ZooKeeper扩展
因此，咱们不得不，在增长Client数量的指望和咱们但愿保持较好吞吐性能的指望间进行权衡。要打破这一耦合关系，咱们引入了不参与投票的服务器，称为 Observer。 Observer能够接受客户端的链接，并将写请求转发给Leader节点。可是，Leader节点不会要求 Observer参加投票。相反，Observer不参与投票过程，仅仅在上述第3歩那样，和其余服务节点一块儿获得投票结果。
图 1.3 Observer 写吞吐量测试
图1.3 显示了一个简单评测的结果。纵轴是，单一客户端可以发出的每秒钟同步写操做的数量。横轴是 ZooKeeper 集群的尺寸。蓝色的是每一个服务器都是投票Server的状况，而绿色的则只有三个是投票Server，其它都是 Observer。从图中咱们能够看出，咱们在扩充 Observer时写性能几乎能够保持不便。可是，若是扩展投票Server的数量，写性能会明显降低，显然 Observers 是有效的。
这个简单的扩展，给 ZooKeeper 的可伸缩性带来了全新的镜像。咱们如今能够加入不少 Observer 节点，而无须担忧严重影响写吞吐量。但他并不是是无懈可击的，由于协议中的通知阶段，仍然与服务器的数量呈线性关系。可是，这里的串行开销很是低。所以，咱们能够认为在通知服务器阶段的开销没法成为主要瓶颈。
2、Observer应用
(1) Observer提高读性能的可伸缩性
应对Client的数量增长，是 Observer的一个重要用例，可是实际上它还给集群带来不少其它的好处。Observer做为ZooKeeper的一个优化，Observer服务器能够直接获取Leader的本地数据存储，而无需通过投票过程。但这也面临必定的"时光旅行"风险，也就是说：可能在读到新值以后又读到老值。但这只在服务器故障时才会发生事实上，在这种状况下，Client能够经过"sync"操做来保证下一个值是最新的。
所以，在大量读操做的工做负载下，Observer会使ZooKeeper的性能获得巨大提高。若要增长投票Server数量来承担读操做，那么就会影响ZooKeeper服务的写性能。并且Observer容许咱们将读性能和写性能分开，这使ZooKeeper更适用于一些以读为主的应用场景。
(2) Observer提供了广域网能力
Observer还能作更多。Observer对于跨广域网链接的Client来讲是很好的候选方案。Observer可做为候选方案，缘由有三：
① 为了得到很好的读性能，有必要让客户端离服务器尽可能近，这样往返时延不会过高。然而，将 ZooKeeper 集群分散到两个集群是很是不可取的设计，由于良好配置的 ZooKeeper 应该让投票服务器间用低时延链接互连——不然，咱们将会遇到上面提到的低反映速度的问题。
② 而Observer 能够被部署在，须要访问 ZooKeeper 的任意数据中心中。这样，投票协议不会受到数据中心间链路的高时延的影响，性能获得提高。投票过程当中 Observer 和领导节点间的消息远少于投票服务器和领导节点间的消息。这有助于在远程数据中心高写负载的状况降低低带宽需求。
③ 因为Observer即便失效也不会影响到投票集群，这样若是数据中心间链路发生故障，不会影响到服务自己的可用性。这种故障的发生几率要远高于一个数据中心中机架间的链接的故障几率，因此不依赖于这种链路是个优势。
3、ZooKeeper集群搭建案例
前面介绍了ZooKeeper集群中的几种角色，接下来给你们来介绍一下如何利用这些角色，来搭建一个性能良好的ZooKeeper集群。我以一个项目为例，给你们分析一下该如何规划咱们的ZooKeeper集群。
假设咱们的项目须要进行跨机房操做，咱们的总部机房设在杭州，但他还要同美国，青岛等多个机房之间进行数据交互。但机房之间的网络延迟都比较大，好比中美机房走海底光缆有ping操做200ms的延迟，杭州和青岛机房有70ms的延迟。 为了提高系统的网络性能，咱们在部署ZooKeeper网络时会在每一个机房部署节点，多个机房之间再组成一个大的网络，来保证整个ZK集群数据一致性。
根据前面的介绍，最后的部署结构就会是：
(总部) 杭州机房 >=3台 ：由Leader/Follower构成的投票集群
(分支) 青岛机房 >=1台 ：由Observer构成的ZK集群
(分支) 美国机房 >=1台 : 由Observer构成的ZK集群
图 3.1 ZooKeeper集群部署图
从图中咱们能够看出，咱们在单个机房内组成一个投票集群，外围的机房都会是一个Observer集群和投票集群进行数据交互。 至于这样部署的一些好处，你们本身根据我前面对ZooKeeper角色的介绍，对比着体会一下，我想这样更能帮助你们理解ZooKeeper。并且针对这样的部署结构，咱们会引入一个优先集群问题： 好比在美国机房的Client，须要优先去访问本机房的ZK集群，访问不到才去访问HZ(总部)机房。