一、使用ZooKeeper实现Java跨JVM的分布式锁

二、使用ZooKeeper实现Java跨JVM的分布式锁(优化构思)

三、使用ZooKeeper实现Java跨JVM的分布式锁(读写锁)

说明:本文是使用Curator框架进行讲解及演示,Curator是对Zookeeper客户端的一个封装,因为Zookeeper的客户端实现偏底层,如果想要实现锁或其他功能都需要自己封装,实现一些简单的功能还可以,如果想要实现锁这种高并发下的东西,不建议自己封装,除非你自信你写的东西比国外大神写的还好~ 如果是研究学习到是可以自己写一下,同时也可以看看开源的代码,那里面还是有很多值得学习的东西。

Zookeeper版本为 Release 3.4.8(stable)

Curator版本为2.9.1

  1. <dependency>
  2. <groupId>org.apache.zookeeper</groupId>
  3. <artifactId>zookeeper</artifactId>
  4. <version>3.4.8</version>
  5. </dependency>
  6. <dependency>
  7. <groupId>org.apache.curator</groupId>
  8. <artifactId>curator-recipes</artifactId>
  9. <version>2.9.1</version>
  10. </dependency>
  11. <dependency>
  12. <groupId>org.apache.curator</groupId>
  13. <artifactId>curator-client</artifactId>
  14. <version>2.9.1</version>
  15. </dependency>

锁原理:

1、首先要创建一个锁的根节点,比如/mylock。

2、想要获取锁的客户端在锁的根节点下面创建znode,作为/mylock的子节点,节点的类型要选择CreateMode.PERSISTENT_SEQUENTIAL,节点的名字最好用uuid(至于为什么用uuid我后面会讲,先说一下~如果不这么做在某种情况下会发生死锁,这一点我看了很多国内朋友自己的实现,都没有考虑到这一层,这也是我为什么不建议大家自己去封装这种锁,因为它确实很复杂),假设目前同时有3个客户端想要获得锁,那么/mylock下的目录应该是这个样子的。

xxx-lock-0000000001,xxx-lock-0000000002,xxx-lock-0000000003

xxx为uuid , 0000000001,0000000002,0000000003 是zook服务端自动生成的自增数字。

3、当前客户端通过getChildren(/mylock)获取所有子节点列表并根据自增数字排序,然后判断一下自己创建的节点的顺序是不是在列表当中最小的,如果是 那么获取到锁,如果不是,那么获取自己的前一个节点,并设置监听这个节点的变化,当节点变化时重新执行步骤3 直到自己是编号最小的一个为止。

举例:假设当前客户端创建的节点是0000000002,因为它的编号不是最小的,所以获取不到锁,那么它就找到它前面的一个节点0000000001 并对它设置监听。

4、释放锁,当前获得锁的客户端在操作完成后删除自己创建的节点,这样会激发zook的事件给其它客户端知道,这样其它客户端会重新执行(步骤3)。

举例:加入客户端0000000001获取到锁,然后客户端0000000002加入进来获取锁,发现自己不是编号最小的,那么它会监听它前面节点的事件(0000000001的事件)然后执行步骤(3),当客户端0000000001操作完成后删除自己的节点,这时zook服务端会发送事件,这时客户端0000000002会接收到该事件,然后重复步骤3直到获取到锁)

上面的步骤实现了一个有序锁,也就是先进入等待锁的客户端在锁可用时先获得锁。

如果想要实现一个随机锁,那么只需要把PERSISTENT_SEQUENTIAL换成一个随机数即可。

简单示例:

  1. package com.framework.code.demo.zook;
  2. import org.apache.curator.RetryPolicy;
  3. import org.apache.curator.framework.CuratorFramework;
  4. import org.apache.curator.framework.CuratorFrameworkFactory;
  5. import org.apache.curator.framework.recipes.locks.InterProcessMutex;
  6. import org.apache.curator.retry.ExponentialBackoffRetry;
  7. public class CuratorDemo {
  8. public static void main(String[] args) throws Exception {
  9. //操作失败重试机制 1000毫秒间隔 重试3次
  10. RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
  11. //创建Curator客户端
  12. CuratorFramework client = CuratorFrameworkFactory.newClient("192.168.1.18:2181", retryPolicy);
  13. //开始
  14. client.start();
  15. /**
  16. * 这个类是线程安全的,一个JVM创建一个就好
  17. * mylock 为锁的根目录,我们可以针对不同的业务创建不同的根目录
  18. */
  19. final InterProcessMutex lock = new InterProcessMutex(client, "/mylock");
  20. try {
  21. //阻塞方法,获取不到锁线程会挂起。
  22. lock.acquire();
  23. System.out.println("已经获取到锁");
  24. Thread.sleep(10000);
  25. } catch (Exception e) {
  26. e.printStackTrace();
  27. }
  28. finally{
  29. //释放锁,必须要放到finally里面,已确保上面方法出现异常时也能够释放锁。
  30. lock.release();
  31. }
  32. Thread.sleep(10000);
  33. client.close();
  34. }
  35. }

