ZooKeeper的典型应用场景

ZooKeeper是一个高可用的分布式数据管理与协调框架

• ZAB算法的实现，很好的保证了分布式系统数据一致性

数据发布/订阅

• 数据发布/订阅系统，即所谓配置中心
• 发布者发布数据到ZooKeeper的一系列节点上，供订阅者订阅，达到动态更新数据的目的
• 实现数据的集中式管理和动态更新

发布/订阅系统通常有推（Push）和拉（Pull）两种模式

• 推（Push）：服务端主动将数据推送给客户端
• 拉（Pull）：客户端主动去服务端拉取最新数据，通常客户端采起定时轮询的策略
• ZooKeeper才去的是推拉结合的策略
  • 客户端向服务端注册须要关注的节点，服务端数据发生变化的时候向客户端推送watcher事件通知，客户端再主动去服务端拉取数据

负载均衡

• 常见的计算机网络技术，对多台计算机、CPU、磁盘驱动器等分配负载；
• 达到优化资源使用、最小化响应时间、最大化吞吐率、避免过载的目的
• 分为软负载和硬负载；ZooKeeper属于软件负载

比较典型的是DNS 服务：

• DNS是（Domain Name System）域名系统的缩写
• 能够看作是一个超大规模的分布式映射表（域名-->IP），方便人们经过域名访问互联网站点
• 实际开发中一般采用本地host 绑定来实现域名解析

基于ZooKeeper实现的动态域名解析方案（DDNS ：Dynamic DNS）：

• 域名解析由每一个应用本身解决；
• 每一个应用还会在数据节点上注册一个数据变动Watcher，以便收到变动通知；
  • 好处：
    • 一方面避免带来域名无限增加带来的集中式管理压力
    • 另外一方面域名变动，逐台更新本地HOST的繁琐

自动化的DNS服务器

• 整个框架是域名解析的服务提供者，须要域名解析的客户属于消费者

系统运行过程：

• 域名注册
  • 每一个服务启动过程当中，把本身的域名信息注册到Register集群
  • Register将信息写入ZooKeeper对应域名数据节点
• 域名解析：
  • 消费者向Dispatcher 发起查询，Dispatcher返回结果
• 域名探测：
  • DDNS系统对全部注册的域名进行可用性检测（健康度检测）
  • 分两种：
    • 服务端主动发起健康度心跳检测，通常须要服务端和客户端创建TCP长链接
    • 客户端发起健康度心跳检测
  • DDNS 采用的是每一个服务提供者定时向Scanner 汇报健康度的形式（第二种）
    • Scanner会记录时间，一旦超过5秒没收到状态汇报，就会清理域名

命名服务（Name Service）

• 命名服务是分布式系统最基本的公共服务之一
• 分布式系统中，被命名实体：集群中的机器，提供的服务地址或远程对象等，均可称为名字（Name）
  • 比较常见的如：分布式服务框架（RPC、RMI），客户端程序经过名字能够获取资源实体、服务地址、提供者信息等
• ZooKeeper命名服务，经过资源引用的方式对资源进行定位和使用

ZooKeeper实现分布式全局惟一ID分配机制

• 在单库单表数据库中，auto_increment 就好
• 分布式环境下全局惟一ID：
  • UUID：universial unique identity，通用惟一识别码
  • GUID：Global unique identity，是hibernate 对UUID 的实现
• UUID 能很是简便的实现惟一性，存在缺陷：
  • 包含32位字符和4个短线字符串，长度过长
  • 含义不明
• ZooKeeper全局惟一id生成：
  • 客户端根据任务类型，在各自任务类型下顺序生成id
  • 节点名拼接上类型，获取完整全局惟一id

分布式协调/通知

• 分布式协调/通知服务，是分布式系统必不可缺环节，不一样分布式组件有机结合起来关键所在
• 对于多台机器上部署运行的应用，须要一个协调者（coordinator）
  • 从应用中抽离出来分布式协调
  • 解耦各个系统之间耦合性，加强扩展性
• ZooKeeper中特有的Watcher机制和异步通知机制
  • 能很好地实现数据变动的实时处理

mysql数据复制总线（mysql_replicator）

