Zookeeper应用场景

Zookeeper是一个高可用的分布式数据管理和协调框架,并且能够很好的保证分布式环境中数据的一致性.在越来越多的分布式系统(Hadoop、HBase、Kafka)中,Zookeeper都作为核心组件使用.

典型应用场景

  • 数据发布/订阅
  • 负载均衡
  • 命名服务
  • 分布式协调/通知
  • 集群管理
  • Master选举
  • 分布式锁
  • 分布式队列

所有的典型应用场景,都是利用了ZK的如下特性:

  • 强一致性:在高并发情况下,能够保证节点的创建一定是全局唯一的
  • Watcher机制和异步通知:可以对指定节点加上监听,当节点变更时,会收到ZK的通知

1.数据发布/订阅

数据发布/订阅(Publish/Subscribe)系统,即配置中心.需要发布者将数据发布到Zookeeper的节点上,供订阅者进行数据订阅,进而达到动态获取数据的目的,实现配置信息的集中式管理和数据的动态更新.

发布/订阅一般有两种设计模式:

  • 推模式: 服务端主动将数据更新发送给所有订阅的客户端称
  • 拉模式: 客户端主动请求获取最新数据

Zookeeper采用了推拉相结合的模式:

  • 客户端向服务端注册自己需要关注的节点,一旦该节点数据发生变更,那么服务端就会向相应的客户端推送Watcher事件通知
  • 客户端接收到这个消息通知后,需要主动到服务端获取最新的数据

若将配置信息存放到Zookeeper上进行集中管理,在通常情况下,应用在启动时会主动到Zookeeper服务端上进行一次配置信息的获取,同时,在指定节点上注册一个Watcher监听,这样在配置信息发生变更,服务端都会实时通知所有订阅的客户端,从而达到实时获取最新配置的目的.

通常,放到配置中心上的数据都具有如下特点:

  • 数据量通常比较小
  • 数据内容在运行时会发生动态变化
  • 集群中各机器共享,配置一致

2.负载均衡

负载均衡(Load Balance)是一种相当常见的计算机网络技术,用来对多个计算机(计算机集群)、网络连接、CPU、磁盘驱动或其他资源进行分配负载,以达到优化资源使用、最大化吞吐率、最小化响应时间和避免过载的目的.

使用Zookeeper实现动态DNS服务

  • 域名配置: 首先在Zookeeper上创建一个节点来进行域名配置,如DDNS/app1/server.app1.company1.com
  • 域名解析: 应用首先从域名节点中获取IP地址和端口的配置,进行自行解析.同时,应用程序还会在域名节点上注册一个数据变更Watcher监听,以便及时收到域名变更的通知
  • 域名变更: 若发生IP或端口号变更,此时需要进行域名变更操作,此时,只需要对指定的域名节点进行更新操作,Zookeeper就会向订阅的客户端发送这个事件通知,客户端之后就再次进行域名配置的获取

3.命名服务

命名服务是分步实现系统中较为常见的一类场景,分布式系统中,被命名的实体通常可以是集群中的机器、提供的服务地址或远程对象等,通过命名服务,客户端可以根据指定名字来获取资源的实体、服务地址和提供者的信息.Zookeeper也可帮助应用系统通过资源引用的方式来实现对资源的定位和使用,广义上的命名服务的资源定位都不是真正意义上的实体资源,在分布式环境中,上层应用仅仅需要一个全局唯一的名字.

Zookeeper可以实现一套分布式全局唯一ID的分配机制:

  • 客户端根据自己的业务类型,在指定类型的任务下面创建持久的顺序节点
  • 节点创建完成后,获取返回的节点名称,提取ID
  • 客户端拿到这个返回值后,拼接上type类型,这就可以作为一个全局唯一的ID了

阿里巴巴集团开源的分布式服务框架Dubbo中使用ZooKeeper来作为其命名服务,维护全局的服务地址列表.在Dubbo实现中:

  • 服务提供者在启动的时候,向ZK上的指定节点/dubbo/{serviceName}/providers目录下写入自己的URL地址,这个操作就完成了服务的发布.
  • 服务消费者启动的时候,订阅/dubbo/{serviceName}/providers目录下的提供者URL地址, 并向/dubbo/{serviceName}/consumers目录下写入自己的URL地址.

dubbo

注意:所有向ZK上注册的地址都是临时节点,这样就能够保证服务提供者和消费者能够自动感应资源的变化.另外,Dubbo还有针对服务粒度的监控,方法是订阅/dubbo/{serviceName}目录下所有提供者和消费者的信息.

4.分布式协调/通知

