setnx分布式锁原理RedisTemplate实现setnx分布式锁

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: setnx分布式锁原理RedisTemplate实现setnx分布式锁

首先分布式锁和我们平常讲到的锁原理基本一样,目的就是确保,在多个线程并发时,只有一个线程在同一刻操作这个业务或者说方法、变量。

在一个进程中,也就是一个jvm 或者说应用中,我们很容易去处理控制,在jdk java.util 并发包中已经为我们提供了这些方法去加锁, 比如synchronized 关键字 或者Lock 锁,都可以处理。

但是我们现在的应用程序如果只部署一台服务器,那并发量是很差的,如果同时有上万的请求那么很有可能造成服务器压力过大,而瘫痪。

想想双十一 和 三十晚上十点分支付宝红包等业务场景,自然需要用到多台服务器去同时处理这些业务,那么这些服务可能会有上百台同时处理,

但是请我们大家想一想,如果有100台服务器 要处理分红包的业务,现在假设有1亿的红包,1千万个人分,金额随机,那么这个业务场景下是不是必须确保这1千万个人最后分的红包金额总和等于1亿。

如果处理不好~~每人分到100万,那马云爸爸估计大年初一,就得宣布破产了~~

1,常规锁会造成什么情况?

首先说一下我们为什么要搞集群,简单理解就是,需求量(请求并发量)变大了,一个工人处理能力有限,那就多招一些工人来一起处理。

假设1千万个请求平均分配到100台服务器上,每个服务器 接收10w的请求(这10w个请求并不是在同一秒中来的,可能是在1,2个小时内,可以联想下我们三十晚上开红包,等到10.20开始,有的人立马开了,有的人是不是等到12点了才想起来~)

那这样的话,平均到每一秒上的请求也就不到1千个,这种压力一般的服务器还是可以承受的。

第一个请求到来后,是不是需要在1亿里面给他分一部分钱,金额随机,假设第一个人分到了100,那是不是要在这1亿中减去100块,剩下99999900 块~

第二个用户再来分,金额随机,这次分200块,那是不是就需要在剩下的99999900块中再减去200块,剩下99999700 块。

等到第10w个用户来,一看还有1000w,那这1000w全成他的了。

等于是在每个服务器中去分1亿,也就是10w个用户分了一个亿,最后总计有100个服务器,要分100亿。

如果真这样了,虽说马云爸爸不会破产(据最新统计马云有2300亿人民币),那分红包的开发项目组,以及产品经理,可以GG了~

简化结构图如下:

2,分布式锁怎么去处理?

那么为了解决这个问题,让1000万用户只分1亿,而不是100亿,这个时候分布式锁就派上用处了。

分布式锁可以把整个集群就当作是一个应用一样去处理,那么也就需要这个锁,要独立于每一个服务之外,而不是在服务里面。

假设第一个服务器接收到用户1的请求后,那么这个时候,他就不能只在自己的应用中去判断还有多少钱可以分了,而需要去外部请求专门负责管理这1亿红包的人(服务),问他:哎,我这里要分100块,给我100。

管理红包的妹子(服务)一看,还有1个亿,那好,给你100块,然后剩下99999900块。

第二个请求到来后,被服务器2获取,继续去询问,管理红包的妹子,我这边要分10块,管理红包的妹子先查了下还有99999900,那就说:好,给你10块。那就剩下99999890块

等到第1000w个请求到来后,服务器100拿到请求,继续去询问,管理红包的妹子,你要100,妹子翻了翻白眼,对你说,就剩1块了,爱要不要,那这个时候就只能给你1块了(1块也是钱啊,买根辣条还是可以的)。

这些请求编号1,2不代表执行的先后顺序,正式的场景下,应该是 100台服务器每个服务器持有一个请求去访问负责管理红包的妹子(服务),那在管红包的妹子那里同时会接收到100个请求,这个时候就需要在负责红包的妹子那里加个锁就可以了(抛绣球),你们100个服务器谁拿到锁(抢到绣球),谁就进来和我谈,我给你分,其他人就等着去吧

经过上面的分布式锁的处理后,马云爸爸终于放心了,决定给红包团队每人加一个鸡腿。

简化的结构图如下:

3,分布式锁的实现有哪些?

