一小时撸完zookeeper，快速掌握分布式锁如何实现

概述

开源的、分布式的，为分布式应用提供的apache项目 工作机制 zookeeper从设计模式的角度来理解:是一个基于观察者模式设计的分布式服务管理框架，他负责管理存储和管理大家关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，zookeeper将负责通知已经在zookeeper注册的那些观察者做出相应的反应 特性

• 全局数据一致
• 可靠性
• 顺序性
• 数据更新原子性
• 实时性

zookeeper角色

• Leader Zookeeper集群核心 事务请求(写操作) 的唯一调度者和处理者，保证集群处理事务的顺序性； 集群内部各个服务器的调度者。 对于create、setData、delete等有写操作的请求，则需要统一转发给leader处理，leader需要决定编号、执行操作，这个过程称为一个事务。
• Follower

处理客户端非事务请求，转发事务请求给Leader； 参与集群Leader选举。

• Observer 观察者角色，观察zookeeper集群的最新状态变化并将这些状态同步过来，其对于非事务请求可以单独处理，事务请求转发给leader处理 不参与任何形式的投票，只提供非事务服务

zookeeper集群搭建

搭建步骤

• 配置主机名到IP地址映射
• 修改zookeeper配置文件
• 远程复制分发安装文件
• 设置myid
• 启动zookeeper集群

搭建过程

1.下载zookeeper wget http://mirror.bit.edu.cn/apache/zookeeper/zookeeper-3.4.13/zookeeper-3.4.13.tar.gz 2.解压到 /usr/local/src下 tar -xvzf zookeeper-3.4.13.tar.gz 3.改名 mv zookeeper-3.4.13 zookeeper 4.进入到conf目录下 5.复制zoosample.cfg 三份，分别命名为 zoo1.cfg zoo2.cfg zoo3.cfg 6.修改zoo_1.cfg内容如下

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/usr/local/data/zk1/data
clientPort=2181
server.1=localhost:2287:3387
server.2=localhost:2288:3388
server.3=localhost:2289:3389

7.修改zoo_2.cfg内容如下

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/usr/local/data/zk1/data
clientPort=2182
server.1=localhost:2287:3387
server.2=localhost:2288:3388
server.3=localhost:2289:3389

8.修改zoo_3.cfg内容如下

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/usr/local/data/zk1/data
clientPort=2183
server.1=localhost:2287:3387
server.2=localhost:2288:3388
server.3=localhost:2289:3389

9.执行命令创建文件夹和myid

mkdir -p /usr/local/data/zk1/data
mkdir -p /usr/local/data/zk2/data
mkdir -p /usr/local/data/zk3/data
echo "1" > /usr/local/data/zk1/data/myid
echo "2" > /usr/local/data/zk2/data/myid
echo "3" > /usr/local/data/zk3/data/myid

10.在bin目录下执行以下命令启动zookeepe集群

zkServer status ../conf/zoo_1.cfg
zkServer status ../conf/zoo_2.cfg
zkServer status ../conf/zoo_3.cfg

11.在bin目录下执行以下命令查看每个节点状态

zkServer.sh status ../conf/zoo_1.cfg
zkServer.sh status ../conf/zoo_2.cfg
zkServer.sh status ../conf/zoo_3.cfg

zookeeper数据模型

• Znode兼具文件和目录两种特点
• 即像文件一样维护着数据又像目录一样可作为路径标识的一部分
• Znode具有原子操作性
• Znode存储具有限制 kb级别
• Znode通过路径引用，路径必须是绝对的
• Znoe组成
  1. stat 状态信息，描述该Znode的版本、权限信息
  2. data 与该Znode关联的数据
  3. children 该Znode下的子节点
• 节点类型
  1. 临时节点 会话结束，临时节点自动删除，临时节点不允许拥有子节点
  2. 永久节点 除非手动删除才消失 不能修改成临时节点
  3. 序列化节点
• 节点属性
  1. dataversion 每次set后都会修改dataversion
  2. cversion 子节点修改后会更新cversion
  3. czxid Znode创建的事务ID
  4. mzxid 被修改的事务ID
  5. ctime 节点创建时间
  6. mtime 节点更新时间
  7. ephemeralOwner 如果节点为临时节点 值标识与该节点绑定的sessionid,如果不是则为0

zookeeper 命令

• 创建连接

zkCli.sh -p host:port

• 创建节点

create [-e] [-s] path acl
-e 创建临时节点 -s 创建序列化节点

