分布式锁的实现，参考很多博客写的总结一下如有侵权，直接转私密啦

最新推荐文章于 2022-10-02 15:10:07 发布

Love晋

最新推荐文章于 2022-10-02 15:10:07 发布

阅读量449

点赞数

分类专栏：分布式锁文章标签：分布式锁

本文链接：https://blog.csdn.net/qq_26388159/article/details/80104907

版权

分布式锁专栏收录该内容

0 篇文章 0 订阅

订阅专栏

目的：

解决分布式场景中数据一致性问题

几个概念：

CAP理论，任何一个分布式系统都无法同时满足一下三点，只能满足三者之中两者。

a、一致性 Consistency

b、容错性 Partition tolerance

c、可用性 Availability

可重入锁，不可重入锁(自旋锁)

分区

区别：不可重入锁只是当前线程获取锁之后，如果锁中嵌套锁的话，方法会阻塞，死锁，可重入锁在如果获取锁之后，锁中锁也不会阻塞

evg:

      1 public class Lock{
      2     private boolean isLocked = false;
      3     public synchronized void lock() throws InterruptedException{
      4         while(isLocked){    
      5             wait();
      6         }
      7         isLocked = true;
      8     }
      9     public synchronized void unlock(){
     10         isLocked = false;
     11         notify();
     12     }
     13 }

不可重入锁当调用print()方法时，获得了锁，这时就无法再调用doAdd()方法，这时必须先释放锁才能调用，所以称这种锁为不可重入锁，也叫自旋锁。

      1 public class Count{
      2     Lock lock = new Lock();
      3     public void print(){
      4         lock.lock();
      5         doAdd();
      6         lock.unlock();
      7     }
      8     public void doAdd(){
      9         lock.lock();
     10         //do something
     11         lock.unlock();
     12     }
     13 }

可重入锁线程可以进入任何一个它已经拥有的锁所同步着的代码块。

      1 public class Lock{
      2     boolean isLocked = false;
      3     Thread  lockedBy = null;
      4     int lockedCount = 0;
      5     public synchronized void lock()
      6             throws InterruptedException{
      7         Thread thread = Thread.currentThread();
      8         while(isLocked && lockedBy != thread){
      9             wait();
     10         }
     11         isLocked = true;
     12         lockedCount++;
     13         lockedBy = thread;
     14     }
     15     public synchronized void unlock(){
     16         if(Thread.currentThread() == this.lockedBy){
     17             lockedCount--;
     18             if(lockedCount == 0){
     19                 isLocked = false;
     20                 notify();
     21             }
     22         }
     23     }
     24 }

解决方案：

a、基于数据库实现的分布式锁

b、基于缓存(redis,memcached,tair)实现分布式锁

c、基于zookeeper实现分布式锁

分布式锁需要具备的几个条件：

a、可以保证在分布式部署应用集群中，同一个方法在同一个时间只能被一台机器上的线程执行

b、这把锁要是一个可重入锁（避免死锁）

c、这把锁最好是一个阻塞锁（根据业务需求考虑要不要这条）

d、有高可用的获取锁和释放锁功能

e、获取锁和释放锁的性能要好

--靠谱四个条件：

1、互斥性。在任何时刻，只有一个客户端持有锁。

2、不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。

3、具有容错性。只要大部分的Redis节点正常运行，客户端就可以加锁和解锁。

4、解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了

a、基于数据库实现的分布式锁

原理：通过数据库表做唯一性约束，来实现的，如果有多个请求同事提交到数据库的话，数据库只能由一个操作可以成功。

缺点：

1、这把锁强依赖数据库的可用性，数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。

2、这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。

3、这把锁只能是非阻塞的，因为数据的insert操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作。

4、这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。

数据库是单点？搞两个数据库，数据之前双向同步。一旦挂掉快速切换到备库上。
没有失效时间？只要做一个定时任务，每隔一定时间把数据库中的超时数据清理一遍。
非阻塞的？搞一个while循环，直到insert成功再返回成功。
非重入的？在数据库表中加个字段，记录当前获得锁的机器的主机信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了。

b、基于redis实现的分布式锁，步骤：

