用万字长文来讲讲本地锁至分布式锁的演进和Redis实现,扩展 Redlock 红锁2

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
简介: 用万字长文来讲讲本地锁至分布式锁的演进和Redis实现,扩展 Redlock 红锁

用万字长文来讲讲本地锁至分布式锁的演进和Redis实现,扩展 Redlock 红锁1:https://developer.aliyun.com/article/1394703

3.2、解决死锁问题

最容易想到也是最简单的方式就是给这个分布式锁加个过期时间,比如3s、5s之类,使用EXPIRE设置一个过期时间

但如果想到的是这种:

redis> SETNX mykey "Hello"
(integer) 1
redis> EXPIRE mykey 10
(integer) 1
redis> SETNX mykey "World"
(integer) 0
redis> TTL mykey
(integer) 8
redis> GET mykey
"Hello"

如果是这么实现的话,咱们就还是对于 Redis 了解太少了。

首先说说这样操作会出现的问题:

  1. 我成功设置了key,但是还没执行到设置时间那一步,应用程序突然挂了,导致死锁问题产生。
  2. 或者是成功设置了 key 后,Redis 服务突然崩溃了,不干活了,这也导致了后面的EXPIRE无法执行成功,同样会产生死锁问题。

重点】:因为加锁和设置时间不是一个原子性操作

怎么才能将加锁和设置锁时间变成一个原子操作呢?

其实这一步Redis已经帮我们做好啦~

Redis 中的set命令是可以添加参数的,一条set命令即可实现SETNX+EXPIRE效果,将加锁和设置时间变成一个原子性操作,要么一起成功,要么一起失败。

完整命令参数:文档链接

SET key value [EX seconds|PX milliseconds|KEEPTTL] [NX|XX] [GET]

  • EXseconds – 设置键key的过期时间,单位时秒
  • PXmilliseconds – 设置键key的过期时间,单位时毫秒
  • NX – 只有键key不存在的时候才会设置key的值
  • XX – 只有键key存在的时候才会设置key的值
  • KEEPTTL -- 获取 key 的过期时间
  • GET -- 返回 key 存储的值,如果 key 不存在返回空

注意: 由于SET命令加上选项已经可以完全取代SETNX, SETEX, PSETEX, GETSET,的功能,所以在将来的版本中,redis可能会不推荐使用并且最终抛弃这几个命令。

返回值

字符串: 如果SET命令正常执行那么回返回OK多行字符串: 使用 GET 选项,返回 key 存储的值,如果 key 不存在返回空: 否则如果加了NX 或者 XX选项,SET 没执行,那么会返回nil。

例子

image.png

从这个小案例中可以看出,这是符合我们要的命令的~

Java 代码实现:这一步的代码实现和上一小节相比,仅改动了一行代码:

上一小节:

Boolean lock = stringRedisTemplate.opsForValue().setIfAbsent(SET_NX_EX_MENU_LIST_LOCK, SET_NX_EX_MENU_LIST_LOCK_VALUE);

加上过期时间:

Boolean lock = stringRedisTemplate.opsForValue().setIfAbsent(SET_NX_EX_MENU_LIST_LOCK, SET_NX_EX_MENU_LIST_LOCK_VALUE, 5L, TimeUnit.SECONDS);

就这样,再那样,再这样,你看死锁问题就被解决啦😜

死锁问题确实被解决了,现在你觉得还有问题吗

我们把它的每一个步骤都拆分来看,就会出现下面的这样一个场景:

假设我们约定锁过期时间为5s,但是执行这个业务时突然卡起来,此业务执行时间超过了我们预估的 5s,那么就可能出现以下情况:

第一条线程抢到锁,业务执行超时,第一条线程所持有的锁被自动释放;此时第二条线程拿到锁,准备执行业务,刚好第一条线程业务执行完成,照常执行了释放锁的过程,导致第二条线程持有的锁被第一条线程所释放,锁被其他人释放