Zookeeper中特有的Watcher注册于异步通知机制,能够很好地实现分布式环境下不同机器,甚至不同系统之间的协调与通知,从而实现对数据变更的实时处理. 通常的做法是不同的客户端都对Zookeeper上的同一个数据节点进行Watcher注册,监听数据节点的变化(包括节点本身和子节点),若数据节点发生变化,那么所有订阅的客户端都能够接收到相应的Watcher通知,并作出相应处理.

MySQL数据复制总线:Mysql_Replicator

MySQL数据复制总线是一个实时的数据复制框架,用于在不同的MySQL数据库实例之间进行异步数据复制和数据变化通知,整个系统由MySQL数据库集群、消息队列系统、任务管理监控平台、Zookeeper集群等组件共同构成的一个包含生产者、复制管道、数据消费等部分的数据总线系统.

Mysql_Replicator

Zookeeper主要负责进行分布式协调工作,在具体的实现上,根据功能将数据复制组件划分为三个模块:

  • Core: 实现数据复制核心逻辑,将数据复制封装成管道,并抽象出生产者和消费者概念
  • Server: 启动和停止复制任务
  • Monitor: 监控任务的运行状态,若数据复制期间发生异常或出现故障则进行告警

Mysql_Replicator

在绝大多数分布式系统中,系统机器间的通信无外乎心跳检测、工作进度汇报和系统调度.

  • 心跳检测
    • 不同机器间需要检测到彼此是否在正常运行,可以使用Zookeeper实现机器间的心跳检测,基于其临时节点特性(临时节点的生存周期是客户端会话,客户端若当即后,其临时节点自然不再存在),可以让不同机器都在Zookeeper的一个指定节点下创建临时子节点,不同的机器之间可以根据这个临时子节点来判断对应的客户端机器是否存活.通过Zookeeper可以大大减少系统耦合.
  • 工作进度汇报
    • 通常任务被分发到不同机器后,需要实时地将自己的任务执行进度汇报给分发系统,可以在Zookeeper上选择一个节点,每个任务客户端都在这个节点下面创建临时子节点,这样便可以实现两个功能
      • 通过判断临时节点是否存在来确定任务机器是否存活
      • 各个任务机器可以将自己的任务执行进度写到该临时节点中去,以便中心系统能够实时获取任务的执行进度
  • 系统调度
    • Zookeeper能够实现如下系统调度模式:分布式系统由控制台和一些客户端系统两部分构成,控制台的职责就是需要将一些指令信息发送给所有的客户端,以控制他们进行相应的业务逻辑,后台管理人员在控制台上做一些操作,实际上就是修改Zookeeper上某些节点的数据,Zookeeper可以把数据变更以时间通知的形式发送给订阅客户端.

5.集群管理

Zookeeper的两大特性:

  • 客户端如果对Zookeeper的数据节点注册Watcher监听,那么当该数据及该单内容或是其子节点列表发生变更时,Zookeeper服务器就会向订阅的客户端发送变更通知
  • 对在Zookeeper上创建的临时节点,一旦客户端与服务器之间的会话失效,那么临时节点也会被自动删除

分布式日志收集系统

分布式日志收集系统的核心工作就是收集分布在不同机器上的系统日志,在典型的日志系统架构设计中,整个日志系统会把所有需要收集的日志机器分为多个组别,每个组别对应一个收集器,这个收集器其实就是一个后台机器,用于收集日志.

对于大规模的分布式日志收集系统场景,通常需要解决两个问题:

  • 变化的日志源机器
  • 变化的收集器机器

无论是日志源机器还是收集器机器的变更,最终都可以归结为如何快速、合理、动态地为每个收集器分配对应的日志源机器.使用Zookeeper的场景步骤如下

  • 注册收集器机器: 在Zookeeper上创建一个节点作为收集器的根节点
    • 例如/logs/collector的收集器节点,每个收集器机器启动时都会在收集器节点下创建自己的节点,如/logs/collector/[Hostname] 日志收集
  • 任务分发
    • 所有收集器机器都创建完对应节点后,系统根据收集器节点下子节点的个数,将所有日志源机器分成对应的若干组,然后将分组后的机器列表分别写到这些收集器机器创建的子节点,如/logs/collector/host1上去.
    • 这样,收集器机器就能够根据自己对应的收集器节点上获取日志源机器列表,进而开始进行日志收集工作.
  • 状态汇报
    • 完成任务分发后,机器随时会宕机,所以需要有一个收集器的状态汇报机制,每个收集器机器上创建完节点后,还需要再对应子节点上创建一个状态子节点,如/logs/collector/host/status,每个收集器机器都需要定期向该结点写入自己的状态信息,这可看做是心跳检测机制,
    • 通常收集器机器都会写入日志收集状态信息,日志系统通过判断状态子节点最后的更新时间来确定收集器机器是否存活.
  • 动态分配
    • 若收集器机器宕机,则需要动态进行收集任务的分配,收集系统运行过程中关注/logs/collector节点下所有子节点的变更,一旦有机器停止汇报或有新机器加入,就开始进行任务的重新分配,此时通常由两种做法:
      • 全局动态分配,当收集器机器宕机或有新的机器加入,系统根据新的收集器机器列表,立即对所有的日志源机器重新进行一次分组,然后将其分配给剩下的收集器机器.
      • 局部动态分配,每个收集器机器在汇报自己日志收集状态的同时,也会把自己的负载汇报上去,如果一个机器宕机了,那么日志系统就会把之前分配给这个机器的任务重新分配到那些负载较低的机器,同样,如果有新机器加入,会从那些负载高的机器上转移一部分任务给新机器.

