redis分布式锁的实现

爱⌒轻易说出口 提交于 2020-03-06 01:41:01

为什么要用分布式锁

使用场景

xx游戏平台举办了一个回馈用户活动,只要等级达到x等级,即可领取xx装备。可能有些人,有过这样的想,是不是,只要我速度够快,就能领到多份奖品啊,想想都美滋滋。结果,系统显示,当前操作过于频繁,请稍后再试。what???

这个的话,就涉及到了锁。同个账号,当我们的第一次请求到服务器的时候,已经被加上了锁,当还没释放锁的时候,再次请求,则不能拿到锁,只能继续等待。(当然这种场景不一定要用分布式锁进行实现,比如数据库的索引唯一性也可实行,只是举个例子)

说到锁的话,则要从公司系统的架构说起了。一开始,很多公司的系统不是很庞大,为了节省资源,单机即可满足需求。对于这种单机模式的系统,我们可以用java原生的synchronized和lock这两种锁,只要锁住相应的类、对象或者方法等即可简单的时间锁机制。

但随着公司的不断发展,用户量的增加,需要对业务进行拆分。这个时候,微服务就出现了,服务拆分了,同时为了保证高可用,每个服务会根据负载等因素,选择部署不同数量的机器,进行集群管理。

在分布式系统的话,则出现了同个服务,部署在不同的机器上。因为我们上面采用的是基于JVM的锁机制,没法保证同个用户请求的锁都是同个JVM(其实可以通过设置负载均衡策略,根据用户id进行hash之类,让用户落到同一台机器上,但这种很少用,毕竟这个是属于业务的问题),则需要使用分布式锁进行控制。

常见的分布式锁的解决方案

  • 基于数据库的分布式锁
  • 基于缓存的分布式锁,比如redis
  • 基于zookeeper的分布式锁

本文的话,则主要介绍 redis分布式锁的实现潜在的问题 以及 解决方法

基于redis分布式锁的实现

1.加锁

最简单的方法是使用setnx命令。key是锁的唯一标识,一般根据业务来命名。比如想给某个活动的某个用户加锁,则key可以命名为lock_xx(活动id)_XX(用户id),而value的话,这里的话,我们暂且设置为1。

    jc.setnx(key, 1);

当一个线程执行setnx返回1,说明key不存在,获取锁成功;当返回结果为0,说明key已经存在,获取锁失败。

2.解锁

有加锁,就得释放锁。当得到锁的线程执行完任务之后,需要释放锁,以便其他线程能够拿到锁,执行任务。

   jc.del(key);

释放锁成功之后,其他线程则能执行setnx命令,拿到锁执行任务。

3.设置锁超时

如果一个拿到锁的线程,在执行任务的过程中挂掉了,来不及显示的释放锁,则会一直占用着资源,导致其他线程无法拿到锁,没法执行任务。

所以在执行setnx命令之后,需要给锁显示设置一个锁超时时间,以保证即使拿到锁的线程挂掉了,也能在超过一定时间自动释放锁,让出资源。而setnx不支持设置超时参数,所以需要其他命令来执行。如下:

  jc.expire(key, seconds);

结合起来,分布式锁的代码如下:

    if (jc.setnx(key, value) == 1){
                jc.expire(key,30);
                try {
                    //业务逻辑
                }finally {
                    jc.del(key);
                }
            }

存在的问题分析

(1)setnx和expire的非原子性

设想一个极端场景,当线程成功执行了setnx,成功得到了锁:

结果,执行完setnx之后,节点1宕机了,还没来得及执行expire命令:

这样一来的话,这把锁还没设置超时时间,则会一直存在,一直占用着资源,导致其他线程拿不到锁,处于死锁状态。

解决方法

setnx指令本身是不支持设置超时参数,但在Redis 2.6.12以上版本,为set设置了可选参数,代码如下:

       //设置参数
        SetParams setParams = new SetParams();
        //设置过期时间,防止加锁之后宕机,一直处于死锁状态
        setParams.ex(expireTime);
        //当key不存在时,才创建key
        setParams.nx();
        String result = jc.set(lockKey, requestId,setParams);

(2)del误删

又是一个极端场景,假设节点1的线程A通过set拿到了锁,并设置了过期时间30秒

由于某些原因,导致线程A执行的很慢,超时时间30秒过去了,但线程A还没执行完,这个时候锁自动释放,线程B得到了锁

随后,线程A任务执行完,进行del操作释放锁,这个时候线程B还没执行完,线程A实际上删除的是线程B加的锁

解决方法

每个线程在set操作的时候,可以给value设置一个唯一的值,然后在del释放锁之前加一个判断,验证当前的锁是不是自身加的锁。

加锁
       String value = UUID.randomUUID().toString();
        //设置参数
        SetParams setParams = new SetParams();
        //设置过期时间,防止加锁之后宕机,一直处于死锁状态
        setParams.ex(expireTime);
        //当key不存在时,才创建key
        setParams.nx();
        String result = jc.set(lockKey, value,setParams);
释放锁
    //判断当前的锁是否是自己加的锁
        if (value.equals(jc.get(lockKey))){
            jc.del(lockKey);
        }

但是,这里又存在一个问题,类似上面的原子性,判断和删除操作是两个独立的操作,不是原子性。会有一个场景,就是判断的时候,获取的值是自身设置的值,但刚好在执行完判断操作之后,超时时间到期,自动释放锁,而刚好有其他线程拿到锁,这个时候在执行删除操作,则释放的是其他线程加的锁。
针对这种情况,我们可以使用Lua脚本进行实现,代码如下:

 String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
jc.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!