Redis分布式锁

设计思路
基于 Redis 的 Setnx 命令:在指定的 key 不存在时,为 key 设置指定的值。

具体思路和实现步骤,详见代码。

import org.springframework.data.redis.core.RedisCallback;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Component;

import java.util.HashMap;
import java.util.Map;
import java.util.Objects;
import java.util.Optional;
import java.util.concurrent.atomic.AtomicLong;

/**
 * Redis分布式锁
 *
 * @author Alisallon
 * Created on 2021/4/25 9:34.
 */
@Component
public class RedisLock {
    /**
     * 保存锁以及过期时间,用于解决释放锁造成的问题
     */
    private static final Map<String, Long> LOCK_MAP = new HashMap<>();
    private final StringRedisTemplate redisTemplate;

    public RedisLock(StringRedisTemplate redisTemplate) {
        this.redisTemplate = redisTemplate;
    }

    /**
     * 尝试获取分布式锁(加锁)
     *
     * @param lock   锁名称
     * @param expire 锁过期时间
     * @return 是否获取到
     */
    public boolean lock(String lock, long expire) {
        try {
            AtomicLong expireAt = new AtomicLong();
            Object result = redisTemplate.execute((RedisCallback<Object>) connection -> {
                // 尝试给锁设置值(保存的是未来的过期时间)
                expireAt.set(System.currentTimeMillis() + expire + 1);
                Boolean acquire = connection.setNX(lock.getBytes(), String.valueOf(expireAt.get()).getBytes());
                if (Optional.ofNullable(acquire).orElse(false)) {
                    // 设置值成功,即获取锁成功(加锁成功)
                    return true;
                }
                // 设置值失败,即没有获取到锁,获取锁的对应的值(过期时间)
                byte[] value = connection.get(lock.getBytes());
                if (Objects.nonNull(value) && value.length > 0) {
                    // 获取锁的对应的值(过期时间)成功
                    long expireTime = Long.parseLong(new String(value));
                    // 判断锁是否过期
                    if (expireTime < System.currentTimeMillis()) {
                        // 锁已经过期,表示没有其他程序在占用锁(不能排除占用锁的程序,因为逻辑复杂造成执行时间太长或者程序挂掉了,还没来得及释放锁)
                        // 这里为了防止死锁,直接对已过期的锁重新设置过期时间,同时获得设置新值之前的旧过期时间
                        expireAt.set(System.currentTimeMillis() + expire + 1);
                        byte[] oldValue = connection.getSet(lock.getBytes(), String.valueOf(expireAt.get()).getBytes());
                        if (Optional.ofNullable(oldValue).isPresent()) {
                            // 重新判断设置新值之前的旧过期时间是否真的过期,因为可能会同时存在多个程序在竞争该锁
                            // 如果oldValue还未过期,说明该锁被其他程序抢走了
                            // 如果oldValue已过期,说明该锁未被占用,当前程序可以获得该锁
                            return Long.parseLong(new String(oldValue)) < System.currentTimeMillis();
                        }
                    }
                }
                // 锁的对应的值失败,返回获取锁失败
                return false;
            });
            if (Optional.ofNullable(result).map(t -> (Boolean) result).orElse(false)) {
                // 获取锁成功
                // 在当前程序中保存该锁和过期时间,会在释放锁时使用
                LOCK_MAP.put(lock, expireAt.longValue());
                return true;
            }
            // 获取锁失败
            return false;
        } catch (Exception e) {
            // 获取锁异常,返回获取锁失败
            return false;
        }
    }

    /**
     * 释放锁
     * 必须和上面的lock方法成对出现
     * 需要注意,如果lock方法后面的执行逻辑里有try-catch,一定要在finally中释放锁
     *
     * @param lock 锁名称
     */
    public void release(String lock) {
        // 当当前占用锁的程序因为逻辑复杂造成执行时间太长(执行正常无误),超过了锁的超时时间,这时锁可能会被其他程序抢走
        // 如果直接delete,可能会把其他程序抢走的锁释放,并且被另一个程序抢走,这会造成多个程序同一种业务逻辑并发执行,可能会造成数据不一致的问题
        // 为了解决这个问题,引入了LOCK_MAP
        // 如果LOCK_MAP中存在该锁,需要判断该锁的超时时间
        if (LOCK_MAP.containsKey(lock)) {
            // 已存在该锁
            long expireAt = LOCK_MAP.get(lock);
            if (expireAt <= System.currentTimeMillis()) {
                // 该锁已过期,此时无需手动释放锁,因为该锁可能已经被其他程序抢走了
                // 如果释放了锁,可能释放的不是本程序获得的锁,而是别的程序已抢走的锁,就可能会出现上面说的数据不一致的问题
                return;
            }
            // 该锁还未过期,可以释放锁,因为能主动调用release方法的一定是已获得锁的程序
        }
        try {
            // 释放锁
            redisTemplate.delete(lock);
            // 当前程序移除锁
            LOCK_MAP.remove(lock);
        } catch (Exception e) {
            // 释放锁异常,可以无视
        }
    }
}

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,294评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,493评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,790评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,595评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,718评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,906评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,053评论 3 410
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,797评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,250评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,570评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,711评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,388评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,018评论 3 316
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,796评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,023评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,461评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,595评论 2 350

推荐阅读更多精彩内容