上面代码再获取锁的地方暂停了10秒钟,我们使用zook的客户端去查看目录的创建情况,由于我前面已经做了几次测试,所以序号是从12开始的。

模拟多个客户端(也可以认为是多个JVM):

现在把上面的代码改造一下放入到线程中去执行,模拟多个客户端测试

  1. public class CuratorDemo {
  2. public static void main(String[] args) throws Exception {
  3. for (int i = 0; i < 10; i++) {
  4. //启动10个线程模拟多个客户端
  5. Jvmlock jl = new Jvmlock(i);
  6. new Thread(jl).start();
  7. //这里加上300毫秒是为了让线程按顺序启动,不然有可能4号线程比3号线程先启动了,这样测试就不准了。
  8. Thread.sleep(300);
  9. }
  10. }
  11. public static class Jvmlock implements Runnable{
  12. private int num;
  13. public Jvmlock(int num) {
  14. this.num = num;
  15. }
  16. @Override
  17. public void run() {
  18. RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000,3);
  19. CuratorFramework client = CuratorFrameworkFactory
  20. .newClient("192.168.142.128:2181", retryPolicy);
  21. client.start();
  22. InterProcessMutex lock = new InterProcessMutex(client,
  23. "/mylock");
  24. try {
  25. System.out.println("我是第" + num + "号线程,我开始获取锁");
  26. lock.acquire();
  27. System.out.println("我是第" + num + "号线程,我已经获取锁");
  28. Thread.sleep(10000);
  29. } catch (Exception e) {
  30. e.printStackTrace();
  31. } finally {
  32. try {
  33. lock.release();
  34. } catch (Exception e) {
  35. e.printStackTrace();
  36. }
  37. }
  38. client.close();
  39. }
  40. }
  41. }

通过客户端软件我们可以看到10个申请锁的节点已经被创建出来了。

看一下打印结果,先申请获取锁的线程在锁可用时最先获取到锁,因为他们申请锁时创建节点的顺序号是递增的,先申请锁的客户端创建的节点编号最小,所以先获取到锁

  1. 我是第0号线程,我开始获取锁
  2. 我是第0号线程,我已经获取锁
  3. 我是第1号线程,我开始获取锁
  4. 我是第2号线程,我开始获取锁
  5. 我是第3号线程,我开始获取锁
  6. 我是第4号线程,我开始获取锁
  7. 我是第5号线程,我开始获取锁
  8. 我是第6号线程,我开始获取锁
  9. 我是第7号线程,我开始获取锁
  10. 我是第8号线程,我开始获取锁
  11. 我是第9号线程,我开始获取锁
  12. 我是第1号线程,我已经获取锁
  13. 我是第2号线程,我已经获取锁
  14. 我是第3号线程,我已经获取锁
  15. 我是第4号线程,我已经获取锁
  16. 我是第5号线程,我已经获取锁
  17. 我是第6号线程,我已经获取锁
  18. 我是第7号线程,我已经获取锁
  19. 我是第8号线程,我已经获取锁
  20. 我是第9号线程,我已经获取锁

为什么节点的名称要加上uuid,这是框架的英文解释。

It turns out there is an edge case that exists when creating sequential-ephemeral nodes. The creation can succeed on the server, but the server can crash before the created node name is returned to the client. However, the ZK session is still valid so the ephemeral node is not deleted. Thus, there is no way for the client to determine what node was created for them.

Even without sequential-ephemeral, however, the create can succeed on the sever but the client (for various reasons) will not know it.

Putting the create builder into protection mode works around this. The name of the node that is created is prefixed with a GUID. If node creation fails the normal retry mechanism will occur. On the retry, the parent path is first searched for a node that has the GUID in it. If that node is found, it is assumed to be the lost node that was successfully created on the first try and is returned to the caller.

就是说 当客户端创建了一个节点,这个创建的过程在zook的服务器端已经成功了,但是在将节点的路径返回给客户端之前服务器端挂了, 因为客户端的session还是有效的,所以这个节点不会删除, 这样客户端就不知道哪个节点是它创建的。

当客户端发生创建失败的时候,会进行重试,如果这个时候zook已经恢复可用,那么客户端会查询服务器端所有子节点,然后通过和自己创建的uuid对比,如果找到了,说明这个节点是它之前创建的,那么久直接使用它,不然这个节点就会成为一个死节点,导致死锁。