说到分布式锁的实现,还是有很多的,有数据库方式的,有redis分布式锁,有zookeeper分布式锁等等

我们如果采用redis作为分布式锁,那么上图中负“责红包的妹子(服务)”,就可以替换成redis,请自行脑补。

3.1,为什么redis可以实现分布式锁?

首先redis是单线程的,这里的单线程指的是网络请求模块使用了一个线程(所以不需考虑并发安全性),即一个线程处理所有网络请求,其他模块仍用了多个线程。

在实际的操作中过程大致是这样子的:

服务器1要去访问发红包的妹子,也就是redis,那么他会在redis中通过"setnx key value" 操作设置一个key 进去,value是啥不重要,重要的是要有一个key,也就是一个标记,而且这个key你爱叫啥叫啥,只要所有的服务器设置的key相同就可以。

假设我们设置一个,如下图

那么我们可以看到会返回一个1,那就代表了成功。

如果再来一个请求去设置同样的key,如下图:

这个时候会返回0,那就代表失败了。

那么我们就可以通过这个操作去判断是不是当前可以拿到锁,或者说可以去访问“负责发红包的妹子”,如果返回1,那我就开始去执行后面的逻辑,如果返回0,那就说明已经被人占用了,我就要继续等待。

当服务器1拿到锁之后,进行了业务处理,完成后,还需要释放锁,如下图所示:

删除成功返回1,那么其他的服务器就可以继续重复上面的步骤去设置这个key,以达到获取锁的目的。

当然以上的操作是在redis客户端直接进行的,通过程序调用的话,肯定就不能这么写,比如java 就需要通过jedis 去调用,但是整个处理逻辑基本都是一样的

通过上面的方式,我们好像是解决了分布式锁的问题,但是想想还有没有什么问题呢??

对,问题还是有的,可能会有死锁的问题发生,比如服务器1设置完之后,获取了锁之后,忽然发生了宕机。

那后续的删除key操作就没法执行,这个key会一直在redis中存在,其他服务器每次去检查,都会返回0,他们都会认为有人在使用锁,我需要等。

为了解决这个死锁的问题,我们就就需要给key 设置有效期了。

设置的方式有2种

1,第一种就是在set完key之后,直接设置key的有效期 "expire key timeout" ,为key设置一个超时时间,单位为second,超过这个时间锁会自动释放,避免死锁。

这种方式相当于,把锁持有的有效期,交给了redis去控制。如果时间到了,你还没有给我删除key,那redis就直接给你删了,其他服务器就可以继续去setnx获取锁。

2,第二种方式,就是把删除key权利交给其他的服务器,那这个时候就需要用到value值了,

比如服务器1,设置了value 也就是 timeout 为 当前时间+1 秒 ,这个时候服务器2 通过get 发现时间已经超过系统当前时间了,那就说明服务器1没有释放锁,服务器1可能出问题了,

服务器2就开始执行删除key操作,并且继续执行setnx 操作。

但是这块有一个问题,也就是,不光你服务器2可能会发现服务器1超时了,服务器3也可能会发现,如果刚好,服务器2,setnx操作完成,服务器3就接着删除,是不是服务器3也可以setnx成功了?

那就等于是服务器2和服务器3都拿到锁了,那就问题大了。这个时候怎么办呢?

这个时候需要用到 “GETSET key value” 命令了。这个命令的意思就是获取当前key的值,并且设置新的值。

假设服务器2发现key过期了,开始调用 getset 命令,然后用获取的时间判断是否过期,如果获取的时间仍然是过期的,那就说明拿到锁了。

如果没有,则说明在服务2执行getset之前,服务器3可能也发现锁过期了,并且在服务器2之前执行了getset操作,重新设置了过期时间。

那么服务器2就需要放弃后续的操作,继续等待服务器3释放锁或者去监测key的有效期是否过期。

这块其实有一个小问题是,服务器3已经修改了有效期,拿到锁之后,服务器2,也修改了有效期,但是没能拿到锁,但是这个有效期的时间已经被在服务器3的基础上有增加一些,但是这种影响其实还是很小的,几乎可以忽略不计。

3.2,为什么zookeeper可以实现分布式锁?

百度百科是这么介绍的:ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。

