使用分布式锁一定注意两个坑

欢迎大家关注公众号「JAVA前线」查看更多精彩分享文章,主要包括源码分析、实际应用、架构思维、职场分享、产品思考等等,同时欢迎大家加我微信「java_front」一起交流学习


1 第一个坑:错误释放锁时机

1.1. 发现问题

分析以下代码存在什么问题:

// 分布式锁服务
public interface RedisLockService {
    // 获取锁
    public boolean getLock(String key);
    // 释放锁
    public boolean releaseLock(String key);
}

// 业务服务
public class BizService {

    @Resource
    private RedisLockService redisLockService;

    public void bizMethod(String bizId) {
        try {
            // 获取锁
            if(redisLockService.getLock(bizId)) {
                // 业务重复校验
                if(!bizValidate(bizId)) {
                    throw new BizException(ErrorBizCode.REPEATED);
                }
                // 执行业务
                return doBusiness();
            }
            // 获取锁失败
            throw new BizException(ErrorBizCode.GET_LOCK_ERROR);
        } finally {
            // 释放锁
            redisLockService.releaseLock(bizId);
        }
    }
}

上述代码看似没问题,实则隐藏大问题。问题在于释放锁时没有校验当前线程是否拿到锁:

  • 线程1和线程2同一时刻访问业务方法
  • 线程2获取锁成功,进行业务处理
  • 线程1没有获取到锁,但是释放锁成功
  • 此时线程3尝试获取锁成功,但是线程2业务未处理完,所以线程3不会触发业务重复异常
  • 最终导致线程2和线程3重复执行业务

1.2 解决问题

解决方案是在确认获取锁成功后才允许释放锁:

public class BizService {

    @Resource
    private RedisLockService redisLockService;

    public void bizMethod(String bizId) {
        boolean getLockSuccess = false;
        try {
            // 尝试获取锁
            getLockSuccess = redisLockService.getLock(bizId);
            // 获取锁成功
            if(getLockSuccess) {
                // 业务重复校验
                if(!bizValidate(bizId)) {
                    throw new BizException(ErrorBizCode.REPEATED);
                }
                // 执行业务
                return doBusiness();
            }
            // 获取锁失败
            throw new BizException(ErrorBizCode.GET_LOCK_ERROR);
        } finally {
            // 获取锁成功才允许释放锁
            if(getLockSuccess) {
                redisLockService.releaseLock(bizId);
            }
        }
    }
}

2 第二个坑:缓存失效问题

第二个问题是Redis还存在内存清理机制,可能会导致分布式锁失效。


2.1 过期清理机制

(1) 定期删除

Redis定时检查哪些key已经过期,发现过期则删除


(2) 惰性删除

如果key非常多,定期删除会非常消耗资源,所以引入惰性删除策略。如果Redis访问key时发现已经过期则直接删除


2.2 内存回收机制

当内存不足时Redis会选择一些元素进行删除:

no-enviction
禁止驱逐数据,新写入操作会报错

volatile-lru
从已设置过期时间的数据集选择最近最少使用的数据淘汰

volatile-ttl
从已设置过期时间的数据集选择将要过期的数据淘汰

volatile-random
从已设置过期时间的数据集选择任意的数据淘汰

allkeys-lru
从数据集选择最近最少使用的数据淘汰

allkeys-random
从数据集选择任意的数据淘汰

至少存在两种场景导致分布式锁失效问题:

  • 场景一:Redis内存不足进行内存回收,使用allkeys-lru或者allkeys-random回收策略导致锁失效

  • 场景二:线程获取分布式锁成功,但处理业务时间过长,此时锁到期被定时清理,导致其它线程获取锁成功并重复执行业务


2.3 乐观锁

通用方案是在数据库层保护,例如库存扣减业务在数据库层用乐观锁,原理参看《MySQL乐观锁扣减库存原理图解》这篇文章。

udpate goods set stock = stock - #{acquire} 
where sku_id = #{skuId} and stock - #{acquire} >= 0

欢迎大家关注公众号「JAVA前线」查看更多精彩分享文章,主要包括源码分析、实际应用、架构思维、职场分享、产品思考等等,同时欢迎大家加我微信「java_front」一起交流学习

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值