掌握Redis分布式锁的正确姿势(2)

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
简介: 掌握Redis分布式锁的正确姿势

今天,我们主要讲的是基于Redis实现的分布式锁


reids实现分布式锁有三种方式


1、基于redis的 SETNX 实现分布式锁

2、Redisson实现分布式锁

4、使用redLock实现分布式锁


目录结构:

image.png


方式一:基于 SETNX 实现分布式锁


将key的值设为value ,当且仅当key不存在。

若给定的key已经存在,则SETNX不做任何动作。

setnx:当key存在,不做任何操作,key不存在,才设置


加锁:


SET orderId driverId NX PX 30000

上面的命令如果执行成功,则客户端成功获取到了锁,接下来就可以访问共享资源了;而如果上面的命令执行失败,则说明获取锁失败。

释放锁:

关键,判断是不是自己加的锁。


GrabService :


public interface GrabService {
    /**
     * 商品抢单
     * @param orderId
     * @param driverId
     * @return
     */
    public ResponseResult grabOrder(int orderId, int driverId);
}


GrabRedisLockServiceImpl :

@Service("grabRedisLockService")
public class GrabRedisLockServiceImpl implements GrabService {
  @Autowired
  StringRedisTemplate stringRedisTemplate;
  @Autowired
  OrderService orderService;
    @Override
    public ResponseResult grabOrder(int orderId , int driverId){
        //生成key
      String lock = "order_"+(orderId+"");
      /*
       *  情况一,如果锁没执行到释放,比如业务逻辑执行一半,运维重启服务,或 服务器挂了,没走 finally,怎么办?
       *  加超时时间
       */
//      boolean lockStatus = stringRedisTemplate.opsForValue().setIfAbsent(lock.intern(), driverId+"");
//      if(!lockStatus) {
//        return null;
//      }
      /*
       *  情况二:加超时时间,会有加不上的情况,运维重启
       */
//      boolean lockStatus = stringRedisTemplate.opsForValue().setIfAbsent(lock.intern(), driverId+"");
//      stringRedisTemplate.expire(lock.intern(), 30L, TimeUnit.SECONDS);
//      if(!lockStatus) {
//        return null;
//      }
      /*
       * 情况三:超时时间应该一次加,不应该分2行代码,
       * 
       */
      boolean lockStatus = stringRedisTemplate.opsForValue().setIfAbsent(lock.intern(), driverId+"", 30L, TimeUnit.SECONDS);
      if(!lockStatus) {
        return null;
      }
      try {
      System.out.println("用户:"+driverId+" 执行抢单逻辑");
            boolean b = orderService.grab(orderId, driverId);
            if(b) {
              System.out.println("用户:"+driverId+" 抢单成功");
            }else {
              System.out.println("用户:"+driverId+" 抢单失败");
            }
        } finally {
          /**
           * 这种释放锁有,可能释放了别人的锁。
           */
//          stringRedisTemplate.delete(lock.intern());
          /**
           * 下面代码避免释放别人的锁
           */
          if((driverId+"").equals(stringRedisTemplate.opsForValue().get(lock.intern()))) {
            stringRedisTemplate.delete(lock.intern());
          }
        }
        return null;
    }
}

这里可能会有人问,如果我业务的执行时间超过了锁释放的时间,会怎么办呢?我们可以使用守护线程,只要我们当前线程还持有这个锁,到了10S的时候,守护线程会自动对该线程进行加时操作,会续上30S的过期时间,直到把锁释放,就不会在进行续约了,开启一个子线程,原来时间是N,每隔N/3,在去续上N


关注点:


key,是我们的要锁的目标,比如订单ID。

driverId 是由我们的商品ID,它要保证在足够长的一段时间内在所有客户端的所有获取锁的请求中都是唯一的。即一个订单被一个用户抢。

NX表示只有当orderId不存在的时候才能SET成功。这保证了只有第一个请求的客户端才能获得锁,而其它客户端在锁被释放之前都无法获得锁。

PX 30000表示这个锁有一个30秒的自动过期时间。当然,这里30秒只是一个例子,客户端可以选择合适的过期时间。

