Zookeeper的应用场景

前言

好久没有写文章了。今天备课Zookeeper的应用场景案例，突然回忆到以前就曾想把这些内容整理到博客上，所以......今天....就弄吧，不在拖了........毕竟明日复明日.....捂脸ing！

Zookeeper的概念回忆

zookeeper是一个轻量级的分布式协调服务框架，专门为分布式应用程序（比如hdfs、hbase等）服务。它内部提供的选举机制，让它本身具有高可用性，只要满足（n+1）/2以上的服务节点存在，那么zookeeper集群就能正常提供服务。它提供的数据模型是一种类似Unix文件系统的层次化树形结构，每个znode都可以用来存储1MB的数据和子节点。正因为zookeeper针对于数据模型中的znode提供了监听和通知机制，zookeeper才能很好的为其他分布式应用程序提供协调服务。

下面我们来一起看看Zookeeper的应用场景案例吧

1、配置信息的统一管理

我们在开发过程中，有时可能需要获取某些公共配置信息，比如数据库的连接信息driver,url,username,password等，而某些时候可能会更新这些配置信息。如果在一个集群上，有多个应用程序都要用这个配置信息时，那分别去修改每个应用程序的配置会特别麻烦，并且还需要重新启动。 

但是，我们要是将这些配置信息存储在zookeeper的某一个znode里，应用程序只需要注册监听此znode，数据发生变化时，zookeeper进行通知，然后应用程序从znode里获取连接数据即可，是不是很方便啊。

参考下图

2、Master选举

在具有主从架构的分布式集群中，通常都是一个master，它是整个集群的管理者，通常拥有最终"决定权"，针对于集群能否正常工作，起着决定性的作用。那么当我们遇到master的单点故障或者是想进行停机维护升级时，集群一定会受到影响，集群的可用性就变的很差。

如果我们再准备一个备用master，随时接管整个集群的工作，那么就不怕遇到上述问题了，大大提高了集群的可用性。这种设计，我们可以使用zookeeper的监听和通知机制，来进行Master选举以及状态切换工作。

3、集群节点的动态上下线感知

4、负载均衡

5、分布式锁

在开发过程中，单个进程中的多线程对共享资源进行访问，我们只需要用synchronized或者lock就能实现互斥操作。但是对于跨进程、跨主机、跨网络的共享资源似乎就无能为力了，比如集群中服务器A，B，C，在自己的内存中都维护长春到北京N2392这列车的火车票数，当顾客多窗口买票时，访问的服务器可能是A，也可能是B，也可能是C。那如何保证三个服务器上的共享资源火车票数是同步的呢。这也可以使用zookeeper来完成。

6、分布式队列

在我们开发过程中，如果涉及到生产者-仓库-消费者模式的单进程程序时，会使用BlockingQueue来充当缓冲区的角色。但是在分布式系统中这种方式就不能使用BlockingQueue来实现了，因为分布式系统是多个服务器（多个内存），而BlockingQueue只能对一个内存进行限制。此时，Zookeeper可以实现此功能效果

思路如下：

1）首先利用Zookeeper中临时顺序节点的特点
2）当生产者创建节点生产时，需要判断父节点下临时顺序子节点的个数，如果达到了上限，则阻塞等待；如果没有达到，就创建节点。
3）当消费者获取节点时，如果父节点中不存在临时顺序子节点，则阻塞等待；如果有子节点，则获取执行自己的业务，执行完毕后删除该节点即可。
获取时获取最小值，保证FIFO特性。