• 实时数据复制框架，在不一样mysql数据库实例之间进行实时异步数据复制和数据变化通知
• 整个系统包括：mysql数据库集群、消息队列系统、任务管理监控平台、ZooKeeper集群等组件
• 包含数据生产者、复制管道、数据消费者等部分

• 分三个核心子模块，每一个模块都是单独进程

• 每一个模块独立进程部署在服务端
• 运行时数据和配置信息均保存在ZooKeeper
• web控制台根据ZooKeeper上的信息获取到后台数据，发布控制信息

任务注册：

• core启动的时候首先向数据节点（/mysql_replicator/taskes）注册”任务列表节点“
  • 好比一个复制热门商品的任务

任务热备份

• 为了应对复制中可能出现的问题（如：复制任务故障或复制任务主机故障）
• 复制组件采用热备份的容灾形式，即将同一个复制任务，部署在不一样的主机上
• 主、备任务主机经过ZooKeeper相互检查健康情况
• 下图中，HostName一、2这样的临时顺序节点
• 完成子节点建立后，每台机器都能获取本身的节点；
• 对比判断本身是不是最小节点，最小状态RUNNING、其余STANDBY（小序号优先策略）

热备切换

• RUNNING正常复制、STANDBY待命
• RUNNING故障，STANDBY最小节点变成RUNNING
• 具体实现：全部STANDBY注册子节点数据变动Watcher 到RUNNING机器
• RUNNING机器与ZooKeeper断开链接，对应数据节点就会消失，Watcher会受到事件

记录执行状态

• RUNNING机器将运行时的任务上下文状态保留给STANDBY机器
• 写入lastCommit节点

控制台协调

• Server管理core组件，将其复制相关元数据，写入数据节点，以备其余机器共享

冷备切换

• core进程被分配对应Group，扫描组下task列表，以下图：

冷热备份对比

• 热备份：每一个任务分配两台机器，Watcher机制交互，实时性强，资源浪费大
• 冷备份：扫描的方式，下降了实时性，节省资源

一种分布式系统机器间通讯方式：

• 机器间通讯无外乎：心跳检测、工做进度汇报、系统调度三种类型
• 心跳检测
  • 一般机器间相互创建链接，肯定心跳（对方是否依然存活）
  • 使用ZooKeeper实现，各个机器都在ZooKeeper指定位置建立临时节点，根据临时节点判断对应客户端是否存活
• 工做进度汇报
  • 任务分发系统，会把任务分发给不一样的机器，各个机器向其汇报任务进度
  • 每一个任务客户端都在这个节点下面建立临时子节点，这样不只能够判断机器是否存活，
  • 同时各个机器能够将本身的任务执行进度写到该临时节点中去，以便中心系统可以实时获取任务的执行进度
• 系统调度
  • Zookeeper可以实现以下系统调度模式：分布式系统由控制台和一些客户端系统两部分构成
  • 控制台的职责就是须要将一些指令信息发送给全部的客户端，以控制他们进行相应的业务逻辑
  • 后台管理人员在控制台上作一些操做，实际上就是修改Zookeeper上某些节点的数据
  • Zookeeper能够把数据变动以事件通知的形式发送给订阅客户端

集群管理

• 集群监控和集群控制
• Zookeeper的两大特性：
  •  客户端若是对Zookeeper的数据节点注册Watcher监听，那么当该数据节点内容或是其子节点列表发生变动时，Zookeeper服务器就会向订阅的客户端发送变动通知。
  • 对在Zookeeper上建立的临时节点，一旦客户端与服务器之间的会话失效，那么临时节点也会被自动删除。

分布式日志收集系统

• 重点看收集器模块
• 日志源机器分为多个组，每一个组有一个收集器（收集机器）

一般须要解决两个问题：

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

一、注册收集器机器

• 每一个收集器机器启动时都会在收集器节点下建立本身的节点，如/logs/collector/[Hostname]

二、任务分发

• 系统根据收集器节点下子节点的个数，将全部日志源机器分红对应的若干组
• 将分组后的日志源机器列表分别写到这些收集器机器建立的子节点
• 收集器机器就可以根据本身对应的收集器节点上获取日志源机器列表，进而开始进行日志收集工做。

三、状态汇报