这个情况中存在两个问题:

  1. 业务执行超时,锁被自动释放
  2. 锁被其他人释放,导致业务出现问题

关于第一个问题,就是常说的锁续期问题,这点之后在使用 Redission 时再细谈。

第二个问题,就比较好解决了,我们每次加锁的时候,带上自己的身份标识,在解锁的时候,进行一次判断即可。

接着往下看吧 👇

3.3、锁被其他人释放,该怎么办?

我们每次加锁的时候,带上自己的身份标识,在解锁的时候,进行一次判断即可。

比如:加锁的时候,生成一个UUID作为 KEY,释放锁时,获取一下锁,判断一下UUID是否相等,相等则执行删除,否则不执行删除。

在 Redis 中命令演示如下:

设置锁:set uuid  "lock" NX EX 60

释放锁:1、get uuid,身份标识相等,则执行2;2、 del uuid

image.png

Java 代码如下:

/**
 * @description:
 * @author: Ning Zaichun
 * @date: 2022年09月20日 20:59
 */
@Service
public class SetNxExLockServiceImpl implements ISetNxExLockService {
    @Autowired
    StringRedisTemplate stringRedisTemplate;
    @Autowired
    private MenuMapper menuMapper;
    private static final String SET_NX_EX_MENU_LIST = "set:nx:ex:menu:list";
    private static final String SET_NX_EX_MENU_LIST_LOCK = "set:nx:ex:menu:list:lock";
    private static final String SET_NX_EX_MENU_LIST_LOCK_VALUE = "lock";
    @Override
    public List<MenuEntity> getList() {
        // 判断缓存是否有数据
        String menuJson = stringRedisTemplate.opsForValue().get(SET_NX_EX_MENU_LIST);
        if (menuJson != null) {
            System.out.println("缓存中有,直接返回缓存中的数据");
            List<MenuEntity> menuEntityList = JSON.parseObject(menuJson, new TypeReference<List<MenuEntity>>() {
            });
            return menuEntityList;
        }
        // 从数据库中查询
        List<MenuEntity> result = getMenuJsonFromDbWithRedisLock();
        return result;
    }
    /**
     * 问题:锁被其他人释放,这该如何处理。
     * 加锁的时候,将值给定位一个唯一的标识符(我这里使用的是 UUID )
     * 1、解锁之前,先判断是不是自己获取的那把锁,
     * 2、确定是一把锁就执行 解锁锁操作
     *
     * @return
     */
    public List<MenuEntity> getMenuJsonFromDbWithRedisLock() {
        List<MenuEntity> result = new ArrayList<>();
        System.out.println("缓存中没有,加锁,重新从数据中查询~==>");
        // 给锁设定一个时间
        String uuid = UUID.randomUUID().toString();
        Boolean lock = stringRedisTemplate.opsForValue().setIfAbsent(SET_NX_EX_MENU_LIST_LOCK, uuid, 5L, TimeUnit.SECONDS);
        if (lock) {
            System.out.println("获取分布式锁成功...");
            try {
                //加锁成功...执行业务
                result = menuMapper.selectList(new QueryWrapper<MenuEntity>());
                stringRedisTemplate.opsForValue().set(SET_NX_EX_MENU_LIST, JSON.toJSONString(result));
            } finally {
                // 获取锁,判断是不是当前线程的锁
                String token = stringRedisTemplate.opsForValue().get(SET_NX_EX_MENU_LIST_LOCK);
                if (uuid.equals(token)) {
                    // 确定是同一把锁, 才释放锁
                    stringRedisTemplate.delete(SET_NX_EX_MENU_LIST_LOCK);
                }
            }
            return result;
            /**
             * 那这样就没有问题了吗?
             * 并不是。
             * 这里存在的问题也很明显,删除操作已经不在是一个原子性操作了。
             * 1、一个是查询判断
             * 2、第二个才是解锁操作
             * 那么又会拆分成,如果我第一步执行成功,第二步执行失败的场景,所以我们要把它变成原子操作才行。
             */
        } else {
            System.out.println("获取分布式锁失败...等待重试...");
            //加锁失败...重试机制
            //休眠一百毫秒
            try {
                TimeUnit.MILLISECONDS.sleep(100);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            return getMenuJsonFromDbWithRedisLock();
        }
    }
    @Override
    public Boolean updateMenuById(MenuEntity menu) {
        //        return updateMenuByIdWithLock(menu);
        //        return updateMenuWithExpireLock(menu);
        return updateMenuWithRedisLock(menu);
    }
    public Boolean updateMenuWithExpireLock(MenuEntity menu) {
        // 给锁设定一个时间
        Boolean lock = stringRedisTemplate.opsForValue().setIfAbsent(SET_NX_EX_MENU_LIST_LOCK, SET_NX_EX_MENU_LIST_LOCK_VALUE, 5L, TimeUnit.SECONDS);
        Boolean update = false;
        if (lock) {
            System.out.println("更新操作:获取分布式锁成功===> 清除缓存");
            try {
                // 删除缓存
                stringRedisTemplate.delete(SET_NX_EX_MENU_LIST);
                // 更新数据库
                update = menuMapper.updateById(menu) > 0;
            } finally {
                // 一定要释放锁,以免造成死锁问题
                stringRedisTemplate.delete(SET_NX_EX_MENU_LIST_LOCK);
            }
            return update;
        }  else{
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
            return updateMenuWithExpireLock(menu);
        }
    }
}

那么这就没有问题了吗?

并不是。这里存在的问题也很明显,删除操作又已经不再是一个原子性操作了。

