Zookeeper特性与节点数据类型详解

Zookeeper简介

一个基于观察者模式，主要是用来解决分布式集群应用系统一致性问题的协调框架，基于CP机制
- 本质是一个分布式的小文件存储系统(文件系统+监听机制)
- 提供基于类似于文件系统的目录树方式的数据存储，并且可以对树种的节点进行有效管理，从而用来维护和监控存储的数据的状态变化，通过监控这些数据状态的变化，从而可以达到基于数据的集群管理、统一命名服务、分布式配置管理、分布式消息队列、分布式锁、分布式协调等功能
数据结构
- 文件树形层次 + KV结构
  - 问题：使用文件系统模型的原因
    - 便于表达数据之间的层次关系
    - 便于不同的应用分配独立的命名空间

CAP&Base理论

CAP

CAP理论指出对于一个分布式计算系统来说，不可能同时满足以下三点
- 一致性©: 在分布式环境下，系统对某数据执行写操作之后仍能保证多个节点访问到相同的该数据
- 可用性(A): 每次访问都能成功响应，但不能保证获取实时数据
- 分区容错性§: 在分布式环境下，能保证在非网络问题故障下稳定运行，仍能保证CP
注意:
- 在分布式系统下仅能保证三中之二，而且P必须满足，所以只有CP、AP两种选择
  - ZK采用CP机制
  - Eureka采用AP机制

问题: Zookeeper是强一致性吗
- ZK写要保证leader是最新的，所以写是强一致性的
- 读是顺序一致性的，ZK节点是读写是携带版本号的，雷同乐观锁，只能保证最终一致性，因为读取是按照顺序操作的，可能读取不到实时数据

Base理论

基本可用：在分布式系统出现故障的情况下，允许损失一定的可用性来保证基本可用，比如通过服务降级、页面降级等措施
软状态: 在分布式系统允许出现不影响系统可用性的写数据延迟
最终一致性: 数据备份节点经过一段时间达到一致性
引申
- Base理论就是对于CAP中C和A的权衡，我们无法保证强一致，但是能通过适当的方式保证最终一致性
  - 弱一致性: 系统中对于某数据的写操作后，无法保证在不同时间段读取到一致的数据
  - 最终一致性: 系统在保证没有新的写操作的情况下，读取到的数据是一致的最新数据
  - 顺序一致性: 任何一次读都能读到最近一次写的数据，并且新的写入是建立在已经达成同步的基础上的

核心概念

文件系统数据结构

节点分类

持久节点(persistent): 服务断开连接之前，节点数据能持久化下来
持久顺序节点(persistent_sequential): 基于持久节点特性，给每个节点进行顺序编号
临时节点(ephemeral): 服务端口连接之后，节点被删除
临时顺序节点(ephemeral_sequential): 基于临时节点特性，给每个节点进行顺序编号
容器节点(container): 容器节点下没子节点的情况下会被定时清除
TTL(time to live): 默认禁用，带过期时间的节点，需要在系统配置文件zoo.cfg中添加extendedTypesEnabled=true开启，ttl不能用于临时节点，而且不稳定

监听通知机制

客户端注册监听它关心的任意节点，或者目录节点以及递归子节点
- 如果注册了某个节点监听，那么当这个节点被删除或者被修改时，对应的客户端将被通知
- 如果注册的是对某个目录的监听，那么当这个目录有子节点被创建或者有子节点被删除，对应的客户端将被通知
- 如果注册的是对某个目录的递归子节点进行监听，那么当这个目录下面的任意子节点有目录结构的变化(有子节点被创建或被删除)或者根节点有数据变化时，对应的客户端将被通知
- 简化: 监测是一次性的，每次触发之后都需要重新进行注册，如果注册了监听，任何写操作都会通知客户端一次
注意: 所有通知都是一次性的，即无论是对节点还是对目录进行的监听，一旦触发，对应的监听立即被移除。递归子节点，监听是对所有子节点，所以每个子节点下面的事件同样只会被触发一次

watcher的过程

客户端向服务端注册watcher
服务端事件发生触发watcher
客户端回调watcher得到触发事件情况
注意: zk中的watch机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知给客户端

应用场景

分布式配置中心
分布式注册中心
分布式锁
- 创建一个目录mylock
- 线程A想获取锁就在mylock目录下创建临时顺序节点
- 获取mylock目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，就说明当前线程顺序号最小，获取锁
- 线程B获取所有节点，判断自己是不是最小节点，设置监听比自己小的节点
- 线程A处理完，删除自己的节点，线程B监听到变更时间，判断自己是不是最小的节点，如果是获取锁
分布式队列
分布式屏障
发布/订阅(常用于配置中心)
- 数据发布/订阅的一个常见的场景是配置中心，发布者把数据发布到zk的一个或一系列的节点上，供订阅者进行数据订阅，达到动态获取数据的目的
- 配置中心一般有几个特点
  - 数据量小的kv
  - 数据内容在运行时发生动态变化
  - 集群机器共享，配置一致
- zk采用的是推拉结合的方式
  - 推: 服务端会推给注册了监控节点的客户端watcher事件通知
  - 拉: 客户端获得通知后，然后主动到服务端拉取最新的数据
负载均衡: 在zk中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求
统一命令服务
- 在分布式环境下，经常需要对应用/服务进行统一命名，便于识别，例如：ip不容易记住，而域名容易记住
- 利用zk顺序节点的特性，制作分布式的序列号生成器(id生成器)
- 分布式环境下使用作为数据库id，另外一种是UUID(缺点:没有规律)，zk可以生成有顺序的容易理解的同时支持分布式环境的编号