这个锁必须要设置一个过期时间。 否则的话,当一个客户端获取锁成功之后,假如它崩溃了,或者由于发生了网络分区,导致它再也无法和Redis节点通信了,那么它就会一直持有这个锁,而其它客户端永远无法获得锁了。antirez在后面的分析中也特别强调了这一点,而且把这个过期时间称为锁的有效时间(lock validity time)。获得锁的客户端必须在这个时间之内完成对共享资源的访问。

此操作不能分割。

SETNX orderId driverId

EXPIRE orderId 30

虽然这两个命令和前面算法描述中的一个SET命令执行效果相同,但却不是原子的。如果客户端在执行完SETNX后崩溃了,那么就没有机会执行EXPIRE了,导致它一直持有这个锁。造成死锁。

方式二:基于redisson实现分布式锁


流程图:

image.png

代码实现:

@Service("grabRedisRedissonService")
public class GrabRedisRedissonServiceImpl implements GrabService {
  @Autowired
  RedissonClient redissonClient;
  @Autowired
  OrderService orderService;
    @Override
    public ResponseResult grabOrder(int orderId , int driverId){
        //生成key
      String lock = "order_"+(orderId+"");
      RLock rlock = redissonClient.getLock(lock.intern());
      try {
        // 此代码默认 设置key 超时时间30秒,过10秒,再延时
        rlock.lock();
      System.out.println("用户:"+driverId+" 执行抢单逻辑");
            boolean b = orderService.grab(orderId, driverId);
            if(b) {
              System.out.println("用户:"+driverId+" 抢单成功");
            }else {
              System.out.println("用户:"+driverId+" 抢单失败");
            }
        } finally {
          rlock.unlock();
        }
        return null;
    }
}

关注点:


redis故障问题。

如果redis故障了,所有客户端无法获取锁,服务变得不可用。为了提高可用性。我们给redis 配置主从。当master不可用时,系统切换到slave,由于Redis的主从复制(replication)是异步的,这可能导致丧失锁的安全性


1.客户端1从Master获取了锁。

2.Master宕机了,存储锁的key还没有来得及同步到Slave上。

3.Slave升级为Master。

4.客户端2从新的Master获取到了对应同一个资源的锁。

客户端1和客户端2同时持有了同一个资源的锁。锁的安全性被打破。


锁的有效时间(lock validity time),设置成多少合适?如果设置太短的话,锁就有可能在客户端完成对于共享资源的访问之前过期,从而失去保护;如果设置太长的话,一旦某个持有锁的客户端释放锁失败,那么就会导致所有其它客户端都无法获取锁,从而长时间内无法正常工作。应该设置稍微短一些,如果线程持有锁,开启线程自动延长有效期


方式三:基于RedLock实现分布式锁


针对于以上两点,antirez设计了Redlock算法

Redis的作者antirez给出了一个更好的实现,称为Redlock,算是Redis官方对于实现分布式锁的指导规范。Redlock的算法描述就放在Redis的官网上:

https://redis.io/topics/distlock


目的:对共享资源做互斥访问


因此antirez提出了新的分布式锁的算法Redlock,它基于N个完全独立的Redis节点(通常情况下N可以设置成5),意思就是N个Redis数据不互通,类似于几个陌生人


代码实现:

@Service("grabRedisRedissonRedLockLockService")
public class GrabRedisRedissonRedLockLockServiceImpl implements GrabService {
    @Autowired
    private RedissonClient redissonRed1;
    @Autowired
    private RedissonClient redissonRed2;
    @Autowired
    private RedissonClient redissonRed3;
    @Autowired
    OrderService orderService;
    @Override
    public ResponseResult grabOrder(int orderId , int driverId){
        //生成key
        String lockKey = (RedisKeyConstant.GRAB_LOCK_ORDER_KEY_PRE + orderId).intern();
        //红锁
        RLock rLock1 = redissonRed1.getLock(lockKey);
        RLock rLock2 = redissonRed2.getLock(lockKey);
        RLock rLock3 = redissonRed2.getLock(lockKey);
        RedissonRedLock rLock = new RedissonRedLock(rLock1,rLock2,rLock3);
        try {
           rLock.lock();
        // 此代码默认 设置key 超时时间30秒,过10秒,再延时
      System.out.println("用户:"+driverId+" 执行抢单逻辑");
            boolean b = orderService.grab(orderId, driverId);
            if(b) {
              System.out.println("用户:"+driverId+" 抢单成功");
            }else {
              System.out.println("用户:"+driverId+" 抢单失败");
            }
        } finally {
          rLock.unlock();
        }
        return null;
    }
}