那对于我们初次认识的人,可以理解成ZooKeeper就像是我们的电脑文件系统,我们可以在d盘中创建文件夹a,并且可以继续在文件夹a中创建 文件夹a1,a2。

那我们的文件系统有什么特点??那就是同一个目录下文件名称不能重复,同样ZooKeeper也是这样的。

在ZooKeeper所有的节点,也就是文件夹称作 Znode,而且这个Znode节点是可以存储数据的。

我们可以通过“ create /zkjjj nice” 来创建一个节点,这个命令就表示,在跟目录下创建一个zkjjj的节点,值是nice。同样这里的值,和我在前面说的redis中的一样,没什么意义,你随便给。

另外ZooKeeper可以创建4种类型的节点,分别是:

1,持久性节点

2,持久性顺序节点

3,临时性节点

4,临时性顺序节点

首先说下持久性节点和临时性节点的区别,持久性节点表示只要你创建了这个节点,那不管你ZooKeeper的客户端是否断开连接,ZooKeeper的服务端都会记录这个节点。

临时性节点刚好相反,一旦你ZooKeeper客户端断开了连接,那ZooKeeper服务端就不再保存这个节点。

再说下顺序性节点,顺序性节点是指,在创建节点的时候,ZooKeeper会自动给节点编号比如0000001 ,0000002 这种的。

最后说下,zookeeper有一个监听机制,客户端注册监听它关心的目录节点,当目录节点发生变化(数据改变、被删除、子目录节点增加删除)等,zookeeper会通知客户端。

下面我们继续结合我们上面的分红包场景,描述下在zookeeper中如何加锁。

假设服务器1,创建了一个节点 /zkjjj ,成功了,那服务器1就获取了锁,服务器2再去创建相同的锁,那么他就会失败,这个时候他就就只能监听这个节点的变化。

等到服务器1,处理完业务,删除了节点后,他就会得到通知,然后去创建同样的节点,获取锁处理业务,再删除节点,后续的100台服务器与之类似

注意这里的100台服务器并不是挨个去执行上面的创建节点的操作,而是并发的,当服务器1创建成功,那么剩下的99个就都会注册监听这个节点,等通知,以此类推。

但是大家有没有注意到,这里还是有问题的,还是会有死锁的情况存在,对不对?

当服务器1创建了节点后挂了,没能删除,那其他99台服务器就会一直等通知,那就完蛋了。。。

这个时候呢,就需要用到临时性节点了,我们前面说过了,临时性节点的特点是客户端一旦断开,就会丢失,也就是当服务器1创建了节点后,如果挂了。

那这个节点会自动被删除,这样后续的其他服务器,就可以继续去创建节点,获取锁了。

但是我们可能还需要注意到一点,就是惊群效应:举一个很简单的例子,当你往一群鸽子中间扔一块食物,虽然最终只有一个鸽子抢到食物,但所有鸽子都会被惊动来争夺,没有抢到..

就是当服务器1节点有变化,会通知其余的99个服务器,但是最终只有1个服务器会创建成功,这样98还是需要等待监听,那么为了处理这种情况,就需要用到临时顺序性节点

大致意思就是,之前是所有99个服务器都监听一个节点,现在就是每一个服务器监听自己前面的一个节点。

假设100个服务器同时发来请求,这个时候会在 /zkjjj 节点下创建 100 个临时顺序性节点 /zkjjj/000000001, /zkjjj/000000002,一直到 /zkjjj/000000100,这个编号就等于是已经给他们设置了获取锁的先后顺序了。

当001节点处理完毕,删除节点后,002收到通知,去获取锁,开始执行,执行完毕,删除节点,通知003~以此类推。

基于缓存(Redis等)实现分布式锁
 
 
1. 使用命令介绍:
(1)SETNX
SETNX key val:当且仅当key不存在时,set一个key为val的字符串,返回1;若key存在,则什么都不做,返回0。
(2)expire
expire key timeout:为key设置一个超时时间,单位为second,超过这个时间锁会自动释放,避免死锁。
(3)delete
delete key:删除key
 
在使用Redis实现分布式锁的时候,主要就会使用到这三个命令。
 
 
 
