万字详解本地锁到分布式锁的演进、Redis实现以及扩展 Redlock 红锁

本文详细介绍了从本地锁到分布式锁的演进过程,探讨了本地锁存在的问题及解决办法。在分布式锁实现中,讲解了Redis的setnx命令、死锁解决、lua脚本原子操作、Redisson的使用以及锁续期。文章还提到了分布式事务锁的挑战,并引出了Redis的红锁(Redlock)算法,分析了红锁的原理、异步性、失败重试策略、释放锁机制及其补充。文章最后提醒读者注意代码中递归调用的潜在问题,建议改用循环重试并限制次数以避免无限递归导致的崩溃。
摘要由CSDN通过智能技术生成

聊到分布式锁,就不得不先聊到本地锁,如果没有从本地锁到分布式锁这个演进过程或者说是推导过程,我觉得是不合适的,甚至是不完整的。

程序的发展是一步一步递进,知道它是解决什么样的问题,才能更好的理解和学习。

文章大纲:

本文字数约为1w字左右,建议可以腾出一点点空闲时间来阅读,都是我的存稿~ 哈哈,寻思着再不发,这个月都得过完了。

关于代码:

后期在检查时,发现案例中的代码是有点不太合适的,应当将所有案例中的递归调用方法改为循环重试,并限制重试次数,而非一直递归调用。 切记切记切记👨‍💻。

一、本地锁

1.1、本地锁的使用

本地锁主要是针对单体服务而言的,锁的都是单体应用内的进程。

像之前在单机情况下出现的读写并发情况。因为并发情况下网络出现问题或是出现其他卡顿问题,导致执行顺序发生变化,从而产生了数据不一致性。如下图:

解决并发最快的方式就是加锁吗,我们也就给它来把锁吧,Java中的锁是有蛮多的,我这里不过多讨论啦(synchronized、JUC)等等。

我案例中所使用的是 JUC 包下的读写锁ReentrantReadWriteLock ,毕竟不能让锁直接限制了Redis 的发挥~,读写锁是读并发,写独占的模式。

增加读写锁之后的流程图如下:

(图片说明:加上锁之后的流程)

案例代码如下:

/**
 * @description: 单机redis下的操作
 * @author: Ning Zaichun
 * @date: 2022年09月06日 23:20
 */
@Slf4j
@Service
public class RedisCacheServiceImpl implements IRedisCacheService {


    @Autowired
    private MenuMapper menuMapper;

    @Autowired
    StringRedisTemplate redisTemplate;

    private static final String REDIS_MENU_CACHE_KEY = "menu:list";

    private ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();


    @Override
    public List<MenuEntity> getList() {
        //1、从缓存中获取
        String menuJson = redisTemplate.opsForValue().get(REDIS_MENU_CACHE_KEY);
        if (!StringUtils.isEmpty(menuJson)) {
            System.out.println("缓存中有,直接从缓存中获取");
            //2、缓存不为空直接返回
            List<MenuEntity> menuEntityList = JSON.parseObject(menuJson, new TypeReference<List<MenuEntity>>() {
            });
            return menuEntityList;
        }
        //3、查询数据库
        //不加锁情况下
        // List<MenuEntity> noLockList = getMenuJsonFormDb();
        // 加锁情况下
        List<MenuEntity> menuEntityList = getMenuJsonFormDbWithReentrantReadWriteLock();
        return menuEntityList;
    }

    public List<MenuEntity> getMenuJsonFormDb() {
        System.out.println("缓存中没有,重新从数据中查询~==>");
        //缓存为空,查询数据库,重新构建缓存
        List<MenuEntity> result = menuMapper.selectList(new QueryWrapper<MenuEntity>());
        //4、将查询的结果,重新放入缓存中
        redisTemplate.opsForValue().set(REDIS_MENU_CACHE_KEY, JSON.toJSONString(result));
        return result;
    }

    public List<MenuEntity> getMenuJsonFormDbWithReentrantReadWriteLock() {
        List<MenuEntity> result = null;
        System.out.println("缓存中没有,加锁,重新从数据中查询~==>");
        // synchronized 是同步锁,所以当多个线程同时执行到这里时,会阻塞式等待
        ReentrantReadWriteLock.ReadLock readLock = readWriteLock.readLock();
        readLock.lock();
        try {
            String menuJson = redisTemplate.opsForValue().get(REDIS_MENU_CACHE_KEY);
            //加锁成功... 再次判断缓存是否为空
            if (!StringUtils.isEmpty(menuJson)) {
                System.out.println("缓存中,直接从缓存中获取");
                //2、缓存不为空直接返回
                List<MenuEntity> menuEntityList = JSON.parseObject(menuJson, new TypeReference<List<MenuEntity>>() {
                });
                return menuEntityList;
            }
            //缓存为空,查询数据库,重新构建缓存
            result = menuMapper.selectList(new QueryWrapper<MenuEntity>());
            //4、将查询的结果,重新放入缓存中
            redisTemplate.opsForValue().set(REDIS_MENU_CACHE_KEY, JSON.toJSONString(result));
            return result;
        } finally {
            readLock.unlock();
        }
    }


