大数据运维3--zookeeper和kafaka的简单使用

Zookeeper概述

是一个开源的分布式应用程序协调服务,它是用来保证数据在集群间的事物一致性的

举例,比如A公司和B公司达成某个协议,A公司需要到B公司取对应的文件过程,这个过程叫通信的过程.计算机中的程序比较多,会出现资源争抢,这个时候会发生死锁,这时整个资源会出现运转不了.这个时候,如果有个交警,指挥资源的流动,这个时候就不会出现死锁.如下图,如果在单机上,资源XY可以打包一起,当需要访问的时候,需要到C中拿到对应的令牌,所有的需要访问X,Y的资源需要在访问令牌才可以访问到XY资源.如果在集群中,XY没有办法打包,这个时候,就需要zookeeper在其中协调资源.

Zookeeper应用场景:集群分布式锁,集群统一命名服务,分布式协调服务

 

 

Zookeeper角色与特性

Leader:接受所有Follower的提案请求并统一协调发起提案的投票,负责与所有的Follower进行内部数据交换

Follower:直接为客户端服务并参与提案的投票,同时与Leader进行数据交换

Observer:直接为客户端服务但不参与提案的投票,同时也与Leader进行数据交换

这里的投票机制的Follower相当于议员,Observer相当于平民,这样区分是为了不能投票涉及太多的人员导致性能下降

 

Zookeeper角色与选举

服务在启动的时候是没有角色的(LOOKING),角色是通过选举产生的,选举产生一个Leader,剩下的是Follower

选举Leader原则

集群中超过半数集群投票选择Leader,假如集群中拥有n台服务器,那么Leader必须得到n/2+1台服务器的投票

如果Leader死亡,重新选举Leader,如果死亡的机器数量达到一半,则集群挂掉,如果无法得到足够的投票数量,就重新发起投票,如果参与投票的机器不足n/2+1,则集群停止工作.如果Follower死亡过多,剩余机器不足n/2+1,则集群也会停止工作.Observer不计算在投票总设备数量里面.

 

Zookeeper原理与设计

Leader所有写相关操作,Follower读操作与响应Leader提议,在Observer出现以前,Zookeeper的伸缩性由Follower来实现,我们可以通过添加;Follower节点的数量来保证Zookeeper服务的读性能,但是随着Follower节点数量的增加,Zookeeper服务的写性能受到了影响.客户段提供一个请求,若是读请求,则由每台Server的本地副本数据库直接响应,若是写请求,需要通过一致性协议Zab来处理,

Zab协议规定:来自Client的所有写请求都要转发到ZK服务中唯一的Leader,由Leader根据该请求发起一个Proposal.然后其他的Server对该Proposa进行vote.之后Leader对Vote进行收集,当Vote数量过半时Leader会向所有的Server发送一个通知消息,最后当Client所连接的Server收到该消息时,会把该操作更新到内存中并对Client的写请求做出回应.

Zookeeper在上述协议中实际扮演了两个职能.一方面从客户端接受连接与操作请求,另一方面对操作结果进行投票.这两个职能在Zookeeper集群扩展的时候彼此制约,从Zab协议对写请求的处理过程中可以发现,增加Follower的数量,则增加了协议投票过程的压力.因为Leader节点必须等待集群中过半Server响应投票.是节点的增加使得部分计算机运行较慢,从而拖慢整个整个投票过程的可能性也随之提高.随着集群变大,写操作也会随之下降.所有.不得不在增加Client数量的期望和希望我们保持较好吞吐量的期间进行权衡.要打破这一耦合关系.引入了不参与投票的服务器Objserver.Observer可以接受客户端的连接,并将写请求转发给Leader节点.但是Leader节点不会要求Observer参与投票,Observe的扩展,给Zookeeper的可伸缩性带来了全新的景象,加入很多Observer节点.无须担心严重影响写吞吐量,但并非是无懈可击,因为协议中的通知阶段,仍然与服务器的数量呈线性关系.但是这里的串行开销非常低,因此,可以认为在通知服务器阶段的开销不会成为瓶颈.Observer提升读性能的可伸缩性,Observer提供了广域网能力.