2. 实现思想:
(1)获取锁的时候,使用setnx加锁,并使用expire命令为锁添加一个超时时间,超过该时间则自动释放锁,锁的value值为一个随机生成的UUID,通过此在释放锁的时候进行判断。
(2)获取锁的时候还设置一个获取的超时时间,若超过这个时间则放弃获取锁。
(3)释放锁的时候,通过UUID判断是不是该锁,若是该锁,则执行delete进行锁释放。
 
/**
  2  * 分布式锁的简单实现代码  4  */
  5 public class DistributedLock {
  6 
  7     private final JedisPool jedisPool;
  8 
  9     public DistributedLock(JedisPool jedisPool) {
 10         this.jedisPool = jedisPool;
 11     }
 12 
 13     /**
 14      * 加锁
 15      * @param lockName       锁的key
 16      * @param acquireTimeout 获取超时时间
 17      * @param timeout        锁的超时时间
 18      * @return 锁标识
 19      */
 20     public String lockWithTimeout(String lockName, long acquireTimeout, long timeout) {
 21         Jedis conn = null;
 22         String retIdentifier = null;
 23         try {
 24             // 获取连接
 25             conn = jedisPool.getResource();
 26             // 随机生成一个value
 27             String identifier = UUID.randomUUID().toString();
 28             // 锁名,即key值
 29             String lockKey = "lock:" + lockName;
 30             // 超时时间,上锁后超过此时间则自动释放锁
 31             int lockExpire = (int) (timeout / 1000);
 32 
 33             // 获取锁的超时时间,超过这个时间则放弃获取锁
 34             long end = System.currentTimeMillis() + acquireTimeout;
 35             while (System.currentTimeMillis() < end) {
 36                 if (conn.setnx(lockKey, identifier) == 1) {
 37                     conn.expire(lockKey, lockExpire);
 38                     // 返回value值,用于释放锁时间确认
 39                     retIdentifier = identifier;
 40                     return retIdentifier;
 41                 }
 42                 // 返回-1代表key没有设置超时时间,为key设置一个超时时间
 43                 if (conn.ttl(lockKey) == -1) {
 44                     conn.expire(lockKey, lockExpire);
 45                 }
 46 
 47                 try {
 48                     Thread.sleep(10);
 49                 } catch (InterruptedException e) {
 50                     Thread.currentThread().interrupt();
 51                 }
 52             }
 53         } catch (JedisException e) {
 54             e.printStackTrace();
 55         } finally {
 56             if (conn != null) {
 57                 conn.close();
 58             }
 59         }
 60         return retIdentifier;
 61     }
 62 
 63     /**
 64      * 释放锁
 65      * @param lockName   锁的key
 66      * @param identifier 释放锁的标识
 67      * @return
 68      */
 69     public boolean releaseLock(String lockName, String identifier) {
 70         Jedis conn = null;
 71         String lockKey = "lock:" + lockName;
 72         boolean retFlag = false;
 73         try {
 74             conn = jedisPool.getResource();
 75             while (true) {
 76                 // 监视lock,准备开始事务
 77                 conn.watch(lockKey);
 78                 // 通过前面返回的value值判断是不是该锁,若是该锁,则删除,释放锁
 79                 if (identifier.equals(conn.get(lockKey))) {
 80                     Transaction transaction = conn.multi();
 81                     transaction.del(lockKey);
 82                     List<Object> results = transaction.exec();
 83                     if (results == null) {
 84                         continue;
 85                     }
 86                     retFlag = true;
 87                 }
 88                 conn.unwatch();
 89                 break;
 90             }
 91         } catch (JedisException e) {
 92             e.printStackTrace();
 93         } finally {
 94             if (conn != null) {
 95                 conn.close();
 96             }
 97         }
 98         return retFlag;
 99     }
100 }

RedisTemplate实现setnx分布式锁

package com.prison.common.util;
 
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.RedisCallback;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Component;
 
import java.util.Objects;
 
/**
 * @ClassName RedisLockUtil
 * @Description 使用redis做锁
 * @Author WangJing
 * @Date 2020年6月8日
 * @Version V1.1.0
 */
@Component
public class RedisLockUtil {
 
    @Autowired
    RedisTemplate<String, Object> redisTemplate;
    /**
     * 任务锁前缀
     */
    public static final String TASK_LOCK_PREFIX = "t_l_prefix";
    /**
     * 任务锁过期时间 2000毫秒
     */
    public static final Integer TASK_LOCK_EXPIRE = 2000;
 