• 完成任务分发后，机器随时会宕机
• 每一个收集器机器上建立完节点后，还须要再对应子节点上建立一个状态子节点，如/logs/collector/host/status
• 每一个收集器机器都须要按期向该结点写入本身的状态信息，这可看作是心跳检测机制，一般收集器机器都会写入日志收集进度信息
• 志系统经过判断状态子节点最后的更新时间来肯定收集器机器是否存活。

四、动态分配

• 若收集器机器宕机，则须要动态进行收集任务的分配
• 收集系统运行过程当中关注/logs/collector节点下全部子节点的变动，一旦有机器中止汇报或有新机器加入，就开始进行任务的从新分配
• 一般由两种作法：
  • 全局动态分配：对全部的日志源机器从新进行一次分组，而后将其分配给剩下的收集器机器。
  • 局部动态分配：
    • 每一个收集器机器在汇报本身日志收集状态的同时，也会把本身的负载汇报上去
    • 若是一个机器宕机了，那么日志系统就会把以前分配给这个机器的任务从新分配到那些负载较低的机器，
    • 一样，若是有新机器加入，会从那些负载高的机器上转移一部分任务给新机器。

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

• 节点类型
  • 在/logs/collector节点下建立临时节点能够很好的判断机器是否存活，可是，若机器挂了，其节点会被删除，记录在节点上的日志源机器列表也被清除，
  • 因此须要选择持久节点来标识每一台机器，同时在节点下分别建立/logs/collector/[Hostname]/status节点来表征每个收集器机器的状态，
  • 这样，既能实现对全部机器的监控，同时机器挂掉后，依然可以将分配任务还原。
• 日志系统节点监听
  • 若采用Watcher机制，收集器节点状态变动可能很频繁，那么通知的消息量的网络开销很是大，
  • 须要采用日志系统主动轮询收集器节点的策略，这样能够节省网络流量，可是存在必定的延时（考虑分布式日志收集系统定位，这点延时可接受）。

在线云主机管理

• 一般该类系统需求点以下：

• 解决：
  • 采用ZooKeeper，将指定的Agent 部署到被监控机器上去，机器启动，会在ZooKeeper添加临时节点（这样断开时，临时节点也会被删除）
  • Agent定时写入本身状态

Master选举

• 在分布式系统中，Master每每用来协调集群中其余系统单元，具备对分布式系统状态变动的决定权，
• 如在读写分离的应用场景中，客户端的写请求每每是由Master来处理，
• 或者其经常处理一些复杂的逻辑并将处理结果同步给其余系统单元。
• 利用Zookeeper的强一致性，
  • 可以很好地保证在分布式高并发状况下节点的建立必定可以保证全局惟一性，
  • 即Zookeeper将会保证客户端没法重复建立一个已经存在的数据节点。

• 具体过程：
  • 首先建立/master_election/2013-09-20节点，客户端集群天天会定时往该节点下建立临时节点，如/master_election/2013-09-20/binding，
  • 这个过程当中，只有一个客户端可以成功建立，此时其变成master，
  • 其余节点都会在节点/master_election/22013-09-20上注册一个子节点变动的Watcher，用于监控当前的Master机器是否存活，
  • 一旦发现当前Master挂了，其他客户端将会从新进行Master选举。

分布式锁

• 分布式锁用于控制分布式系统之间同步访问共享资源的一种方式，
• 能够保证不一样系统访问一个或一组资源时的一致性，主要分为排他锁和共享锁。
• 排他锁又称为写锁或独占锁
  • 若事务T1对数据对象O1加上了排它锁，那么在整个加锁期间，
  • 只容许事务T1对O1进行读取和更新操做，其余任何事务都不能再对这个数据对象进行任何类型的操做，直到T1释放了排它锁
    1. 获取锁，在须要获取排它锁时，全部客户端经过调用接口，在/exclusive_lock节点下建立临时子节点/exclusive_lock/lock。    
       • Zookeeper能够保证只有一个客户端可以建立成功，没有成功的客户端须要注册/exclusive_lock节点监听。
    2. 释放锁，当获取锁的客户端宕机或者正常完成业务逻辑都会致使临时节点的删除，
       • 此时，全部在/exclusive_lock节点上注册监听的客户端都会收到通知，能够从新发起分布式锁获取。