上述步骤已经完整的说明了整个日志收集系统的工作流程,其中有两点注意事项.

  • 节点类型: 在/logs/collector节点下创建临时节点可以很好的判断机器是否存活,但是,若机器挂了,其节点会被删除,记录在节点上的日志源机器列表也被清除,所以需要选择持久节点来标识每一台机器,同时在节点下分别创建/logs/collector/[Hostname]/status节点来表征每一个收集器机器的状态,这样,既能实现对所有机器的监控,同时机器挂掉后,依然能够将分配任务还原.
  • 日志系统节点监听: 若采用Watcher机制,那么通知的消息量的网络开销非常大,需要采用日志系统主动轮询收集器节点的策略,这样可以节省网络流量,但是存在一定的延时.

6.Master选举

在分布式系统中,Master往往用来协调集群中其他系统单元,具有对分布式系统状态变更的决定权. 例如在读写分离的应用场景中,客户端的写请求往往是由Master来处理,或者其常常处理一些复杂的逻辑并将处理结果同步给其他系统单元.利用Zookeeper的强一致性,能够很好地保证在分布式高并发情况下节点的创建一定能够保证全局唯一性,即Zookeeper将会保证客户端无法重复创建一个已经存在的数据节点.

如果仅仅是想实现Master选举的话,那么其实只需要有一个能够保证数据唯一性的组件即可,例如关系型数据库的主键模型就是非常不错的选择.但是,如果希望能够快速进行集群Master动态选举,那么急于Zookeeper来实现是一个不错的新思路.

7.分布式锁

分布式锁用于控制分布式系统之间同步访问共享资源的一种方式,可以保证不同系统访问一个或一组资源时的一致性,主要分为排它锁和共享锁.

7.1 排他锁

排他锁(Exclusive Locks,简称X锁),又称为写锁或独占锁,是一种基本的锁类型. 若事务T1对数据对象O1加上了排它锁,那么在整个加锁期间,只允许事务T1对O1进行读取和更新操作,其他任何事务都不能再对这个数据对象进行任何类型的操作,直到T1释放了排它锁.

  • 定义锁:通过Zookeeper上的数据节点来表示一个锁,例如/exclusive_lock/lock节点就可以被定义为一个锁
  • 获取锁:在需要获取排它锁时,所有客户端通过调用接口,在/exclusive_lock节点下创建临时子节点/exclusive_lock/lock.Zookeeper可以保证只有一个客户端能够创建成功,没有成功的客户端需要注册/exclusive_lock节点监听.
  • 释放锁: /exclusive_lock/lock是一个临时节点
    • 所以以下两种情况下,都有可能释放锁
      • 当获取锁的客户端宕机,那么Zookeeper上的这个临时节点就会被移除
      • 正常完成业务逻辑后,客户端就会主动将自己创建的临时节点的删除
    • 所有在/exclusive_lock节点上注册监听的客户端都会收到通知,可以重新发起分布式锁获取

排他锁流程图

7.2 共享锁

共享锁(Shared Locks,简称S锁),又称为读锁,同样是一种基本的锁类型.若事务T1对数据对象O1加上共享锁,那么当前事务只能对O1进行读取操作,其他事务也只能对这个数据对象加共享锁,直到该数据对象上的所有共享锁都被释放.

