一.Zookeeper

1. zookeeper是什么?

Zookeeper是一个分布式协调服务
作用 : 解决分布式集群中应用系统的一致性问题
例如:怎样避免同时操作同一数据造成脏读的问题

本质 : Zookeeper本质是一个分布式的小文件存储系统.类似于文件管理系统.以目录树的方式进行数据存储.并且可以对树中的节点进行有效管理.从而用来维护和监控存储的数据的状态变化.通过监控这些数据状态的变化,从而可以达到基于数据的集群管理.
例如 : 统一命名服务,分布式配置管理,分布式消息队列,分布式锁,分布式协调等功能

• ZooKeeper集群角色
  Leader : Zookeeper集群工作的核心(老大的角色)

作用 : 事务请求的唯一调度者和处理者,保证集群事务处理的顺序性;集群内部各个服务器的调度者.
Follower : 小弟角色
作用 : 处理客户端非事务(读操作)请求,凡是触及到事务操作统一转发到Leader;参与集群Leader选举投票
Observer : 观察者角色
作用 : 观察Zookeeper集群的最新状态变化并将这些状态同步,可以对非事务请求独立处理,对于事务请求则转发给Leader进行处理.
不会参与任何形式的投票只提供事务服务,通常用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力(优化).

• zookeeper特性
  (1)全局数据一致

每个server保存一份相同的数据副本,client无论连接哪个server,展示的数据都是一致的
(2)可靠性
一旦一个更新操作被应用,那么在客户端再次更新它之前,它的值将不会改变.这个保证会产生两种结果:
     * 如果客户端成功获得了正确的返回数据,那么说明更新已经成功,如果不能够返回正确数据(由于通信错误,超时..),客户端将不知道更新操作是否生效,服务器进行回滚操作
     * 当从故障恢复的时候,任何客户端能够看到执行成功的更新操作将不会回滚
(3)顺序性
全局有序 : 在一台服务器上消息a在消息b前发布,则在所有server上消息a将在消息b前被发布
偏序 : 如果一个消息b在消息a后被同一个发送者发布,a必将排在b前面
(4)数据更新原子性
一次数据更新要么成功(半数以上节点成功),要么失败,不存在中间状态
(5)实时性
Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息,或者服务器失效的信息

2.Zookeeper数据模型

Zookeeper的数据模型,在结构上和标准文件系统非常相似,拥有一个层次的命名空间,都是采用树形层次结构,ZooKeeper树中的每个节点被称为Znode.和文件系统的目录树一样,Zookeeper树中的每个节点可以拥有子节点
其不同之处在于:
(1)Znode兼具文件和目录两种特点.即像文件一样可以存储数据,元信息,ACL,时间戳等数据结构,又向目录一样可以作为路径标识的一部分,并可以具有子Znode.用户对Znode具有增删改查等操作(前提是具有相应权限).

(2)Znode具有原子性操作,读操作将获取与节点相关的所有数据,写操作也将替换掉节点的所有数据.另外每个节点都拥有自己的ACL(访问控制列表),这个列表规定了用户的权限,即限定了特定用户对目标节点可以执行的操作

(3)Znode存储数据大小有限制, Zookeeper虽然可以关联一些数据,但并没有被设计为常规的数据库或者大数据存储,相反的是,它用来管理调度数据,比如分布式应用中的配置文件信息,状态信息,汇集信息等等.这些数据的共同特性就会他们都是很小的数据,通常以KB为大小单位.Zookeeper的服务器和客户端都被设计为严格检查屏限制每个Znode的数据大小至多1M

(4)Znode通过路径引用,如同unix中的文件路径.路径必须是绝对的,因此他们必须由斜杠字符来开头.除此以外,他们必须是唯一的,意思就是说每个路径只有一个表示,因此这些路径不能改变,在Zookeeper中,路径由Unicode字符串组成,并且有一些限制.字符串"/zookeeper"用以保存管理信息,比如关键配额信息

• 数据结构
  每个Znode由3部分组成:

(1)stat : 此为状态信息,描述该Znode的版本,权限等信息
(2)data : 与该Znode关联的数据
(3)children : 该Znode下的子节点

• 节点类型
  Znode分为两种:

(1)临时节点
该节点的声明周期依赖于创建他们的会话,一旦会话结束,临时节点将被自动删除,也可以手动删除,临时节点不允许拥有子节点.
(2)永久节点
该节点的声明周期不依赖于会话,并且只有在客户端显示执行删除操作的时候,他们才能被删除
Znode还有一个序列化的特性,如果创建的时候指定的话,该Znode的名字后面会自动追加一个不断增加的序列号.序列号对于此节点的父节点来说是唯一的,这样便会就每个子节点创建的先后顺序,它的格式为"%10d"(10位数字,没有数值的数位用0补充)
这样便会存在四种类型的Znode节点,分别对应:
PERSISTENT: 永久节点
EPHEMERAL : 临时节点
PERSISTENT_SEQUENTIAL : 永久节点,序列化
EPHEMERAL_SEQUENTIAL : 临时节点,序列化

3.Zookeeper Watch

Watch实际就是Zookeeper的监听机制.一个Watch事件是一个一次性的触发器
Zookeeper的watch实际上要处理两类事件

• 连接状态事件(type=None,path=null)
  这类事件不需要注册,也不需要连续触发,只需处理就OK

None 在客户端与Zookeeper集群中的服务断开连接的时候,客户端会收到这个事件

• 节点事件
  NodeCreated Znode创建事件

NodeDelete Znode删除事件
NodeDataChangedd Znode数据内容更新时间.(本质上该事件只关注dataVersion版本号,但是只要调用了更新接口dataVersion就会有变更)
NodeChildrenChanged Znode子节点改变事件(只关注子节点的个数变更,子节点内容有变是不会通知的)

4.Zookeeper选举机制

zookeeper默认的算法是FastLeaderElection,采用投票数大于半数则胜出的逻辑.

• 概念
  (1)服务器ID

例如:三台服务器, 编号分别为1,2,3
编号越大在选择算法中的权重越大
(2)选举状态
LOOKING,竞选状态
FOLLOWING,随从状态,同步Leader状态,参与投票.
OBSERVING,观察状态,同步Leader状态,不参与投票
LEADER,领导者状态
(3)数据ID
服务器中存放的最新数据 version
值越大说明数据越新,在选举算法中国数据越新权重越大
(4)逻辑时钟
投票次数,同一轮投票过程中的逻辑时钟值是相同的,每投完一次票这个数据就会增加,然后与接收到的其他服务器返回的投票信息中的数值相比,根据不同的值做出不同的判断

• 全新集群选举
  假设目前有 5 台服务器， 每台服务器均没有数据，它们的编号分别是

1,2,3,4,5,按编号依次启动，它们的选择举过程如下：
(1) 服务器 1 启动，给自己投票，然后发投票信息，由于其它机器还没有启
动所以它收不到反馈信息，服务器 1 的状态一直属于 Looking。
(2)服务器 2 启动，给自己投票，同时与之前启动的服务器 1 交换结果，由
于服务器 2 的编号大所以服务器 2 胜出，但此时投票数没有大于半数，
所以两个服务器的状态依然是 LOOKING。
(3)服务器 3 启动，给自己投票，同时与之前启动的服务器 1,2 交换信息，
由于服务器 3 的编号最大所以服务器 3 胜出，此时投票数正好大于半数，
所以服务器 3 成为领导者，服务器 1,2 成为小弟。
(4)服务器 4 启动，给自己投票，同时与之前启动的服务器 1,2,3 交换信息，
尽管服务器 4 的编号大，但之前服务器 3 已经胜出，所以服务器 4 只能
成为小弟 。
(5)服务器 5 启动，后面的逻辑同服务器 4 成为小弟

• 非全新集群选举
  对于运行正常的 zookeeper 集群， 中途有机器 down 掉， 需要重新选举时，

选举过程就需要加入数据 ID、 服务器 ID 和逻辑时钟。
数据 ID：数据新的 version 就大，数据每次更新都会更新 version。
服务器 ID：就是我们配置的 myid 中的值，每个机器一个。
逻辑时钟：这个值从 0 开始递增,每次选举对应一个值。 如果在同一次选举
中,这个值是一致的。
这样选举的标准就变成：
1、逻辑时钟小的选举结果被忽略，重新投票；
2、统一逻辑时钟后，数据 id 大的胜出；
3、数据 id 相同的情况下， 服务器 id 大的胜出；
根据这个规则选出 leader。

5.Zookeeper典型应用

(1)数据发布与订阅
(2)命名服务
(3)分布式锁