    /**
     * 获取锁,true 则得到锁,false 已被锁定
     * @param lockName       锁名称
     * @param lockExoire     锁时间
     * @return
     */
    public Boolean getLock(String lockName, Integer lockExoire) {
        return (Boolean) redisTemplate.execute((RedisCallback<?>) connection -> {
            // 获取时间毫秒值
            long expireAt = System.currentTimeMillis() + lockExoire + 1;
            // 获取锁
            Boolean acquire = connection.setNX(lockName.getBytes(), String.valueOf(expireAt).getBytes());
            if (acquire) {
                return true;
            } else {
                byte[] bytes = connection.get(lockName.getBytes());
                // 非空判断
                if (Objects.nonNull(bytes) && bytes.length > 0) {
                    long expireTime = Long.parseLong(new String(bytes));
                    // 如果锁已经过期
                    if (expireTime < System.currentTimeMillis()) {
                        // 重新加锁,防止死锁
                        byte[] set = connection.getSet(lockName.getBytes(),
                                String.valueOf(System.currentTimeMillis() + lockExoire + 1).getBytes());
                        return Long.parseLong(new String(set)) < System.currentTimeMillis();
                    }
                }
            }
            return false;
        });
    }
 
    /**
     * 删除锁
     * @param lockName
     */
    public void delLock(String lockName) {
        redisTemplate.delete(lockName);
    }
 
    /**
     * 获取锁Key
     * @param prefix    前缀
     * @param name      名称
     * @return
     */
    public static String getFullKey(String prefix, String name) {
        return prefix + "_" + name;
    }
 
}


相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore &nbsp; &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
2月前
|
缓存 NoSQL Java
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
这篇文章是关于如何在SpringBoot应用中整合Redis并处理分布式场景下的缓存问题,包括缓存穿透、缓存雪崩和缓存击穿。文章详细讨论了在分布式情况下如何添加分布式锁来解决缓存击穿问题,提供了加锁和解锁的实现过程,并展示了使用JMeter进行压力测试来验证锁机制有效性的方法。
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
|
2月前
|
存储 调度
分布式锁设计问题之云存储的最佳实践中保障分布式锁的容错能力如何解决
分布式锁设计问题之云存储的最佳实践中保障分布式锁的容错能力如何解决
|
2月前
|
缓存 NoSQL Java
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解、如何添加锁解决缓存击穿问题?分布式情况下如何添加分布式锁
这篇文章介绍了如何在SpringBoot项目中整合Redis,并探讨了缓存穿透、缓存雪崩和缓存击穿的问题以及解决方法。文章还提供了解决缓存击穿问题的加锁示例代码,包括存在问题和问题解决后的版本,并指出了本地锁在分布式情况下的局限性,引出了分布式锁的概念。
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解、如何添加锁解决缓存击穿问题?分布式情况下如何添加分布式锁
|
6天前
|
Java
分布式-Zookeeper-分布式锁
分布式-Zookeeper-分布式锁
|
6天前
|
网络协议 安全 Java
分布式(基础)-RMI的原理
分布式(基础)-RMI的原理
|
3月前
|
NoSQL 算法 Java
(十三)全面理解并发编程之分布式架构下Redis、ZK分布式锁的前世今生
本文探讨了从单体架构下的锁机制到分布式架构下的线程安全问题,并详细分析了分布式锁的实现原理和过程。
|
3月前
|
数据库
分布式锁实现问题之数据库中的分布式锁有哪些缺点
分布式锁实现问题之数据库中的分布式锁有哪些缺点
|
2月前
|
存储 调度
分布式锁设计问题之分布式锁系统通常设计其架构如何解决
分布式锁设计问题之分布式锁系统通常设计其架构如何解决
|
2月前
|
NoSQL 关系型数据库 MySQL
分布式锁设计问题之分布式锁内部实现的如何解决
分布式锁设计问题之分布式锁内部实现的如何解决
|
3月前
|
NoSQL 前端开发 算法
Redis问题之Redis分布式锁与Zookeeper分布式锁有何不同
Redis问题之Redis分布式锁与Zookeeper分布式锁有何不同
下一篇
无影云桌面