zookeeper简介

简介:分布式服务框架，一个高性能，分布式的，开源分布式应用协调服务,它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。典型的应用场景（配置中心、负载均衡、统一命名服务 、集群管理、同步锁、Leader 选举、队列管理等）。

 

工作机制：

 

1.Standalone：单点模式，有单点故障问题。

 

2.伪分布式：在一台机器同时运行多个ZooKeeper实例，仍然有单点故障问题，当然，其中配置的端口号要错开的，适合实验环境模拟集群使用。

 

3.完全分布式：在多台机器上部署ZooKeeper集群，适合线上环境使用。

 

ZooKeeper到底是什么：

1.三种端口号：这里先说明三个ZooKeeper配置需要的端口号，因为后面的解释中会经常引用，就拉到前面讲啦

端口X：客户端连接ZooKeeper集群使用的监听端口号

端口Y：leader和follower之间数据同步使用的端口号

端口Z：leader选举专用的端口号

 

2.单点分析：在每个ZooKeeper节点当中，ZooKeeper维护了一个类似linux的树状文件系统结构，可以把一些配置信息，数据等存放到ZooKeeper当中，也可以把ZooKeeper当中的一个目录节点当做一个锁的互斥文件来实现并发安全控制，你看到这就先把ZooKeeper理解为一个在操作系统上运行的一个虚拟文件系统，只不过他不是像HDFS那样真的用来存放文件的，他是利用文件系统的节点作为底层实现来提供分布式环境很常用的功能，这在后面的实战使用会具体讲解.

 

3.集群分析：ZooKeeper中的每个节点都是上面的单点分析那样工作的，但是集群多节点之间到底如何进行协商和通信呢？

首先，类似mysql读写分离那样，ZooKeeper的每个节点都存放相同的数据，因此访问ZooKeeper的时候会被分流道各个节点实现高并发，多节点也顺便实现了高可用。

ZooKeeper的节点之间也有主次关系，集群启动完成之后，ZooKeeper会运行选举程序（端口Z）从集群中选择一个leader节点，而其他的节点就是follower节点，对于ZooKeeper的写操作，会被转发到leader节点，而follower节点和leader节点的数据同步（端口Y）也在后台自动实现，读操作则每个节点都能提供，负载均衡~

 

4.容灾机制：follower节点挂了比较不要紧，有leader协调，整个集群还不至于发生致命影响。但是leader节点要是挂了，就群龙无首了，但是其实这个状态和ZooKeeper集群启动前期还没确定leader节点的时候是一样的状态，下面讲解这个状态如何进行leader的 选举。

由于每个节点配置文件中都维护了整个ZooKeeper集群的所有节点列表，因此在没确定leader节点或者leader节点挂掉的时候，每个节点向leader的通信必然是失败的，follower节点就是这么发现leader节点挂了的，这个时候他就能启动选举程序进行leader竞选，和其他的所有follower节点进行通信，根据某种算法方案确定leader的节点之后，被选中的节点就启动leader的程序，化身leader重新领导整个集群。

 

5.客户端访问高可用：

读操作：每个节点都能响应

写操作：不管向哪个节点请求都会转发到leader节点执行，再把数据同步到各个follower节点。

访问follower节点宕机：客户端会保存一个地址列表，会自动使用另一个地址进行访问，实在不行还有leader节点分配地址再次访问呢，而且一旦客户端和服务器的连接被断开，客户端就会自动去连接另一个节点的地址进行请求。

访问leader节点宕机：也是使用这个地址列表，如果是读操作，则leader选举出来之前都能访问，但是如果是写操作，就要等leader选举完成之后才能进行操作。 （每个follower节点都保存了集群的地址信息）

 

集群角色

 

1、Leader：接受所有的Follower的提案请求并统一协调发起提案的投票，负责与所有Follower进行内部的数据交换（同步）；

2、Follower：直接为客服端服务并参与提案的投票，同时与Leader进行数据交换（同步）；

3、Observer：直接为客服端服务但不参与提案的投票，同时与Leader进行数据交换（同步）；