image.png运行Redlock算法的客户端依次执行下面各个步骤,来完成 获取锁 的操作:


获取当前时间(毫秒数)。

按顺序依次向N个Redis节点执行 获取锁 的操作。这个获取操作跟前面基于单Redis节点的 获取锁 的过程相同,包含value driverId ,也包含过期时间(比如 PX 30000 ,即锁的有效时间)。为了保证在某个Redis节点不可用的时候算法能够继续运行,这个 获取锁 的操作还有一个超时时间(time out),它要远小于锁的有效时间(几十毫秒量级)。

客户端在向某个Redis节点获取锁失败以后,应该立即尝试下一个Redis节点。这里的失败,应该包含任何类型的失败,比如该Redis节点不可用,或者该Redis节点上的锁已经被其它客户端持有

计算整个获取锁的过程总共消耗了多长时间,计算方法是用当前时间减去第1步记录的时间。如果客户端从大多数Redis节点(>= N/2+1)成功获取到了锁,比如:五台机器如果加锁成功三台就默认加锁成功,并且获取锁总共消耗的时间没有超过锁的有效时间(lock validity time),那么这时客户端才认为最终获取锁成功;否则,认为最终获取锁失败

如果最终获取锁成功了,那么这个锁的有效时间应该重新计算,它等于最初的锁的有效时间减去第3步计算出来的获取锁消耗的时间。

如果最终获取锁失败了(可能由于获取到锁的Redis节点个数少于N/2+1,或者整个获取锁的过程消耗的时间超过了锁的最初有效时间),那么客户端应该立即向所有Redis节点发起 释放锁 的操作(即前面介绍的Redis Lua脚本)。

上面描述的只是 获取锁 的过程,而 释放锁 的过程比较简单:客户端向所有Redis节点发起 释放锁 的操作,不管这些节点当时在获取锁的时候成功与否。


总结


到这里redis分布式锁就讲完了,具体使用哪一种类型的分布式锁需要看公司业务的,流量大的可以使用RedLock实现分布式锁,流量小的可以使用redisson,后面会讲解Zookeeper实现分布式锁,喜欢的小伙伴可以关注我,对本文内容有疑问或者问题的同学可以留言,小农看到了会第一时间回复,谢谢大家,大家加油