• 删除节点

delete path
不能删除有子节点的节点，除非子节点内容为空

• 递归删除节点

rmr path

• 节点限制

setquota -n | -b val path
n 标识子节点个数 -b 表示数据大小
listquota 查看设置信息
delquota -n | -b path 删除设置信息

• 历史命令

history 查看历史命令
redo num 重新执行某条命令

Zookeeper Watcher

Zookeeper提供了分布式数据发布/订阅功能，Zookeeper引入watcher机制来实现这种分布式的通知功能，zookeeper允许客户端向服务端注册一个watcher监听，当服务端的一些事件触发了这个watcher，那么就会像客户端发送通知。 触发事件的种类：节点删除、节点改变、子节点改变等。 总体来说，watcher概括为以下三个过程，客户端向服务端注册watcher、服务端事件触发watcher、客户端回调watcher得到触发事件内容

触发机制特点

• 一次性触发
• 事件封装
• 传递watchedevent,包括通知状态，事件类型，节点路径。
• event异步发送
• 先注册再触发

shell操作watcher

help 查看所有命令，后面带有watcher的都可以实现监听

    stat path [watch]
    ls path [watch]
    ls2 path [watch]
    get path [watch]

Zookeeper java api

• 引入依赖

<dependency>
      <groupId>org.apache.zookeeper</groupId>
      <artifactId>zookeeper</artifactId>
      <version>3.4.14</version>
    </dependency>

• 示例代码

public static void main(String[] args) throws Exception{
        ZooKeeper zooKeeper = new ZooKeeper("192.168.195.100:2181,192.168.195.100:2182", 30000, new Watcher() {
            @Override
            public void process(WatchedEvent watchedEvent) {
                System.out.println("回调通知");
                System.out.println(watchedEvent.getPath());
                System.out.println(watchedEvent.getState());
                System.out.println(watchedEvent.getType());
            }
        });
//        zooKeeper.create("/magicbook","充满魔力的book".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT_SEQUENTIAL);
        zooKeeper.getData("/magicbook0000000007",true,null);
        zooKeeper.setData("/magicbook0000000007","少时诵诗书".getBytes(),-1);
        zooKeeper.delete("/magicbook0000000007",-1);
        //        zooKeeper.close();
    }

Zookeeper选举机制

zookeeper 默认的选举算法是fastleaderelection,采用投票数大于半数胜出 概念

• 服务器ID
• id越大，在选举算法中权重越大
• 选举状态
  1. 竞选状态 LOCKING
  2. 随从状态 FOLOWING 同步leader状态 参与投票
  3. 观察状态 OBSERVER 同步Leader状态 不参与投票
  4. Leader 领导者状态
• 数据ID 服务器中存放的最新数据的版本，值越大说明数据越新

全新集群选举

• 每个机器都给自己投票 LOCKING
• 服务器大的ID可以把小的ID票数夺过来
• 投票数过半结束
• 这时候如果更大的服务器ID来竞选，不好意思。投票已经结束了

非全新集群

对于运行正常的zookeeper集群，中途有机器宕机，需要重新选举，选举过程就需要加入数据ID,服务器ID,逻辑时钟。

• 数据ID :数据新的version就大，数据每次都会更新version
• 服务器ID:就是我们配置的myid
• 这个值从0开始，每次选举对应一个值，如果在同一个选举中，这个是一致的。
• 选举的过程 1.逻辑时钟小的被忽略，重新投票。 2.统一逻辑时钟后，数据ID大的胜出。 3.数据ID相同的情况下，服务器ID大的胜出。 4.最后选出leader

典型应用 数据发布与订阅 通过重复监听节点改变事件，利用watcher监听，实现数据发布订阅 分布式锁 1、每个客户端创建临时有序节点 2、客户端获取节点列表，判断自己是否列表中的第一个节点，如果是就获得锁，如果不是就监听自己前面的节点，等待前面节点被删除。 3、如果获取锁就进行正常的业务流程，执行完释放锁。上述步骤2中，有人可能担心如果节点发现自己不是序列最小的节点，准备添加监听器，但是这个时候前面节点正好被删除，这时候添加监听器是永远不起作用的，其实zk的API可以保证读取和添加监听器是一个原子操作。为什么要监听前一个节点而不是所有的节点呢？这是因为如果监听所有的子节点，那么任意一个子节点状态改变，其它所有子节点都会收到通知（羊群效应），而我们只希望它的后一个子节点收到通知。