认识zookeepr

了解zookeepr

zookeepr是一个开源的分布式的,为分布式应用提供协调服务的Apache项目

Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应，从而实现集群中类似Master/Slave管理模式(主从架构)

zookeepr 特点

1) 数据模型的结构跟UNIX文件系统很类似 整体上可看作是一棵树每个节点称为ZNode,默认能存 储  1MB的数据

2）Zookeeper：一个领导者（leader），多个跟随者（follower）组成的集群。

3）集群中只要有半数以上节点存活，Zookeeper集群就能正常服务 (半数机制 最少3台)。

4）全局数据一致：每个server保存一份相同的数据副本，client无论连接到哪个server，数据都是一致的。

5）更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行。

6）实时性，在一定时间范围内，client能读到最新数据。

zookeepr 应用场景

很多分布式协调服务都可以用zookeepr来做

1)配置管理 : 如果我们做普通的java 应用,一般配置项就是一个本地的配置文件,如果是微服务系统,各个系统服务都要使用集中化的配置管理,这个时候就需要 zookeepr

2)组成员管理:比如HBase(保证集群中只有一个 master，保存 hbase:meta 表的位置，保存集群中的)就是用来做集群的组成员管理

zookpeer 内部原理 (选举机制)

注意:半数机制（Paxos 协议）：集群中半数以上机器存活，集群可用。所以zookeeper适合装在奇数台机器上(最少为3台)。

这里举一个简单的例子来描述选举过程

 

假设有五台服务器组成的zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的

1.服务器1启动,此时只有它一个服务器启动了,它发起了选举,但是不够半数(基数3),所以它的状态为LOOKING状态;

2.服务器2启动,它也发起了选举,并与服务器1进行通信交换选票,由于两者都没有历史数据,此时id值较大的2胜出,但是还不够半数,所以1,2均保持LOOKING状态

3.服务器3启动,它也发起选票,并且跟服务器1,2通信交换选票,由于3此时的id为最高着,所以1,2均投票3,加3自身一票,刚好满足半数,此时服务器3状态更改为LEADING(领导者状态),服务器1,2状态更改为FOLLOWING;(跟随者状态);(此时zookeeper服务器已经可以运作)

4.服务器4启动,它也发起了选票,同样跟前面3个服务器通信交换选票.但是因为服务器3已经当选LEADING;服务器1,2也不能再更改选票,所以选票结果为服务器3(3票),服务器4(1票)少数服从多数,服务器4的状态也更改为FOLLOWING;

5.服务器5启动,它同服务器4一样,最后只能少数服从多数,状态更改为FOLLOWING;

这里得出:当服务器满足半数要求,并选出LEADING后.后面的服务器不管id再大也只能当小弟(FOLLOWING);

当然以上面例子为例如果做为LEADING的服务器3在运行过程中挂了,那么服务器1,2,4,5会重新选举leader,流程跟第一次选举没有太大的差异,(选举确定后,就算服务器3再重新连接上也只能当小弟(FOLLOWING)了;

启动后可以利用以下命令来查看 zookeeper 集群中的角色

 

拓展:我们也可以从开始就规定那个服务器不能参加选举 那它的状态从一开始就为:observer

 

observer

次级子节点，又名观察者

observer:用于读取数据，与 follower 区别在于没有投票权，不能被选为主节点,并且在计算集群可用状态时不会将 observer 计算入内。(及它在基数3之外 它的出现需要在有最少3台服务器的基础上才可以,否则无法选举出LEADING,服务器也就无法运作)

observer使用的时机:一般读的请求会大于写。当整个集群压力过大时，可以增加几个临时工 observer 来获得性能的提升,在不需要的时候的时候，可以随时撤掉 observer.