b.1、maven引入

     <dependency>
         <groupId>redis.clients</groupId>
         <artifactId>jedis</artifactId>
         <version>2.9.0</version>
     </dependency>

b.2、枷锁代码

解释：

可以看到，我们加锁就一行代码：jedis.set(String key, String value, String nxxx, String expx, int time)，

这个set()方法一共有五个形参：

第一个为key，我们使用key来当锁，因为key是唯一的。
第二个为value，我们传的是requestId，很多童鞋可能不明白，有key作为锁不就够了吗，为什么还要用到value？原因就是我们在上面讲到可靠性时，分布式锁要满足第四个条件解铃还须系铃人，通过给value赋值为requestId，我们就知道这把锁是哪个请求加的了，在解锁的时候就可以有依据。requestId可以使用UUID.randomUUID().toString()方法生成。
第三个为nxxx，这个参数我们填的是NX，意思是SET IF NOT EXIST，即当key不存在时，我们进行set操作；若key已经存在，则不做任何操作；
第四个为expx，这个参数我们传的是PX，意思是我们要给这个key加一个过期的设置，具体时间由第五个参数决定。
第五个为time，与第四个参数相呼应，代表key的过期时间。

总的来说，执行上面的set()方法就只会导致两种结果：1. 当前没有锁（key不存在），那么就进行加锁操作，并对锁设置个有效期，

同时value表示加锁的客户端。2. 已有锁存在，不做任何操作。

心细的童鞋就会发现了，我们的加锁代码满足我们可靠性里描述的三个条件。首先，set()加入了NX参数，可以保证如果已有key存在，

则函数不会调用成功，也就是只有一个客户端能持有锁，满足互斥性。其次，由于我们对锁设置了过期时间，即使锁的持有者后续发生崩溃而没有解锁，

锁也会因为到了过期时间而自动解锁（即key被删除），不会发生死锁。最后，因为我们将value赋值为requestId，代表加锁的客户端请求标识，

那么在客户端在解锁的时候就可以进行校验是否是同一个客户端。由于我们只考虑Redis单机部署的场景，所以容错性我们暂不考虑。

public class RedisTool {

    private static final String LOCK_SUCCESS = "OK";
    private static final String SET_IF_NOT_EXIST = "NX";
    private static final String SET_WITH_EXPIRE_TIME = "PX";

    /**
     * 尝试获取分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @param expireTime 超期时间
     * @return 是否获取成功
     */
    public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {

        String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);

        if (LOCK_SUCCESS.equals(result)) {
            return true;
        }
        return false;

    }

}

b.3解锁

解释：

可以看到，我们解锁只需要两行代码就搞定了！第一行代码，我们写了一个简单的Lua脚本代码，上一次见到这个编程语言还是在《黑客与画家》里，没想到这次居然用上了。第二行代码，我们将Lua代码传到jedis.eval()方法里，并使参数KEYS[1]赋值为lockKey，ARGV[1]赋值为requestId。eval()方法是将Lua代码交给Redis服务端执行。

那么这段Lua代码的功能是什么呢？其实很简单，首先获取锁对应的value值，检查是否与requestId相等，如果相等则删除锁（解锁）。那么为什么要使用Lua语言来实现呢？因为要确保上述操作是原子性的。关于非原子性会带来什么问题，可以阅读【解锁代码-错误示例2】。

public class RedisTool {

    private static final Long RELEASE_SUCCESS = 1L;

    /**
     * 释放分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @return 是否释放成功
     */
    public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {

        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));

        if (RELEASE_SUCCESS.equals(result)) {
            return true;
        }
        return false;

    }

}

redis 参考文章https://wudashan.cn/2017/10/23/Redis-Distributed-Lock-Implement/#releaseLock-wrongDemo2链接地址。

Love晋

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
分布式锁的实现，参考很多博客写的总结一下如有侵权，直接转私密啦

目的：解决分布式场景中数据一致性问题几个概念： CAP理论，任何一个分布式系统都无法同时满足一下三点，只能满足三者之中两者。 a、一致性 Consistency b、容错性 Partition tolerance c、可用性 Availability 可重入锁，不可重...
复制链接

扫一扫