共享锁和排他锁最根本的区别在于,加上排他锁后,数据对象只对一个对象可见,而加上共享锁之后,数据对所有事务都可见.

  • 定义锁: 通过Zookeeper上的数据节点来表示一个锁,例如/shared_lock/host1-R-00000001就可以表示成一个共享锁
  • 获取锁: 在需要获取共享锁时,所有客户端都会到/shared_lock下面创建一个临时顺序节点,如果是读请求,那么就创建例如/shared_lock/host1-R-00000001的节点,如果是写请求,那么就创建例如/shared_lock/host2-W-00000002的节点.
  • 判断读写顺序: 根据定义,不同事务可以同时对一个数据对象进行读写操作,而更新操作必须在当前没有任何事务进行读写情况下进行,通过Zookeeper来确定分布式读写顺序,大致分为四步
    • 1.创建完节点后,获取/shared_lock节点下所有子节点,并对该节点注册子节点变更的Watcher监听
    • 2.确定自己的节点序号在所有子节点中的顺序
    • 3.请求处理
      • 读请求:如果没有比自己序号小的子节点或所有比自己序号小的子节点都是读请求,那么表明自己已经成功获取到共享锁,同时开始执行读取逻辑.如果比自己序号小的子节点中有写请求,那么就需要进入等待
      • 写请求:如果自己不是序号最小的子节点,那么就需要进入等待
    • 4.接收到Watcher通知后,重复步骤1
  • 释放锁,其释放锁的流程与独占锁一致

共享锁流程图

羊群效应 上述共享锁的实现方案,可以满足一般分布式集群竞争锁的需求,但是如果机器规模扩大会出现一些问题.

羊群效应

针对如上图所示的情况进行分析

  • host1首先进行读操作,完成后将节点/shared_lock/host1-R-00000001删除
  • 余下4台机器均收到这个节点移除的通知,然后重新从/shared_lock节点上获取一份新的子节点列表
  • 每台机器判断自己的读写顺序,其中host2检测到自己序号最小,于是进行写操作,余下的机器则继续等待
  • 继续…

可以看到,host1客户端在移除自己的共享锁后,Zookeeper发送了子节点更变Watcher通知给所有机器,然而除了给host2产生影响外,对其他机器没有任何作用.大量的Watcher通知和子节点列表获取两个操作会重复运行,这样会造成系能鞥影响和网络开销,更为严重的是,如果同一时间有多个节点对应的客户端完成事务或事务中断引起节点消失,Zookeeper服务器就会在短时间内向其他所有客户端发送大量的事件通知,这就是所谓的羊群效应.

避免羊群效应的改动

  • 1.客户端调用create接口常见类似于/shared_lock/[Hostname]-请求类型-序号的临时顺序节点
  • 2.客户端调用getChildren接口获取所有已经创建的子节点列表(不注册任何Watcher)
  • 3.如果无法获取共享锁,就调用exist接口来对比自己小的节点注册Watcher
    • 对于读请求:向比自己序号小的最后一个写请求节点注册Watcher监听
    • 对于写请求:向比自己序号小的最后一个节点注册Watcher监听
  • 4.等待Watcher通知,继续进入步骤2.

此方案改动主要在于:每个锁竞争者,只需要关注/shared_lock节点下序号比自己小的那个节点是否存在即可.

共享锁流程图

8.分布式队列

分布式队列可以简单分为先入先出队列模型和等待队列元素聚集后统一安排处理执行的Barrier模型.

8.1 FIFO先入先出

FIFO(First Input First Output), 先进入队列的请求操作先完成后,才会开始处理后面的请求.FIFO队列就类似于全写的共享模型,所有客户端都会到/queue_fifo这个节点下创建一个临时节点,如/queue_fifo/host1-00000001.

创建完节点后,按照如下步骤执行

  • 1.通过调用getChildren接口来获取/queue_fifo节点的所有子节点,即获取队列中所有的元素
  • 2.确定自己的节点序号在所有子节点中的顺序
  • 3.如果自己的序号不是最小,那么需要等待,同时向比自己序号小的最后一个节点注册Watcher监听
  • 4.接收到Watcher通知后,重复步骤1

8.2 Barrier分布式屏障

Barrier分布式屏障,最终的合并计算需要基于很多并行计算的子结果来进行,开始时,/queue_barrier节点已经默认存在,并且将结点数据内容赋值为数字n来代表Barrier值,之后,所有客户端都会到/queue_barrier节点下创建一个临时节点,例如/queue_barrier/host1.

创建完节点后,按照如下步骤执行

  • 1.通过调用getData接口获取/queue_barrier节点的数据内容,如10
  • 2.通过调用getChildren接口获取/queue_barrier节点下的所有子节点,同时注册对子节点变更的Watcher监听
  • 3.统计子节点的个数
  • 4.如果子节点个数还不足10个,那么需要等待
  • 5.接受到Wacher通知后,重复步骤3

results matching ""

    No results matching ""