    @Override
    public Boolean updateMenuById(MenuEntity menu) {
        //return updateMenuByIdNoWithLock(menu);
        return updateMenuByIdWithReentrantReadWriteLock(menu);
    }


    public Boolean updateMenuByIdNoWithLock(MenuEntity menu) {
        // 1、删除缓存
        redisTemplate.delete(REDIS_MENU_CACHE_KEY);
        System.out.println("清空单机Redis缓存");
        // 2、更新数据库
        return menuMapper.updateById(menu) > 0;
    }

    public Boolean updateMenuByIdWithReentrantReadWriteLock(MenuEntity menu) {
        ReentrantReadWriteLock.WriteLock writeLock = readWriteLock.writeLock();
        writeLock.lock();
        try {
            // 1、删除缓存
            System.out.println("清除缓存");
            redisTemplate.delete(REDIS_MENU_CACHE_KEY);
            // 2、更新数据库
            return menuMapper.updateById(menu) > 0;
        }finally {
            writeLock.unlock();
        }
    }
}
复制代码

具体还需大家去了解~

我这里加的 JUC 下的读写锁,原本我想的是弄的JUC的锁

1.2、本地锁存在的问题

看起来本地锁没有并发问题,不管有多少请求一起进来,都要去争取那唯一的一把锁,抢到了才能继续往下执行业务

单体项目中,每把锁锁的就是当前服务中的当前线程的请求。

(图片说明:单体服务时)

但是当服务需要进一步扩展时,就会随之产生出一些问题。

多服务并发时,如果还是只给当前线程加锁,多个用户一起尝试获取锁时,可能会有多个用户同时获取到锁,导致出现问题。

如下图:

每个服务都是单独的,加锁操作也只是给自己的,大家不能共享,那么实际上在高并发的时候,是根本没效果的。

我1号服务抢到了锁,还没等到释放,2号服务又获取到了锁,接着3号、4号等等,大家都可以操作数据库,这把锁也就失去了它该有的作用。

因此就进一步出现了分布式锁,接下来继续看吧。

二、分布式锁的介绍

本地锁失效是因为无法锁住各个应用的读写请求,失效的根本原因就是其他的服务无法感知到是否已经有请求上锁了,即无法共享锁信息

分布式锁,其实也就是将加锁的这一个操作,单独的抽取出来了,让每个服务都能感知到。

之前就说了,软件架构设计中,"没有什么是加一层解决不了的,如果加一层不行就再加一层"。

这里其实也是一样,只不过碰巧这一层可以在Redis中实现罢了,看起来倒是没有多加一层,但如果是用Zookeeper 或者其他方式来实现,你会发现架构中会多一层滴。

其实理解思想实现的方式有很多种的,

  • Redis 实现分布式锁
  • Zookeeper 实现分布式锁
  • MySQL 专门用一张表来记录信息,实现分布式锁,也是常说的基于数据库实现分布式锁。

所谓的加锁,其本质也就是判断一个信号量是否存在罢了,分布式也就是把这个信号量从本地线程中,移植到了Redis中存储,让所有服务中的请求都能共享一把锁。知道思想后,实现方式并不局限,大家也不要局限了自己,都已经站在巨人肩膀上,就要想的更多一些~

我采用 Redis 实现分布式锁,主要原因:

  1. Redis 是基于内存操作的数据库,速度快;
  2. 市场主流的数据库,拥有较多的参考资料;
  3. Redis 社区开发者活跃,并且 Redis 对分布式锁有较好的支持;

今天所讨论的,主要就是针对于使用 Redis 实现分布式锁,流程图大致如下:

(图片说明:此图为获取锁的大致流程,其之后的构建缓存、释放锁等未在图上所标明)

虽然两个服务都是独立的,但是在执行数据库代码前,都需要先获取到读锁或者写锁,以确保并发时执行的正确性~

接下来就是说分布式锁的实现啦~

三、分布式锁的实现

在上一小节就已说分布式锁的实现有多种方式,大的范围中有 Redis、Zookeeper、MySQL等实现方式,我具体讲的是以 Redis 的实现。

讲解过程也是逐步深入,逐步演进,并非是直接丢出实现代码,针对为什么要这么做,为什么最终是这样,让大家有一个了解过程。

锁的第一个要求就是要能做到互斥,而在Redis中最容易想到,也是最简单的,无疑就是 setnx 命令。

我们就以 setnx抛砖引玉,来对分布式锁的实现,做一个逐步演进的讨论。

3.1、setnx

Redis SetnxSET IF Not EXists )命令在指定的 key 不存在时,为 key 设置指定的值,这种情况下等同 SET 命令。当 key存在时,什么也不做。

返回值

  • 如果key设置成功了,则返回1
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值