大数据｜zookeeper简介及3个简单易懂的案例分析（一）

一、zookeeper简介

zookeeper是一个分布式应用程序协调服务，分布式应用程序可以基于它实现同步服务。具体来讲zookeeper可以实现的分布式协调服务包括：

1）统一名称服务 2）配置管理 3）分布式锁 4）集群节点状态协调（负载均衡/主从协调）

二、三个案例

1）统一名称服务

我们设想这么一个场景，有3个客户端需要调用有同样服务的一个分布式应用系统，在这个系统中现有3台提供服务的服务器，server01、server02、server03。如下图一：

图一

在这种情况下，要想让每个客户端知道分布式应用系统上有多少可以使用的服务时，需要在每个客户端设置一个配置文件用来记录有哪些可用的服务器。但是当分布式应用系统中有一台服务器挂掉或新加了一台可以提供相同服务的新服务器server04时，需要一个个去更新每个客户端的配置文件，这显然是一个很复杂的事，实际上服务也很难找到这些客户端。基于此，我们考虑增加一个第三方媒介来看看情况是否有改观。如图二：

图二

分布式应用系统里面如果有增加新的服务或者有老的服务挂掉都会即时注册到这个第三方媒介里面。当客户端需要访问某个服务时，也会先想第三方媒介发送请求，如图二中的1，第三方收到客户端请求后就会返回一台最合适的满足条件的服务器地址给客户端，比如当前负载最少的服务地址，客户端得到服务地址之后再去直接访问对应的服务。

这里的第三方主要做的是协调名称服务。

2）配置管理

我以前在做RPC时使用的是Hessian实现，把不同的功能的应用都做成一个服务，每个应用提供不同的服务，相互之间都有调用。如下图三：

图三

我当时遇到的问题主要有：

（1）当服务越来越多时，服务URL配置管理变得非常困难。此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。

（2）当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动。

（3）甚至后面当服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？

为了解决这些问题，是否也可以通过一个第三方媒介呢？见图四：

图四

这个第三方主要工作是接收各个应用的服务注册和维护各服务之间的关系，当然也包括检测各服务的状态情况。集群节点状态协调（负载均衡/主从协调）这个协调服务也可以基于这种方式去实现。

3）分布式锁

最近我在学习Hadoop做数据分析这块，涉及到存在多个服务器中的程序都要访问一个共享资源文件时的文件同步问题，如下图五：

图五

这样出现的问题就是A服务里呈现在查看或更新这个共享资源时得到的数据很可能会是脏读、幻读的错误数据。解决方法也是可以利用第三方。如图六：

图六

这里的关键在A在访问之后或者获取访问权限时要把自己当前的最小id删除，同时重新生成一个新的大id。

四、总结

通过上面三个案例，我们知道这个第三方做的事主要是分布式应用程序的协调服务，如果把我们的每个应用比如成动物园里面的动物，为了更好地维护管理这些动物，那么就需要一个动物园的管理员。而zookeeper就是这么一个角色。

动物园管理员