Redis分布式锁存在的问题以及解决方式

发布时间:2024年01月18日

☆* o(≧▽≦)o *☆嗨~我是小奥🍹
📄📄📄个人博客:小奥的博客
📄📄📄CSDN:个人CSDN
📙📙📙Github:传送门
📅📅📅面经分享(牛客主页):传送门
🍹文章作者技术和水平有限,如果文中出现错误,希望大家多多指正!
📜 如果觉得内容还不错,欢迎点赞收藏关注哟! ??

Redis分布式锁实现

一、分布式锁

分布式锁:满足分布式系统或集群模式下多进程可见并且互斥的锁。

分布式锁的核心是实现多进程之间互斥,而满足这一点的方式有很多,常见的有三种:

MySQLRedisZookeeper
互斥利用MySQL本身的互斥锁机制利用setnx互斥命令利用节点的唯一性和有序性实现互斥
高可用
高性能一般一般
安全性断开连接,自动释放锁利用锁超时时间,到期释放临时节点,断开连接自动释放

二、 基于Redis的分布式锁

2.1 初级版本

实现基于Redis的分布式锁需要实现两个基本的方法:

获取锁

互斥:确保只有一个线程获取锁

// 添加锁,利用setnx的互斥特性
setnx lock thread1
// 添加锁过期时间,避免服务器宕机引起的死锁
expire lock 10
// 添加锁,NX是互斥,EX是设置超时时间
set lock thread1 NX EX 10

释放锁

  • 手动释放:删除key即可
  • 超时释放:获取锁时添加一个超时时间
// 释放锁,删除即可
del key

基本逻辑

  • 业务开始时尝试获取锁
    • 获取锁失败,直接返回
    • 获取锁成功,开始执行业务
      • 如果业务超时或服务宕机,自动释放锁
      • 否则执行完业务手动释放锁

存在的问题 :分布式锁误删问题

比如如下的场景:

  • 线程1首先获取锁,正常获取到锁,开始执行自己的业务。
  • 由于某种原因,线程1的业务被阻塞,并且阻塞时间超过了锁的过期时间,导致锁被自动释放
  • 锁被释放后,线程2再来获取锁,因为线程1的锁被释放了,所以线程2也能成功获取到锁,然后开始执行自己的业务。
  • 在线程2执行业务时,线程1的业务完成,线程1手动释放锁,此时,线程1释放的是线程2的锁。
  • 这时候,线程3也来获取锁,因为线程2的锁被线程1释放了,所以线程3也能成功获取到锁,然后开始执行自己的业务。
  • 此时,线程2和线程3是并行执行业务的,会出现错误的结果。

产生原因:

  • 没有唯一的锁标识,所以会产生误删的情况。

在这里插入图片描述

2.2 解决分布式锁误删问题

要想解决分布式锁误删的问题,主要的关键思路在于:如何判断是不是自己的锁。

这时就可以使用**线程标识 **(即线程ID)来当作分布式锁标识:

  • 如果线程标识与当前线程一致,则释放锁;
  • 如果线程标识与当前线程不一致,则不做处理;

处理逻辑

业务开始时尝试获取锁,锁的标识可以是线程ID:

  • 获取锁之前先比较当前线程ID与锁标识是否一致:
    • 不一致,获取锁失败,直接返回
    • 一致,获取锁成功,开始执行业务
      • 如果业务超时或服务宕机,自动释放锁
      • 业务执行完成,比较当前线程ID与锁标识是否一致
        • 一致,手动释放锁
        • 不一致,不做任何处理

存在的问题:分布式锁原子性问题

比如如下的场景:

  • 线程1首先获取锁,正常获取到锁,开始执行自己的业务。
  • 线程1业务执行完毕,需要手动释放锁,获取锁标识并判断是否与自己一致,结果一致,执行手动释放锁的动作,假设此时产生了阻塞,并且阻塞时间超过了锁的过期时间,导致锁被自动释放
  • 锁被释放后,线程2再来获取锁,因为线程1的锁被释放了,所以线程2也能成功获取到锁,然后开始执行自己的业务。
  • 在线程2执行业务过程中,线程1的阻塞结束了,此时继续执行手动释放锁动作,线程1手动释放锁,此时,线程1释放的是线程2的锁。
  • 这时候,线程3也来获取锁,因为线程2的锁被线程1释放了,所以线程3也能成功获取到锁,然后开始执行自己的业务。
  • 此时,线程2和线程3是并行执行业务的,会出现错误的结果。

产生原因:

  • 判断锁标识释放锁是两个操作,没有保证原子性。

在这里插入图片描述

2.3 分布式锁的原子性问题

要想解决操作原子性问题,我们可以使用Lua脚本解决多条命令原子性问题。

Redis提供的调用函数,语法如下:

# 执行redis的命令
redis.call('命令名称','key','其他参数',...)

Lua脚本

-- 锁的key
local key = KEYS[1]
-- 当前线程标识
local threadId = ARGV[1]
-- 比较线程标识与锁中的标识是否一致
if (redis.call('get', KEYS[1]) == ARGV[1]) then
	-- 释放锁
	return redis.call('del', KEYS[1])
end
return 0

Lua脚本处理逻辑

  • 获取锁中的线程标识
  • 判断是否与当前线程标识一致
    • 一致,手动删除锁
    • 不一致,不做处理

2.4 Redis分布式锁存在的问题

上面的实现逻辑呢,其实就已经能满足简单的分布式锁的功能了,但是由于它是我们自己实现的,所以还是会有一些问题:

(1)不可重入:同一个线程只能获取一次锁,无法多次获取同一把锁,如果我们有嵌套业务都需要用到分布式锁,那么这种Redis实现的锁就不可以使用了。

(2)不可重试:获取锁时如果获取失败就直接返回了,没有重试机制,这种对性能来说其实并不友好。

(3)超时释放:锁超时释放虽然可以避免死锁,但是如何业务执行耗时较长也会导致锁超时释放,存在不可预估的问题。

(4)主从一致性无法保证:如果Redis提供了主从集群,因为主从同步存在延迟,并且一般都是主写从读。如果线程在主节点获取了锁,并且尚未同步给从节点的过程中,突然主节点宕机,虽然Redis会重新选取一个从节点作为新的主节点,但是新主节点中没有锁的标识,所以也会出现多线程并行执行业务的情况(情况出现概率极低)。

文章来源:https://blog.csdn.net/qq_52805594/article/details/135684866
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。