亲宝软件园·资讯

展开

Spring Boot整合Zookeeper分布式锁

怪 咖@ 人气:1

温馨提示：本篇文章要求掌握zk的数据结构，以及临时序号节点！

zk实现分布式锁完全是依靠zk节点类型当中的临时序号节点来实现的

一、Java当中关于锁的概念

1.1.什么是锁

锁是用来控制多个线程访问共享资源的方式，一般来说，一个锁能够防止多个线程同时访问共享资源。

1.2.锁的使用场景

以减库存为例，库存这时候就剩1个，那么我们得保证只会有1个请求真正的完成减1操作，假如代码逻辑是，先从库里查库存，通过if条件判断，如果有就减，没有就返回购买失败。

这时候并发访问减库存接口，可能这时候我们代码当中的if判断已经失效了，多个请求同时查到还有一个，并且已经进入了if判断，没有加锁的话，这时候事情就比较严重了，库存一下子就成了负数。

对于这块代码我们不希望同时有人减库存，这时候就需要加锁来控制，加完锁之后，就是将并发请求改成了串行，也就是不管并发了多少个请求，我通过加锁，只让1个请求进行减库存，你们去争抢锁资源吧，谁先抢到了就是谁的。

1.3.什么是分布式锁

分布式锁是控制 微服务集群 之间同步访问共享资源的一种方式。

1.4.分布式锁的使用场景

使用分布式锁前提：微服务一定是集群，这里的微服务不是指的zk，而是指的我们的业务模块，在项目当中一般的，由于并发量较高，往往会将业务拆分为一个模块一个模块，例如订单模块，库存模块，拆模块其中一个目的就是为了针对于模块的并发性进行集群部署，比如订单模块用的比较多，我可以搭建多个订单模块，但是尽管他们的模块是多个，围绕的数据还是共通的（一个数据库）。

集群情况下，我们在代码加普通锁已经解决不了问题，假如现在有三个库存微服务，设置了负载均衡的方式访问，普通锁只能控制自己的服务减库存不会出现负数，但是他控制不了其他两个服务，数据是共通的，所以这时候只能使用分布式锁，通过分布式锁来控制三个服务当库存只有一个商品的时候，只能有一个服务访问的请求可以减库存成功。

二、zk实现分布式锁

2.1.zk中锁的种类：

读锁和写锁完全是按照创建的临时序号节点的名称来区分的！

当需要上锁的时候，就进行创建临时序号节点，释放锁的时候就删除节点。

2.2.zk如何上读锁

想要上读锁，主要就是需要看比他小的节点当中是否有写锁。如果有写锁，就需要等他用完之后删除节点，通过watch机制来通知他，写锁已经释放，然后他再进行第二步判断。

在这里插入图片描述

2.3.zk如何上写锁

在这里插入图片描述

2.4.⽺群效应

如果⽤上述的上锁⽅式，只要有节点发⽣变化，就会触发其他节点的监听事件，这样的话对zk的压⼒⾮常⼤，——⽺群效应。可以调整成链式监听。解决这个问题。

在这里插入图片描述

假如并发了100个请求都需要获取写锁，这时候创建了100个节点来监听最小节点，当最小节点发生变化的时候，意味着他一下子要进行通知100个节点，zk瞬间会压力非常大。

所以这时候可以采用链式监听，链式监听仍然是依靠的序号节点的特点。就好比mysql设置自增后，不管多少并发请求，他仍然能保证id的唯一性，zk的序号节点同样也是。让他们都不再监听最小节点，而是监听他的上一个节点。当上一个节点释放锁后，那当前节点就可以创建写锁了。

这里还会遇到一个问题，假如他的上一个节点意外删除了，但是并不是等着拿到锁后释放锁，而是单纯的不想等了，所以删除了节点，而上面还有很多节点加着锁呢，所以我们不能单纯的靠上一个节点删除后当前节点就进行加锁。我们加写锁要保证的是，他上面没有任何节点加锁。这时候让他进行监听上上个节点即可。假如上上个节点仍然有问题了，那就监听上上上个节点。总之一点就是尽量避免不让多个节点同时去监听一个节点。