实现非公平锁:

重写创建节点的方法,

  1. package com.framework.code.demo.zook.lock;
  2. import org.apache.curator.framework.CuratorFramework;
  3. import org.apache.curator.framework.recipes.locks.StandardLockInternalsDriver;
  4. import org.apache.zookeeper.CreateMode;
  5. public class NoFairLockDriver extends StandardLockInternalsDriver {
  6. /**
  7. * 随机数的长度
  8. */
  9. private int numLength;
  10. private static int DEFAULT_LENGTH = 5;
  11. public NoFairLockDriver() {
  12. this(DEFAULT_LENGTH);
  13. }
  14. public NoFairLockDriver(int numLength) {
  15. this.numLength = numLength;
  16. }
  17. @Override
  18. public String createsTheLock(CuratorFramework client, String path, byte[] lockNodeBytes) throws Exception
  19. {
  20. String newPath = path + getRandomSuffix();
  21. String ourPath;
  22. if ( lockNodeBytes != null )
  23. {
  24. //原来使用的是CreateMode.EPHEMERAL_SEQUENTIAL类型的节点
  25. //节点名称最终是这样的_c_c8e86826-d3dd-46cc-8432-d91aed763c2e-lock-0000000025
  26. //其中0000000025是zook服务器端资自动生成的自增序列 从0000000000开始
  27. //所以每个客户端创建节点的顺序都是按照0,1,2,3这样递增的顺序排列的,所以他们获取锁的顺序与他们进入的顺序是一致的,这也就是所谓的公平锁
  28. //现在我们将有序的编号换成随机的数字,这样在获取锁的时候变成非公平锁了
  29. ourPath = client.create().creatingParentContainersIfNeeded().withProtection().withMode(CreateMode.EPHEMERAL).forPath(newPath, lockNodeBytes);
  30. //ourPath = client.create().creatingParentContainersIfNeeded().withProtection().withMode(CreateMode.EPHEMERAL_SEQUENTIAL).forPath(path, lockNodeBytes);
  31. }
  32. else
  33. {
  34. ourPath = client.create().creatingParentContainersIfNeeded().withProtection().withMode(CreateMode.EPHEMERAL).forPath(newPath);
  35. //ourPath = client.create().creatingParentContainersIfNeeded().withProtection().withMode(CreateMode.EPHEMERAL_SEQUENTIAL).forPath(path);
  36. }
  37. return ourPath;
  38. }
  39. /**
  40. * 获得随机数字符串
  41. */
  42. public String getRandomSuffix() {
  43. StringBuilder sb = new StringBuilder();
  44. for (int i = 0; i < numLength; i++) {
  45. sb.append((int) (Math.random() * 10));
  46. }
  47. return sb.toString();
  48. }
  49. }

把我们写的类注册进去:

  1. InterProcessMutex lock = new InterProcessMutex(client,"/mylock", new NoFairLockDriver());

还是上面的例子,在跑一边看结果,可以看到,获取锁的顺序已经是无序的了,从而实现了非公平锁。

    1. 我是第1号线程,我开始获取锁
    2. 我是第0号线程,我开始获取锁
    3. 我是第0号线程,我已经获取锁
    4. 我是第2号线程,我开始获取锁
    5. 我是第3号线程,我开始获取锁
    6. 我是第4号线程,我开始获取锁
    7. 我是第5号线程,我开始获取锁
    8. 我是第6号线程,我开始获取锁
    9. 我是第7号线程,我开始获取锁
    10. 我是第8号线程,我开始获取锁
    11. 我是第9号线程,我开始获取锁
    12. 我是第9号线程,我已经获取锁
    13. 我是第8号线程,我已经获取锁
    14. 我是第4号线程,我已经获取锁
    15. 我是第7号线程,我已经获取锁
    16. 我是第3号线程,我已经获取锁
    17. 我是第1号线程,我已经获取锁
    18. 我是第2号线程,我已经获取锁
    19. 我是第5号线程,我已经获取锁
    20. 我是第6号线程,我已经获取锁