• 共享锁又称为读锁
  • 若事务T1对数据对象O1加上共享锁，那么当前事务只能对O1进行读取操做，
  • 其余事务也只能对这个数据对象加共享锁，直到该数据对象上的全部共享锁都被释放。

• 获取锁，在须要获取共享锁时，全部客户端都会到/shared_lock下面建立一个临时顺序节点，
  • 若是是读请求，那么就建立例如/shared_lock/host1-R-00000001的节点，
  • 若是是写请求，那么就建立例如/shared_lock/host2-W-00000002的节点。

• 判断读写顺序，不一样事务能够同时对一个数据对象进行读操做，而更新操做必须在当前没有任何事务进行读状况下进行，

  • 经过Zookeeper来肯定分布式读写顺序，大体分为四步：

    • 1. 建立完节点后，获取/shared_lock节点下全部子节点，并对该节点变动注册监听。

    • 2. 肯定本身的节点序号在全部子节点中的顺序。

    • 3. 对于读请求：

      • 若没有比本身序号小的子节点或全部比本身序号小的子节点都是读请求，那么代表本身已经成功获取到共享锁，同时开始执行读取逻辑，

      • 如有写请求，则须要等待。

      • 对于写请求：

        • 若本身不是序号最小的子节点，那么须要等待。

    • 4. 接收到Watcher通知后，重复步骤1。

• 释放锁，其释放锁的流程与独占锁一致。

羊群效应（惊群效应）

• 能够看到，host1客户端在移除本身的共享锁后，Zookeeper发送了子节点更变Watcher通知给全部机器，
• 然而除了给host2产生影响外，对其余机器没有任何做用。
• 大量的Watcher通知和子节点列表获取两个操做会重复运行，这样会形成系能鞥影响和网络开销，
• 更为严重的是，若是同一时间有多个节点对应的客户端完成事务或事务中断引发节点小时，Zookeeper服务器就会在短期内向其余全部客户端发送大量的事件通知，这就是所谓的羊群效应。

能够有以下改动来避免羊群效应：

1. 客户端调用create接口常见相似于/shared_lock/[Hostname]-请求类型-序号的临时顺序节点。
2. 客户端调用getChildren接口获取全部已经建立的子节点列表（不注册任何Watcher）。
3. 若是没法获取共享锁，就调用exist接口来对比本身小的节点注册Watcher。
   • 对于读请求：向比本身序号小的最后一个写请求节点注册Watcher监听。
   • 对于写请求：向比本身序号小的最后一个节点注册Watcher监听。
4.  等待Watcher通知，继续进入步骤2。

此方案改动主要在于：每一个锁竞争者，只须要关注/shared_lock节点下序号比本身小的那个节点是否存在便可。

注意：

• 改进方案主要是缩小锁做用范围，和多线程并发编程思路同样
• 改进后方案比较麻烦
• 并非说非要用改进后的方案：
  • 若是集群规模不大，资源相对没那么紧张，第一种方案简单直接
  • 若是规模达到必定程度，精细管理锁的做用范围显得很重要

分布式队列

分布式队列能够简单分为先入先出队列模型和等待队列元素汇集后统一安排处理执行的Barrier模型。

• FIFO先入先出，先进入队列的请求操做先完成后，才会开始处理后面的请求。
  • FIFO队列就相似于全写的共享模型，
  • 全部客户端都会到/queue_fifo这个节点下建立一个临时节点，如/queue_fifo/host1-00000001。

• 建立完节点后，按照以下步骤执行：

  　　1. 经过调用getChildren接口来获取/queue_fifo节点的全部子节点，即获取队列中全部的元素。

  　　2. 肯定本身的节点序号在全部子节点中的顺序。

  　　3. 若是本身的序号不是最小，那么须要等待，同时向比本身序号小的最后一个节点注册Watcher监听。

  　　4. 接收到Watcher通知后，重复步骤1。

 

Barrier分布式屏障

 

• 建立完节点后，按照以下步骤执行。

　　1. 经过调用getData接口获取/queue_barrier节点的数据内容，如10。

　　2. 经过调用getChildren接口获取/queue_barrier节点下的全部子节点，同时注册对子节点变动的Watcher监听。

　　3. 统计子节点的个数。

　　4. 若是子节点个数还不足10个，那么须要等待。

　　5. 接受到Wacher通知后，重复步骤3。