  • 第一步是查询判断
  • 第二步才是解锁操作

那么继而又会出现,我第一步执行成功,第二步执行失败的场景,所以我们必须要把它变成原子性操作才行。

这个时就要用到了 Redis 中的 lua 脚本啦~

让它去帮助我们实现将判断和解锁变成一步原子性操作~ 接着看吧

用万字长文来讲讲本地锁至分布式锁的演进和Redis实现,扩展 Redlock 红锁3:https://developer.aliyun.com/article/1394710

相关实践学习
基于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 中间件
Redis,分布式缓存演化之路
本文介绍了基于Redis的分布式缓存演化,探讨了分布式锁和缓存一致性问题及其解决方案。首先分析了本地缓存和分布式缓存的区别与优劣,接着深入讲解了分布式远程缓存带来的并发、缓存失效(穿透、雪崩、击穿)等问题及应对策略。文章还详细描述了如何使用Redis实现分布式锁,确保高并发场景下的数据一致性和系统稳定性。最后,通过双写模式和失效模式讨论了缓存一致性问题,并提出了多种解决方案,如引入Canal中间件等。希望这些内容能为读者在设计分布式缓存系统时提供有价值的参考。感谢您的阅读!
Redis,分布式缓存演化之路
|
3天前
|
NoSQL Redis 数据库
Redis 功能扩展 Lua 脚本 对Redis扩展 eval redis.call redis.pcall
通过本文的介绍,我们详细讲解了 Lua 脚本在 Redis 中的作用、`eval` 命令的使用方法以及 `redis.call` 和 `redis.pcall` 的区别和用法。通过合理使用 Lua 脚本,可以实现复杂的业务逻辑,确保操作的原子性,并减少网络开销,从而提高系统的性能和可靠性。
26 13
|
26天前
|
SQL Java 关系型数据库
【📕分布式锁通关指南 01】从解决库存超卖开始加锁的初体验
本文通过电商场景中的库存超卖问题,深入探讨了JVM锁、MySQL悲观锁和乐观锁的实现及其局限性。首先介绍了单次访问下库存扣减逻辑的正常运行,但在高并发场景下出现了超卖问题。接着分析了JVM锁在多例模式、事务模式和集群模式下的失效情况,并提出了使用数据库锁机制(如悲观锁和乐观锁)来解决并发问题。 悲观锁通过`update`语句或`select for update`实现,能有效防止超卖,但存在锁范围过大、性能差等问题。乐观锁则通过版本号或时间戳实现,适合读多写少的场景,但也面临高并发写操作性能低和ABA问题。 最终,文章强调没有完美的方案,只有根据具体业务场景选择合适的锁机制。
41 12
|
2月前
|
NoSQL Java Redis
秒杀抢购场景下实战JVM级别锁与分布式锁
在电商系统中,秒杀抢购活动是一种常见的营销手段。它通过设定极低的价格和有限的商品数量,吸引大量用户在特定时间点抢购,从而迅速增加销量、提升品牌曝光度和用户活跃度。然而,这种活动也对系统的性能和稳定性提出了极高的要求。特别是在秒杀开始的瞬间,系统需要处理海量的并发请求,同时确保数据的准确性和一致性。 为了解决这些问题,系统开发者们引入了锁机制。锁机制是一种用于控制对共享资源的并发访问的技术,它能够确保在同一时间只有一个进程或线程能够操作某个资源,从而避免数据不一致或冲突。在秒杀抢购场景下,锁机制显得尤为重要,它能够保证商品库存的扣减操作是原子性的,避免出现超卖或数据不一致的情况。
76 10
|
3月前
|
存储 运维 NoSQL
分布式读写锁的奥义:上古世代 ZooKeeper 的进击
本文作者将介绍女娲对社区 ZooKeeper 在分布式读写锁实践细节上的思考,希望帮助大家理解分布式读写锁背后的原理。
113 11
|
2月前
|
NoSQL Redis
redis红锁
在Redis集群中,若请求分布式锁成功后Master宕机且Slave未同步此锁,会导致锁被多次获取。为解决此问题,可对集群每个节点加锁,当大多数节点(N/2+1)加锁成功时,视为获取锁成功。尽管Redisson实现了红锁,但其无法确保每个锁分布在不同Master上,因此建议直接使用Redisson的普通锁。
40 5
|
2月前
|
存储 NoSQL Java
使用lock4j-redis-template-spring-boot-starter实现redis分布式锁
通过使用 `lock4j-redis-template-spring-boot-starter`,我们可以轻松实现 Redis 分布式锁,从而解决分布式系统中多个实例并发访问共享资源的问题。合理配置和使用分布式锁,可以有效提高系统的稳定性和数据的一致性。希望本文对你在实际项目中使用 Redis 分布式锁有所帮助。
197 5
|
3月前
|
NoSQL Java 数据处理
基于Redis海量数据场景分布式ID架构实践
【11月更文挑战第30天】在现代分布式系统中,生成全局唯一的ID是一个常见且重要的需求。在微服务架构中,各个服务可能需要生成唯一标识符,如用户ID、订单ID等。传统的自增ID已经无法满足在集群环境下保持唯一性的要求,而分布式ID解决方案能够确保即使在多个实例间也能生成全局唯一的标识符。本文将深入探讨如何利用Redis实现分布式ID生成,并通过Java语言展示多个示例,同时分析每个实践方案的优缺点。
99 8
|
3月前
|
缓存 NoSQL PHP
Redis作为PHP缓存解决方案的优势、实现方式及注意事项。Redis凭借其高性能、丰富的数据结构、数据持久化和分布式支持等特点,在提升应用响应速度和处理能力方面表现突出
本文深入探讨了Redis作为PHP缓存解决方案的优势、实现方式及注意事项。Redis凭借其高性能、丰富的数据结构、数据持久化和分布式支持等特点,在提升应用响应速度和处理能力方面表现突出。文章还介绍了Redis在页面缓存、数据缓存和会话缓存等应用场景中的使用,并强调了缓存数据一致性、过期时间设置、容量控制和安全问题的重要性。
65 5
|
2月前
|
存储 缓存 NoSQL
解决Redis缓存数据类型丢失问题
解决Redis缓存数据类型丢失问题
184 85