目录
相关文章
|
1月前
|
存储 负载均衡 NoSQL
【赵渝强老师】Redis Cluster分布式集群
Redis Cluster是Redis的分布式存储解决方案,通过哈希槽(slot)实现数据分片,支持水平扩展,具备高可用性和负载均衡能力,适用于大规模数据场景。
172 2
|
2月前
|
存储 缓存 NoSQL
Redis核心数据结构与分布式锁实现详解
Redis 是高性能键值数据库,支持多种数据结构,如字符串、列表、集合、哈希、有序集合等,广泛用于缓存、消息队列和实时数据处理。本文详解其核心数据结构及分布式锁实现,帮助开发者提升系统性能与并发控制能力。
|
6天前
|
缓存 NoSQL 关系型数据库
Redis缓存和分布式锁
Redis 是一种高性能的键值存储系统,广泛用于缓存、消息队列和内存数据库。其典型应用包括缓解关系型数据库压力,通过缓存热点数据提高查询效率,支持高并发访问。此外,Redis 还可用于实现分布式锁,解决分布式系统中的资源竞争问题。文章还探讨了缓存的更新策略、缓存穿透与雪崩的解决方案,以及 Redlock 算法等关键技术。
|
2月前
|
NoSQL Redis
Lua脚本协助Redis分布式锁实现命令的原子性
利用Lua脚本确保Redis操作的原子性是分布式锁安全性的关键所在,可以大幅减少由于网络分区、客户端故障等导致的锁无法正确释放的情况,从而在分布式系统中保证数据操作的安全性和一致性。在将这些概念应用于生产环境前,建议深入理解Redis事务与Lua脚本的工作原理以及分布式锁的可能问题和解决方案。
121 8
|
3月前
|
缓存 NoSQL 算法
高并发秒杀系统实战(Redis+Lua分布式锁防超卖与库存扣减优化)
秒杀系统面临瞬时高并发、资源竞争和数据一致性挑战。传统方案如数据库锁或应用层锁存在性能瓶颈或分布式问题,而基于Redis的分布式锁与Lua脚本原子操作成为高效解决方案。通过Redis的`SETNX`实现分布式锁,结合Lua脚本完成库存扣减,确保操作原子性并大幅提升性能(QPS从120提升至8,200)。此外,分段库存策略、多级限流及服务降级机制进一步优化系统稳定性。最佳实践包括分层防控、黄金扣减法则与容灾设计,强调根据业务特性灵活组合技术手段以应对高并发场景。
986 7
|
4月前
|
NoSQL 算法 安全
redis分布式锁在高并发场景下的方案设计与性能提升
本文探讨了Redis分布式锁在主从架构下失效的问题及其解决方案。首先通过CAP理论分析,Redis遵循AP原则,导致锁可能失效。针对此问题,提出两种解决方案:Zookeeper分布式锁(追求CP一致性)和Redlock算法(基于多个Redis实例提升可靠性)。文章还讨论了可能遇到的“坑”,如加从节点引发超卖问题、建议Redis节点数为奇数以及持久化策略对锁的影响。最后,从性能优化角度出发,介绍了减少锁粒度和分段锁的策略,并结合实际场景(如下单重复提交、支付与取消订单冲突)展示了分布式锁的应用方法。
339 3
|
4月前
|
存储 NoSQL Java
从扣减库存场景来讲讲redis分布式锁中的那些“坑”
本文从一个简单的库存扣减场景出发,深入分析了高并发下的超卖问题,并逐步优化解决方案。首先通过本地锁解决单机并发问题,但集群环境下失效;接着引入Redis分布式锁,利用SETNX命令实现加锁,但仍存在死锁、锁过期等隐患。文章详细探讨了通过设置唯一标识、续命机制等方法完善锁的可靠性,并最终引出Redisson工具,其内置的锁续命和原子性操作极大简化了分布式锁的实现。最后,作者剖析了Redisson源码,揭示其实现原理,并预告后续关于主从架构下分布式锁的应用与性能优化内容。
234 0
|
6月前
|
数据采集 存储 数据可视化
分布式爬虫框架Scrapy-Redis实战指南
本文介绍如何使用Scrapy-Redis构建分布式爬虫系统,采集携程平台上热门城市的酒店价格与评价信息。通过代理IP、Cookie和User-Agent设置规避反爬策略,实现高效数据抓取。结合价格动态趋势分析,助力酒店业优化市场策略、提升服务质量。技术架构涵盖Scrapy-Redis核心调度、代理中间件及数据解析存储,提供完整的技术路线图与代码示例。
590 0
分布式爬虫框架Scrapy-Redis实战指南
|
4月前
|
数据采集 存储 NoSQL
基于Scrapy-Redis的分布式景点数据爬取与热力图生成
基于Scrapy-Redis的分布式景点数据爬取与热力图生成
300 67
|
7月前
|
NoSQL Java 中间件
【📕分布式锁通关指南 02】基于Redis实现的分布式锁
本文介绍了从单机锁到分布式锁的演变,重点探讨了使用Redis实现分布式锁的方法。分布式锁用于控制分布式系统中多个实例对共享资源的同步访问,需满足互斥性、可重入性、锁超时防死锁和锁释放正确防误删等特性。文章通过具体示例展示了如何利用Redis的`setnx`命令实现加锁,并分析了简化版分布式锁存在的问题,如锁超时和误删。为了解决这些问题,文中提出了设置锁过期时间和在解锁前验证持有锁的线程身份的优化方案。最后指出,尽管当前设计已解决部分问题,但仍存在进一步优化的空间,将在后续章节继续探讨。
1029 131
【📕分布式锁通关指南 02】基于Redis实现的分布式锁