Zookeeper全面剖析

目录

一.zookeeper概述

二.zookeeper数据结构

 三.zookeeper节点类型

四.zookeeper操作节点的基础命令

五.zookeeper的java客户端

六.zookeeper高级特性

七.zookeeper的watch监听机制

八.zookeeper用来做分布式锁的优缺点

九.zookeeper的羊群效应

十.zookeeper的选举机制

---

一.zookeeper概述

        1.zookeeper为大型分布式计算提供开源的分布式配置服务、同步服务和命名注册。

        2.zookeeper是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。

二.zookeeper数据结构

        1.结构：zookeeper本身是一个树形目录服务（名称空间），非常类似于标准文件系统，key-value 的形式存储。

        2.结构特点：

                <1>每个路径下的节点key(完整路径，名称)是唯一的。

                <2>每个节点中存储了节点value和对应的状态属性。

   

 三.zookeeper节点类型

1.持久节点

        PERSISTENT：zk默认创建的就是持久节点，一旦创建，则永久存在于zookeeper中，除非手动删除。

2.持久有序节点

        PERSISTENT_SEQUENTIAL：zk在创建有序节点时会在路径上加序号作为后缀，有序递增的(如demo000001、demo000002…..demo00000N)。

3.临时节点

        EPHEMERAL：临时节点下面不能再创建子节点，临时节点会在客户端会话断开后由zk服务端自动删除。如果服务器重启宕机也会被删除。适合做心跳、服务发现等场景

4.临时有序节点

        EPHEMERAL_SEQUENTIAL：在临时节点基础上，创建时会在路径后面加序号。适合做分布式锁，分布式选举等场景。

5.容器节点

        CONTAINER：当子节点都被删除后，容器节点也随即删除。

6.TTL节点

        PERSISTENT_WITH_TTL：客户端断开连接后不会自动删除TTL节点，如果该TTL节点没有子节点且在给定的TTL时间内无修改，该TTL节点会被删除。

四.zookeeper操作节点的基础命令

五.zookeeper的java客户端

1. zookeeper原生API

2.Curator

3.zkClient

六.zookeeper高级特性

1.配置管理

2.服务注册、服务发现

3.负载均衡

4.分布式队列

        通过顺序节点实现分布式队列，生产者通过在某节点下创建顺序节点来存放数据，消费者通过读取顺序节点来消费数据

5.集群管理

        集群监控（状态收集），集群控制，比如Kafka， Hadoop ，Solr集群等

6.分布式服务命名

7.分布式锁

        <1> 分布式锁简介：指在分布式环境下，保护跨进程、跨主机、跨网络的共享资源，实现互斥访问，保证一致性；在zk中，锁就是一个数据节点。

        <2> 基于zk分布式锁的普通实现：注册临时节点，谁注册成功谁获取锁，其他监听该节点的删除事件，一旦被删除，通知其他客户端，再次重复该流程；此为最简单的实现，但容易引发一些问题（羊群效应） 。

        <3>基于zk分布式锁的高级实现：

                1.所有服务启动时都去zookeeper中注册一个临时顺序节点，并 将基本信息写入临时节点；

                2.所有服务获取节点列表并判断自己的节点是否是最小的那个， 谁最小谁就获取了锁；

                3.未获取锁的客户端添加对前一个节点删除事件的监听；

                4.锁释放/持有锁的客户端宕机 后，节点被删除；

                5.下一个节点的客户端收到通知，重复上述流程。

8.集群Master选举

        Master选举步骤：

                <1> 所有服务启动时都去zookeeper中注册一个临时 顺序节点，并将基本信息写入临时节点;

                <2> 所有服务判断自己的节点是否是最小的那个，谁 最小谁就是Master，其他是Slave;

                <3> Slave添加对前一个节点删除事件的监听；

                <4> Master宕机或不可用时，zookeeper会将该会话绑定的临时节点删除；

                <5> Slave接收到事件通知，重复上述流程。

七.zookeeper的watch监听机制

        watch监听机制主要用于监听节点状态变更，用于后续事件触发，假设当B节点监听A节点时，一旦A节点发生修改、删除、子节点列表发生变更等事件，B节点则会收到A节点改变的通知，接着完成其他额外事情。

八.zookeeper用来做分布式锁的优缺点

1.zk是基于cp模式的，能够保证数据的一致性

2.基于watch机制实现锁释放的自动监听，锁操作性能较好

3.频繁的创建节点对zk服务器的压力较大，吞吐量没有redis强

九.zookeeper的羊群效应

        其他线程都监听同一个锁节点，一旦锁节点释放后，其他线程都会收到通知，然后竞争获取锁节点。

         这种大量的通知操作会严重降低zookeeper性能，对于这种由于一个被watch的znode节点的变化，而造成大量的通知操作，叫做羊群效应。

十.zookeeper的选举机制

1.算法模型

（1）Paxos算法：是目前解决分布式一致性问题最有效的算法之一，是一个分布式选择具算法，遵循少数服从多数的原则（过半原则）。

（2）ZAB协议：在Paxos算法基础上进行扩展改造而来的也遵循过半原则，zk使用ZAB协议作为数据一致性算法。

        ZAB协议的四种状态：
        LOOKING：系统刚启动时或者leader宕机后正处于选举状态

        FOLLOWING：Follower节点所处的状态，同步leader状态，参与投票

        LEADING：Leader所处状态

        OBSERVING：观察状态，同步leader状态，不参与投票

2.选择所涉及的参数

        SID：服务器ID。标识zk集群的机器，每台机器不能重复，和myid一致。

        ZXID：事务ID。标识一次服务器状态的变更。

        Epoch：时间纪元（逻辑时钟）。没有Leader时，同一轮投票过程中时间纪元都是相同的，每投完一次票时间纪元加一次。每次投票都要保证在同一轮。

3.zk选举流程（集群中有5台机器 S1 - S5，那么根据过半原则需要大于等于3票）

（1）S1启动，发起一次选举。投自己1票。此时S1有1票，不够3票，无法完成选举。S1状态保持为LOOKING；

（2）S2启动，发起一次选举。S1、S2分别投自己1票并交换选票信息，此时S1发现S2的myId比自己的大，更改选票为S2。此时S1为0票，S2为2票，不够3票，无法完成选举。S1、S2状态保持LOOKING；

（3）S3启动，发起一次选举。此时S1、S2都会更改选票为S3。此时S1、S2为0票，S3为3票已过半，S3当选Leader。S1、S2更改状态为FOLLOWING，S3更改状态为LEADING；

（4）S4启动，发起一次选举，此时S1、S2、S3已经不是LOOKING状态，不会更改选票信息，S4投自己1票。此时交换选票信息结果为：S1、S2为0票，S3为3票，S4为1票，少数服从多数，S4更改选票信息为S3，并更改状态为FOLLOING；

（5）S5启动，同S4一样当小弟。