三、springboot整合分布式锁

springboot整合curator客户端：https:

我直接是基于上一篇文章当中的项目进行 分布式锁 练习的！

根据上面提到的zk分布式锁实现思路，我们其实并不用去自己写，在curator客户端已经给我们提供了现成的方法，我们只需要简单的调用客户端提供的方法，就可以实现分布式锁功能！

@Autowired
CuratorFramework curatorFramework;

/**
 * 获取读锁的条件是前面没有写锁
 * 当/lock1节点不存在的时候，我们不需要手动去创建，获取锁的时候会自动创建
 * 自动创建的是临时节点，用完之后释放锁的时候会删除掉的
 * 获取到锁之后会在/lock1节点下创建一个临时序号节点
 * 然后没有获取到锁的线程也会创建一个节点，这时候处于等待期间
 * 释放锁的时候，首先会删除掉自己的序号节点，然后假如没有人在排队用锁，这时候会把/lock1节点也删除掉
 *
 * @throws Exception
 */
@Test
void testGetReadLock() throws Exception {
    // 读写锁
    InterProcessReadWriteLock interProcessReadWriteLock = new
            InterProcessReadWriteLock(curatorFramework, "/lock1");
    // 获取读锁对象(创建对象耗时也就18毫秒)
    InterProcessLock interProcessLock = interProcessReadWriteLock.readLock();
    System.out.println("等待获取读锁对象!");

    // 获取锁（假如一直没拿到锁这个方法一直会是阻塞的，就算不阻塞的情况下，这个方法耗时也是特别长，高达17秒）
    interProcessLock.acquire();

    // 正常的我们代码假如走到了这一步，说明已经获取到锁了，这里写相关的业务代码即可，执行完记住释放锁
    System.out.println("获取到了锁！");
    for (int i = 1; i <= 100; i++) {
        Thread.sleep(3000);
        System.out.println(i);
    }
    // 释放锁（方法耗时13毫秒）
    interProcessLock.release();
    // 走到这一步的时候节点已经被删除了
    System.out.println("等待释放锁!");
}

/**
 * 获取写锁的条件是前面没有任何的锁
 *
 * @throws Exception
 */
@Test
void testGetWriteLock() throws Exception {
    // 读写锁
    InterProcessReadWriteLock interProcessReadWriteLock = new
            InterProcessReadWriteLock(curatorFramework, "/lock1");
    // 获取写锁对象
    InterProcessLock
            interProcessLock = interProcessReadWriteLock.writeLock();
    System.out.println("等待获取写锁对象!");
    // 获取锁（假如一直没拿到锁这个方法一直会是阻塞的）
    interProcessLock.acquire();
    for (int i = 1; i <= 100; i++) {
        Thread.sleep(3000);
        System.out.println(i);
    }
    // 释放锁
    interProcessLock.release();
    System.out.println("等待释放锁!");
}

/**
 * 方便测试多个线程获取读锁
 *
 * @throws Exception
 */
@Test
void testGetReadLock1() throws Exception {
    testGetReadLock();
}

这个是两个获取读锁的时候的节点场景：

在这里插入图片描述

这个是一个获取读锁，一个获取写锁的场景，然后读锁节点是0004，所以是后创建的，他只有等待0003释放写锁，才能获取到读锁。

在这里插入图片描述

zk分布式锁会产生死锁吗？

这个肯定是不会的，因为假如有客户端拿到了锁，还没释放，服务挂了，这时候依据临时节点的特性，当临时节点和客户端断开连接几秒后会自动删除的，删除节点也就意味着自动释放锁！

正常情况不建议使用zk作为分布式锁，效率属实太慢。

加载全部内容
相关教程
猜你喜欢
用户评论