zookeeper的基本原理(二）

在前面的两篇中，我们介绍了zookeeper的安装与简单的使用，这一篇我们就来看一下zookeeper的一些基本原理。

一、什么是zookeeper

zookeeper是什么？打开百度，输入zookeeper，我们可以看到是这么定义的：

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

看了这一段话，每一句都有不认识的东西，像我这样的小青年内心就是：

刚上来就是分布式，那么什么是分布式？什么是集群？了解了这些才能进一步去了解之后的东西。在此期间我在网上也是看了许多讲解什么是分布式，有一个解释比较简单易懂，大意是这样的：

你开了一家饭店，请了一位厨师，厨师负责洗菜、做菜、端菜，后来客人多了厨师忙不过来，又请了两位厨师，这样就有了三位厨师来共同完成，这就是集群的概念。后来为了提高
效率与质量，你又分别请了三个洗菜工，三个端菜员，将原先整体属于厨师的任务分割开，让厨师专心做菜。这种将原先属于一个角色的任务分割给不同的角色，各司其职，这就是分布式。

简单概括的话：分布式就是将一个业务拆分为多个业务，放在不同的服务器上。

二、为什么使用zookeeper

在以前的项目中，如果项目简单的话，那么一台服务器就可以搞定了，但是当项目越来越复杂，请求多了，服务也多了，这时候就需要采用分布式了。

但是采用分布式也存在一些问题，我们将项目部署在多台服务器上，如果想要修改某些配置信息，就需要逐个去通知服务器，再逐个修改。而且在分布式情况下，对于锁资源的获取、数据的存储也是有着一些问题存在的。

通过使用zookeeper，可以实现诸如分布式应用配置管理、统一命名服务、状态同步服务、集群管理等功能。

zookeeper也可以担任注册中心，在dubbo中有个架构图：

在dubbo的这个场景中，zookeeper就可以作为注册中心(Resgistry)。服务的提供者将服务注册到zookeeper，服务消费者在使用的时候直接去注册中心去查看服务使用即可。倒是类似于中介，提供者与消费者有事找注册中心就行，后续的操作交给zookeeper。此外，zookeeper也是dubbo官方推荐的注册中心。

三、zookeeper的一些重要概念&&信息

高可用：

在公司的项目中，zookeeper是以集群的形式搭建的，采用集群搭建的好处就在于如果某个时刻突然出现了意外，挂了个一台服务器，只要剩余存活的服务器超过了原先的半数，那么zookeeper是还可以正常提供服务的。

来看下zookeeper的架构图就明白了：

它的服务器之间是相互连接的，即使其中一台挂了，客户端也可以连接其它的服务器。至于连接的是哪个服务器，这个就是视情况而定了。

zookeeper的特点：

1、顺序一致性：当一个客户端发起多个请求，这些请求会按照发起的顺序被zookeeper执行。
2、原子性：原子性这个东西我们大家都不陌生，毕竟在数据库中是见过这个东西的。在zookeeper中也是同样的意思。因为zookeeper基本采用集群的方式搭建的，那么向zookeeper中写数据的时候，要么所有的服务器都写入，要么所有的服务器都不写入。
3、单一系统映像：zookeeper集群虽然有多台服务器，但是无论客户端连接的是哪台服务器，最终看到的数据模型是要一样的。
4、可靠性：一旦客户端发起的请求被应用，那么更改的结果就会被持久化，直到下次被覆盖。

节点

在分布式中，节点一般代表服务器。但是在zookeeper中，节点除了代表服务器，还代表了zookeeper中的存储节点。关于节点znode的一些信息，在我的上一篇文章 zookeeper的使用与基本原理(一) 有介绍过，此外还有一些关于zookeeper的监视器(watcher)、权限(ACL)也都在上篇文章有提到。

集群角色：

在zookeeper中，服务器节点有三种角色：跟随者(follower)、领导者(leader)、观察者(observer)。


在zookeeper中就是这个样子的，至于观察者，是需要配置才有的。

领导者：负责进行投票的发起与进行，更新系统状态。

跟随者：负责与客户端进行通信，客户端发起读操作的话，可以立即执行，如果发起写操作，那么需要将写操作的信息传递给领导者。同时跟随者可以在领导者选举的过程中进行投票。

观察者：观察者虽然是observer，但是它并不边缘ob。它与跟随者唯一的区别就是观察者不会在领导者选举的时候投票。此外，跟随者与观察者都可以归类于学习者。

服务器节点的三种状态：

LOOKING：当前服务器不知道领导者是谁，正在寻找领导者。
LEADING：当前服务器节点为领导者
FOLLOWING：表示当前状态为跟随者。

四、ZAB协议

ZAB（ZooKeeper Atomic Broadcast 原子广播）协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议，它是zookeeper的核心。在zookeeper中，通过ZAB协议来实现分布式数据一致性。基于此协议，zookeeper实现了一种主备模式的系统架构来保证集群中各个服务器节点的数据一致性。

ZAB协议包含两部分：恢复模式（选主）、广播模式（同步）。

恢复模式：恢复模式有两个应用场景：一个是在集群启动时，这个时候所有服务器刚刚启动，需要选举出领导者。另一种就是当领导者服务器挂掉了，此时其余的服务器处于LOOKING状态，需要选举出新的领导者。那么这个领导者怎么选举出呢？

启动时：第一台服务器server1启动的时候，因为只有它一个服务器，所以没办法进行领导者的选举，当第二台服务器server2启动的时候，此时两台服务器之间可以相互通信，此时进入leader选举过程。

1、每台服务器发出一次投票，server1与server2都会设置自己为领导者（好像现实中也是这样啊。。。）。每次投票会带出两个参数：(myid，zxid)，myid在之前zookeeper配置的时候就说过了，假设设置server1的myid为1，server2的myid为2，zxid则是当时的事务id。此时server1为(1，0)，server2为(2,0)。
2、集群中的每台服务器接收来自集群中其它服务器的投票信息
3、票已经投完了，那么就开始进行领导者选举的PK。首先比较的是zxid，谁的zxid大，那么谁就是领导者。如果zxid一样，那么就比较myid，谁的myid大，谁就是领导者。此时server2的zxid与server1的zxid相同，但是server2的myid大于server1的myid，所以server2胜出，server2获得了两票胜出，而server1PK失败，就需要更改自己为(2，0)去进行接下来的选举。
4、假设有三台服务器，此时为(2,0)的已经有两台服务器了，虽然第三台为(3,0)，但是第二台服务器的得票数已经超过了半数，理应当选为领导者。
5、一旦确认了领导者，那么每个服务器就会更新自己的状态，领导者更改为LEADING、跟随者更改为FOLLOWING状态。

运行时领导者选举：

在zookeeper集群使用的时候，如果出现了leader宕机的情况，那么肯定是要选举出一个leader来继续下面的工作。其实与启动时领导者选举是类似的，跟随者发出自己的myid与zxid进行互相PK，但是此时zookeeper已经工作过一段时间了，它的zxid可能不像开始的时候为0，但是选举的思想还是先比较zxid，谁的zxid大，谁就是领导者。zxid相同就比较myid。

广播模式：
ZAB广播模式是通过类似两阶段提交协议的方式解决数据一致性。

1、领导者收到客户端的写请求。
2、领导者生成一个新的事务，并为这个事务生成一个唯一的ZXID。
3、领导者将这个事务提议(propose)发送给所有的跟随者(follower)节点。
4、跟随者节点将收到的事务请求加入到历史队列(history queue)中，并发送ack给领导者。
5、当领导者收到半数以上的跟随者的ack消息，领导者就会发送commit请求。
6、当跟随者收到commit请求时，从历史队列中将事务请求commit。

五、zookeeper集群为什么要奇数台服务器

其实在上面的ZAB协议中就可以看到，zookeeper集群的运行只要半数以上的服务器节点能够运行就OK了。我们假设集群A有三台服务器，集群B有四台服务器，根据我们在上面了解的，集群A允许一台服务器宕机之后还可以完好运行。而集群B也只能允许一台服务器宕机，如果集群B有两台服务器宕机了，那么剩下的服务器就不满足zookeeper集群的正常运行的条件了。所以从这方面看，三台服务器集群与四台服务器集群的容错数量是一样的，但是部署三台服务器相比于四台服务器，会更减少资源的消耗。