使用ZooKeeper实现Java跨JVM的分布式锁的更多相关文章

  1. 使用ZooKeeper实现Java跨JVM的分布式锁(读写锁)

    一.使用ZooKeeper实现Java跨JVM的分布式锁 二.使用ZooKeeper实现Java跨JVM的分布式锁(优化构思) 三.使用ZooKeeper实现Java跨JVM的分布式锁(读写锁) 读写 ...

  2. 使用ZooKeeper实现Java跨JVM的分布式锁(优化构思)

    一.使用ZooKeeper实现Java跨JVM的分布式锁 二.使用ZooKeeper实现Java跨JVM的分布式锁(优化构思) 三.使用ZooKeeper实现Java跨JVM的分布式锁(读写锁) 说明 ...

  3. Java使用Redis实现分布式锁来防止重复提交问题

    如何用消息系统避免分布式事务? - 少年阿宾 - BlogJavahttp://www.blogjava.net/stevenjohn/archive/2018/01/04/433004.html [ ...

  4. zookeeper笔记之基于zk实现分布式锁

    一.分布式锁概述 Java中基于AQS框架提供了一系列的锁,但是当需要在集群中的多台机器上互斥执行一段代码或使用资源时Java提供的这种单机锁就没了用武之地,此时需要使用分布式锁协调它们.分布式锁有很 ...

  5. ZooKeeper(八)-- Curator实现分布式锁

    1.pom.xml <dependencies> <dependency> <groupId>junit</groupId> <artifactI ...

  6. Java基于redis实现分布式锁(SpringBoot)

    前言 分布式锁,其实原理是就是多台机器,去争抢一个资源,谁争抢成功,那么谁就持有了这把锁,然后去执行后续的业务逻辑,执行完毕后,把锁释放掉. 可以通过多种途径实现分布式锁,例如利用数据库(mysql等 ...

  7. java中redis的分布式锁工具类

    使用方式 try { if(PublicLock.getLock(lockKey)){ //这里写代码逻辑,执行完后需要释放锁 PublicLock.freeLock(lockKey); } } ca ...

  8. java基础之----redi分布式锁

    最近项目中,用到了redis分布式锁,使用过程有些心得,所以希望分享给大家. 首先我们意识里要知道分布锁有哪些? 分布式锁一般分三种,基于数据库的乐观锁,基于redis的分布式锁,基于zookeper ...

  9. java基于mongodb实现分布式锁

    原理 通过线程安全findAndModify 实现锁 实现 定义锁存储对象: /** * mongodb 分布式锁 */ @Data @NoArgsConstructor @AllArgsConstr ...

随机推荐

  1. 信息安全意识教育日历——By 安全牛

    安全牛:企业即使投入再好的信息安全技术和产品,也难以解决内部威胁以及社会工程等攻击手段,无法做到全面有效地保护企业信息资产.而通过开展员工的信息安全意识培训教育工作,不仅能降低企业风险.满足合规要求, ...

  2. 通信—HTTP与HTTPS

    HTTP是客户端浏览器或其他程序与Web服务器之间的应用层通信协议.在Internet上的Web服务器上存放的都是超文本信息,客户机需要通过HTTP协议传输所要访问的超文本信息. HTTPS(全称:H ...

  3. HadoopHA简述

    1 概述 在hadoop2.0之前,namenode只有一个,存在单点问题(虽然hadoop1.0有 secondarynamenode,checkpointnode,buckcupnode这些,但是 ...

  4. Ubuntu学习笔记3-图书知识点总结

    免费的虚拟机软件:vmware server Ubuntu下切换到root用户: 1,su 2, sudo -s 3, sudo+命令 Ubuntu下切换到一般用户: su chennan 软件包的安 ...

  5. PySpider HTTP 599: SSL certificate problem错误的解决方法(转)

    前言 最近发现许多小伙伴在用 PySpider 爬取 https 开头的网站的时候遇到了 HTTP 599: SSL certificate problem: self signed certific ...

  6. LeetCode:累加数【306】

    LeetCode:累加数[306] 题目描述 累加数是一个字符串,组成它的数字可以形成累加序列. 一个有效的累加序列必须至少包含 3 个数.除了最开始的两个数以外,字符串中的其他数都等于它之前两个数相 ...

  7. 扯一扯 C#委托和事件?策略模式?接口回调?

    早前学习委托的时候,写过一点东西,今天带着新的思考和认知,再记点东西.这篇文章扯到设计模式中的策略模式,观察者模式,还有.NET的特性之一--委托.真的,请相信我,我只是在扯淡...... 场景练习 ...

  8. windows10+mysql8.0.zip安装

    〇.准备: MySQL8.0 Windows zip包下载地址:https://cdn.mysql.com//Downloads/MySQL-8.0/mysql-8.0.11-winx64.zip 环 ...

  9. canvas笔记1

    w3c定义: <canvas> 标签定义图形,比如图表和其他图像. <canvas> 标签只是图形容器,您必须使用脚本来绘制图形. canvas 对象 属性: width he ...

  10. hadoop28---netty传对象

    Netty中,通讯的双方建立连接后,会把数据按照ByteBuf的方式进行传输,例如http协议中,就是通过HttpRequestDecoder对ByteBuf数据流进行处理,转换成http的对象.基于 ...