ZooKeeper 是一个高可用的分布式数据管理与系统协调框架。基于对 Paxos 算法的实现,
使该框架保证了分布式环境中数据的强一致性,也正是基于这样的特性,使得
ZooKeeper 解决很多分布式问题。网上对 ZK 的应用场景也有不少介绍,本文将结合作者
身边的项目例子,系统地对 ZK 的应用场景进行一个分门归类的介绍。
值得注意的是,ZK 并非天生就是为这些应用场景设计的,都是后来众多开发者根据其框架
的特性,利用其提供的一系列 API 接口(或者称为原语集),摸索出来的典型使用方法。
因此,也非常欢迎读者分享你在 ZK 使用上的奇技淫巧。
ZooKeeper 典型应用场景一览
数据发布与订阅(配置中心)
发布与订阅模型,即所谓的配置中心,顾名思义就是发布者将数据发布到 ZK 节点上,供订阅者动态获取
数据,实现配置信息的集中式管理和动态更新。例如全局的配置信息,服务式服务框架的服务地址列表等
就非常适合使用。
应用中用到的一些配置信息放到 ZK 上进行集中管理。这类场景通常是这样:应用在启动的时候会主
动来获取一次配置,同时,在节点上注册一个 Watcher,这样一来,以后每次配置有更新的时候,
都会实时通知到订阅的客户端,从来达到获取最新配置信息的目的。
分布式搜索服务中,索引的元信息和服务器集群机器的节点状态存放在 ZK 的一些指定节点,供各个
客户端订阅使用。
分布式日志收集系统。这个系统的核心工作是收集分布在不同机器的日志。收集器通常是按照应用
来分配收集任务单元,因此需要在 ZK 上创建一个以应用名作为 path 的节点 P,并将这个应用的所
有机器 ip,以子节点的形式注册到节点 P 上,这样一来就能够实现机器变动的时候,能够实时通知
到收集器调整任务分配。
系统中有些信息需要动态获取,并且还会存在人工手动去修改这个信息的发问。通常是暴露出接
口,例如 JMX 接口,来获取一些运行时的信息。引入 ZK 之后,就不用自己实现一套方案了,只要
将这些信息存放到指定的 ZK 节点上即可。
注意:在上面提到的应用场景中,有个默认前提是:数据量很小,但是数据更新可能会比较快的场景。
负载均衡
这里说的负载均衡是指软负载均衡。在分布式环境中,为了保证高可用性,通常同一个应用或同一个服务
的提供方都会部署多份,达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业
务逻辑,其中比较典型的是消息中间件中的生产者,消费者负载均衡。
消息中间件中发布者和订阅者的负载均衡,linkedin 开源的 KafkaMQ 和阿里开源的 metaq 都是通过
zookeeper 来做到生产者、消费者的负载均衡。这里以 metaq 为例如讲下:
生产者负载均衡:metaq 发送消息的时候,生产者在发送消息的时候必须选择一台 broker 上的一个分区
来发送消息,因此 metaq 在运行过程中,会把所有 broker 和对应的分区信息全部注册到 ZK 指定节点
上,默认的策略是一个依次轮询的过程,生产者在通过 ZK 获取分区列表之后,会按照 brokerId 和
partition 的顺序排列组织成一个有序的分区列表,发送的时候按照从头到尾循环往复的方式选择一个分区
来发送消息。
消费负载均衡:
在消费过程中,一个消费者会消费一个或多个分区中的消息,但是一个分区只会由一个消费者来消