Zookeeper纸上谈兵——概述

前言
最近开始工作了，觉得有必要将一些学习的东西做一些总结，于是给自己定了个小目标：坚持每天学习并且每周一篇博客内容包括学习的一些笔记，还有自己的理解啥的，然而过去好几周了，都一直没写，今天终于开始动手，没有次序，不定期更新吧。学到了Zookeeper，就从Zookeeper开始！

一、Zookeeper简介

相信很多人听说Zookeeper都是从dubbo那里听来的，因为dubbo官方推荐使用Zookeeper作为注册中心，好吧，至少我是这样的。事实上，Zookeeper主要是为分布式系统提供一致性服务的，它的一致性主要通过基于Paxos算法的ZAB协议完成。官方解释，Zookeeper是一个开源的分布式应用程序协调服务器，其功能主要包括：配置维护、域名服务、分布式同步、集群管理四个方面。听起来是不是有点晕，等下你就明白了。对了，其名字的由来还比较有意思，感兴趣可自行百度。

1.1 功能介绍

（1） 配置维护

这个功能可能是我们日常接触最多的，在分布式系统中，很多的服务都是部署在集群之中的，也就是说有多台服务器上有着相同的服务，这些服务配置自然都是一样的。
这样的话，如果需要修改服务配置，就要一台一台地改，服务器数量少还好说，数量多了，比如某些大型互联网公司动辄就是几千台服务器，你再去一个个改试试？耗费人力不说还容易出错。
于是，Zookeeper就跳出来了，他说我有一个“发布–订阅模式”可以解决问题。只要服务的发布者（提供者、生产者，指的都是一个意思）将修改之后的配置文件交到Zookeeper手中，那么Zookeeper就会通知到订阅者，订阅者就会主动同步Zookeeper里的配置文件。Zookeeper能够通过同步的原子性保证集群中所有服务器配置文件的正确更新。是不是有中间商的感觉？

（2）域名服务

分布式系统里面，一个项目包含多个工程，而其中有些工程是专门为其他工程提供服务的，而同一个服务又可能存在于多个提供者。所以，关系就会变得十分复杂。
Zookeeper于是为每一个服务起一个名称，将这些服务名称与提供服务的主机地址保存起来，形成一个服务映射表。消费者只需要通过服务名就可以享受服务，就如同你只需要地址栏输入www.baidu.com就可以使用百度，而无需关心百度的后面有多少ip地址，这就是叫域名服务的原因。
这样一来，对于服务的增加、减少和修改都只需更改Zookeeper中的映射表就可以了。
Dubbo就是使用的Zookeeper作为域名服务器，所以我们会发现调用dubbo服务只需要服务名。

上面这个简单的图中，消费者只需要将自己想要消费的服务告诉Zookeeper，Zookeeper就会去集群里找到相应的提供者信息并返回给消费者。同一个服务可能会有多个提供者，Zookeeper会根据提供者的忙闲程度返回合适的提供者。

（3）分布式服务

在分布式系统中，有很多处理是由集群中的若干服务器计算完成的，并且其计算顺序存在逻辑上的先后，所以保证这些服务器运行期间的同步性就显得尤为重要。
使用Zookeeper时，Zookeeper可以让这些服务器同时监听Zookeeper上的同一个Znode，也就是Zookeeper文件系统里的一个数据存储节点，一旦其中一个服务器对节点进行更新，其他服务器就会收到通知并作出相应的处理。

图比较粗擦，不过思想本来比较简单，就不解释了。

（4）集群管理
在分布式中我们经常会看到什么master啊，slave什么的，以及主从之类的概念，这些是集群的组成部分。在集群管理中，比较麻烦的就是节点故障管理。Zookeeper可以让集群选出一个健康节点作为master，这个master会时刻监控着当前集群的每个节点的情况（心跳机制），一旦某个节点发生故障，master会通知其他节点，让其他节点做出任务分配的相关调整，如果master自己挂了呢？Zookeeper有一个“选举”机制可以选出新的master。
另外，Zookeeper还会对发现的节点故障进行判断，如果能够修复就会自动修复，如果不能就告诉管理员错误的原因以便于管理员迅速定位问题。是不是很贴心？

1.2 Zookeeper的一致性

Zookeeper的一致性需要满足一下几点：

（1）顺序一致性

从同一个客户端发起的多个事务请求，组中将会严格按照其发起的顺序被应用到Zookeeper中。

（2）原子性

这个很好理解，所有事务的请求结果在集群中所有的机器上的应用情况应该是一样的。要么集群中所有机器都应用了此请求，要么就都没有。

（3）单一视图

所谓单一就是说无论客户端连接到的是集群中的哪一台服务器，它所得到的结果和看到的服务器数据模型都是一致的。

（4）可靠性

可靠就是说吐过服务端成功应用了一个事务并完成了对客户端的响应，那么该服务在另一个事务更改它之前都会一直保留而不会出现丢失。

（5）实时性

Zookeeper的实时性仅仅保证在一定的时间段内，客户端最终能够从服务端获取到最新的数据状态。

二、Zookeeper中的重要概念

2.1 Session

这里Session指的是客户端会话。Zookeeper的服务端口默认是2181，客户端启动时，会与Zookeeper建立一个TCP长连接，通过这个长连接，客户端就可以通过心跳机制保持与服务端的有效会话，同时也可以向服务端发送请求并接受响应，还能接收服务端发过来的Watcher事件通知。
Session会有一个SessionTimeout值来控制一个客户端会话的超时时间，当服务器压力过大或是网络故障或者客户端主动断开连接等导致连接中断时，只要在这个时间内客户端能重新连上服务器集群中的任意一台服务器，则之前的会话就仍然有效。

2.2 Znode

我们前面说过，Znode就是Zookeeper文件系统中的数据存储节点，Zookeeper的文件系统与Linux非常相似，采用树形结构，根目录都是 / ，每一个目录叫做一个Znode，每一个Znode有一个唯一的路径标识，因为是树形结构，所以每个节点的路径自然都是唯一的，这个路径就是它的名称，类似于java中类的全限定名。Znode中的数据具有多个版本，所以查询某个路径下的数据需要带上版本号。前面也有提到，客户端可以在Znode上设置监视器（Watcher）。

2.3 Watcher机制

Zookeeper通过watcher机制来实现发布/订阅模式。一个发布者可以让多个订阅者同时监听某一主题对象，当这个对象状态发生变化时，会通知所有的订阅者让它们能及时作出处理。Zookeeper允许订阅者向发布者注册一个Watcher监听，当服务端的事件触发这个watcher，就会向注册的订阅者发送一个事件通知，这个通知就是通过上面说的TCP长连接的Session完成的。

2.4 ACL

ACL全称为Access Control List，即访问控制列表，用于控制资源的访问权限，也就是说Zookeeper是有权限控制功能的，它利用ACL策略对Znode进行权限控制，包括Znode的创建、读写、删除、访问子Znode、设置Znode权限等等。
我们知道，Linux的权限管理是ugo机制，其中一个文件或者目录拥有了某个组的权限，那么文件或子目录就会获得其父目录的权限，也即是说权限是可以继承的，但在Zookeeper中，Znode的权限是独立的，没有继承关系，它分三个部分：授权策略scheme、用户id、用户权限permission。

第一篇博客就这些吧，网上学习的笔记加一些自己的理解，下一篇来分析学习一下Paxos算法。