亲宝软件园·资讯

展开

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作为分布式锁,效率属实太慢。

加载全部内容

相关教程
猜你喜欢
用户评论