redis分布式锁实现方案深入探讨（锁重试、锁续租、Redis Module、Redisson、RedLock）

已于 2022-05-17 11:54:10 修改
阅读量3.4k 收藏 12
点赞数 2
分类专栏： redis原理与实战 文章标签： redis lua redis Module etcd zk
于 2022-05-17 11:53:14 首次发布
本文为博主原创文章，转载请注明本人源链接。微信公众号搜索：徐同学呀，愿与你共同进步！
本文链接：https://blog.csdn.net/weixin_36586120/article/details/124818167
版权

文章目录

分布式锁一般有如下的特点：

  • 互斥（Mutual Exclusion）： 同一时刻只能有一个线程持有锁
  • 同步：获取锁失败是可以阻塞，后续可被唤醒
  • 可重入性： 同一节点上的同一个线程如果获取了锁之后能够再次获取锁
  • 避免死锁（Dead lock free）：和J.U.C中的锁一样支持锁超时，防止死锁
  • 容错（Fault tolerance）： 避免单点故障，锁服务要有⼀定容错性

基本原理

Redis分布式锁，主要借助setnx和expire两个命令完成。

setnx 对一个key进行设置value时，如果这个key已经存在，就什么也不做，返回0；如果不存在，就在redis缓存里存储这个key-vlaue，并返回OK，表示获取锁成功。

setnx key “xxx”

释放锁的话就直接把这个key删除即可。

但是需要注意几个问题：

（1）持有锁的进程或线程因为异常，未释放锁，导致死锁。

（2）释放锁的时候，只有获取锁的那个进程才能删除这个key，其他进程不能。

给锁设置超时时间（setnx+expire）

第一个问题的解决方案就是给key设置一个超时时间，key超时之后自动删除就释放锁了。

setnx和expire是两个命令，虽说expire在setnx成功后执行，是线程安全的，但两个操作不是原子的，如果setnx成功，还没来得及expire，持有锁的进程就挂了，也是会造成死锁。

所以要保证setnx和expire是一个原子操作。

设置key的同时设置超时时间 set key value PX 100 NX

set key value [EX seconds] [PX milliseconds] [NX|XX]

EX seconds：设置失效时长，单位秒

PX milliseconds：设置失效时长，单位毫秒

NX：key不存在时设置value，成功返回OK，失败返回(nil)

XX：key存在时设置value，成功返回OK，失败返回(nil)

通过lua脚本将setnx和给key设置超时时间封装起来，用redis执行lua脚本达到原子性目的

使用lua脚本编写加减锁的逻辑，保证加锁和释放锁的原子性：

加锁的Lua脚本： lock.lua

--- -1 failed
--- 1 success
---
local key = KEYS[1]
local requestId = KEYS[2]
local ttl = tonumber(KEYS[3])
local result = redis.call('setnx', key, requestId)
if result == 1 then
    --PEXPIRE:以毫秒的形式指定过期时间
    redis.call('pexpire', key, ttl)
else
    result = -1;
    -- 如果value相同，则认为是同一个线程的请求，则认为重入锁
    local value = redis.call('get', key)
    if (value == requestId) then
        result = 1;
        redis.call('pexpire', key, ttl)
    end
end
--  如果获取锁成功，则返回 1
return result

释放锁逻辑（get+del）

释放锁的逻辑，必须是持有的锁的线程或进程才能释放锁，所以在加锁时，给key设置的value必须能唯一标识持有锁的对象，比如ip+port+threadId等

释放锁的时候先获取锁key的value，比对一下是不是和自己的唯一标识一样，一样就删除该key释放锁，不一样就什么也不做。

查询key和删除key，是两个动作，同样不是原子操作，所以可以通过lua脚本进行封装。

解锁的Lua脚本： unlock.lua:

--- -1 failed
--- 1 success

-- unlock key
local key = KEYS[1]
local requestId = KEYS[2]
local value = redis.call('get', key)
if value == requestId then
    redis.call('del', key);
    return 1;
end
return -1

锁续租

前面在加锁的时候，给key设置了超时时间，如果获取锁后，业务处理时间过长，还没处理完，锁就超时自动释放锁了，当前线程可能还不知道锁被超时释放，继续向下处理业务，另一个进程或者线程此时又获取锁成功，这样就出现了并发问题，锁基本没啥用。当然因为锁key设置value具有唯一性，所以不存在前一个线程把后一个线程获取到锁释放掉。

解决方法，就是可以先预估好业务处理需要的时长，然后预留多一点的超时时间给key。这种方式肯定是治标不治本，如果遇到fullgc，且时间过长，导致的stw，也会让预估的业务处理时长不准。

所以比较彻底的办法就是在加锁成功之后再起一个后台线程，定时检查锁是否过期，快过期的时候，延迟超时时间。

具体逻辑：

  1. 加锁成功，开启一个后台线程。
  2. 后台线程根据锁的超时时间，每隔3/4的超时时间去对锁进行一次锁key的超时重置。
  3. 续租时，需要先获取key的value看看是不是自己持有的锁，如果是才续租。
  4. 查看锁和续租封装在lua脚本里保证原子性。
if (redis.call('get', KEYS[1]) == ARGV[1]) then "
   return redis.call('pexpire', KEYS[1], ARGV[2]); "
else
   return nil; 
end;

锁重试

对同一把锁，假设一个进程加锁成功了，一个进程想再获取锁就得不断循环重试，这就相当于一个自旋锁，虽然没有线程上下文的切换，但是在锁竞争激烈的情况下，对cpu的占用和性能损耗是巨大的。

所以需要实现一种像java的synchronized或者AQS那样，在获取锁失败后，可以先自旋一段时间，如果还获取不到锁就进入同步队列阻塞等待。java的单进程锁，获取锁失败的线程阻塞可以由本进程持有锁的线程释放锁时唤醒，但是分布式锁，需要实现的是跨进程唤醒。

具体实现逻辑：

  1. 分布式锁可以在单进程里维护一个CLH，逻辑上跟AQS差不多，获取锁失败就进队列阻塞。如果是同进程的多个线程获取同一把锁被阻塞，可以达到同进程唤醒的效果。
  2. 当前进程没有线程持有锁，就需要跨进程唤醒，此时可以开启一个后台重试线程。
  3. 重试线程的逻辑就是，定时检查锁是否空闲，如果空闲就唤醒当前正在阻塞的线程。
  4. 获取锁成功后，就回收这个重试线程。

也可以使用带超时阻塞的LockSupport.parkNanos，在获取锁的主线程里进行重试逻辑。但是为了代码解耦，所以单独开启一个重试线程。也是为了防止惊群效应。

codis 没有pub/sub功能，如果想使用监听+远程唤醒的功能，需要用redis cluster

用zk和etcd实现的分布式锁，都可以使用watcher机制。

但是redis cluster、zk、etcd v2 的发布订阅都会存在惊群效应，一个事件变更，如果有大量的客户端监听，需要一个个远程通知，对这些集群的负载影响很大。

etcd v3，实现了类似java的AQS的clh，有多个监听会形成一个链表，不会一下子唤醒，而是依托前驱唤醒后继。

百度CAS/CAD

因为Lua 脚本的相关问题，性能、内存占用等，百度内部方案：SET + CAS/CAD Module，去掉了对Lua脚本的依赖。

加锁：

SET KEY VALUE NX PX 30000

续租：

CAS KEY VALUE VALUE PX 30000

释放锁：

CAD KEY VALUE

SET + CAS/CAD 的优点:

  • 命令简单，单条命令即可实现加锁、续约、解锁的功能。

  • 避免 Lua 脚本的问题：热点问题，扩缩容时间脚本丢失，以及 Lua 内存占用问题。

缺点：

  • Redis 的主从复制是异步的，failover 过程中可能丧失锁的安全性。
  • 锁可重入的问题

https://github.com/alibaba/alibabacloud-tairjedis-sdk

https://github.com/baidu/dlock

Redisson 分布式锁实现方案

Redisson 是架设在 Redis 基础上的一个 Java 驻内存数据网格（In-Memory Data Grid）

  • 可重入锁 RedissonLock

  • 读写锁 RedissonReadWriteLock

  • 公平锁 RedissonFairLock

  • 自旋锁 RedissonSpinLock

  • 联锁、红锁 RedissonMultiLock、RedissonRedLock

整个加锁流程：

Lua脚本源码：

Redisson 加锁的数据结构是一把锁对应的hash表，外围的大key是锁名称，里面的小key客户端唯一标识，value是锁重入次数，然后给这个哈希表设置超时时间。

**KEYS[1]**代表的是你加锁的那个key，比如说：

RLock lock = redisson.getLock(“DISLOCK”);

这里你自己设置了加锁的那个锁key就是“DISLOCK”。

**ARGV[1]**代表的就是锁key的默认生存时间

调用的时候，传递的参数为 internalLockLeaseTime ，该值默认30秒。

**ARGV[2]**代表的是加锁的客户端的ID，类似于下面这样：

01a6d806-d282-4715-9bec-f51b9aa98110:1

Redis Hincrby 命令用于为哈希表中的字段值加上指定增量值。

增量也可以为负数，相当于对指定字段进行减法操作。

如果哈希表的 key 不存在，一个新的哈希表被创建并执行 HINCRBY 命令。


Redisson优点：

  • 完整的解决方案，使用简单

  • 可重入、远程通知机制、自动续约（watch dog）

需要注意：Redisson 的 watchDog 只有在未显式指定加锁时间时才会生效。

缺点：

  • Redis 的主从复制是异步的，failover 过程中可能丧失锁的安全性

  • LUA 脚本的相关问题，性能，内存占用等

  • PUB/SUB 机制在集群模式下负载较重，spinlock对其进行了优化

RedLock

RedLock 是 Redis 官方针对 Redis 异步复制机制在 failover 过程可能导致数据丢失，而设计的一种分布式锁算法。RedLock也是Redisson中一种锁实现方案。

RedLock算法思想：

  • 获取锁的过程需要在一个奇数个redis实例集群上，获取超过一半以上实例的锁，才算是成功获取锁。
  • 释放锁的过程也是需要在所有获取到锁的实例上一个个释放，才是真正释放锁。
  • 获取锁失败，即获取锁的redis失败少于一半，那么需要把从其他实例获取的锁释放。

RedLock除了安全，再无其他优点：

  • 性能低，加锁和释放锁都需要操作多台redis
  • 部署实施复杂
  • 如果一台redis加锁成功，还没有持久化就宕机了，此时重启，另一个进程或线程又可以获取锁，所以要求redis宕机延迟重启，延迟时长为锁过期时间，但是redis里锁那么多，到底以哪个过期时间为准，不好判断。

使用redis分布式锁，是追求高性能， 在cap理论中，追求的是 ap 而不是cp。

所以，如果追求高可用，建议使用 zookeeper或者etcd实现分布式锁。

redis分布式锁可能导致的数据不一致性，建议使用业务补偿的方式去弥补。所以，不太建议使用红锁。

Redis分布式锁
Aasee的博客
05-20 1704
一文学会redis分布式锁
第二十章_Redis分布式锁Redlock算法和底层源码分析
sinat_31583645的博客
06-06 1031
首先，我们假设客户端能够在大多数实例中获取锁所有实例都将包含一个具有相同生存时间的密钥，然而，这个key是在不用时间设置的，所以过期也会在不同的时间过期，假设第一个key设置时间T1，最后一个key设置时间t2，我们确定第一个key的过期时间至少是MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT，所以所有的key设置超时至少是这个时间，在设置大多数密钥期间，另一个客户端将无法获取锁，因为如果已经存在N/2+1个密钥，则N/2+1 set NX操作无法成功。
项目实战，用Redis实现分布式锁，支持重试。
weixin_43819764的博客
01-30 2336
背景 对于锁大家肯定不会陌生，在单体系统中， Java 提供的 synchronized 关键字和 ReentrantLock 可重入锁基本能满足我们的需求。 但是随着分布式的快速发展，本地的加锁往往不能满足我们的需要。因为分布式与单机情况下最大的不同在于其不是多线程而是多进程。 多线程由于可以共享堆内存，因此可以简单的采取内存作为标记存储位置。而进程之间甚至可能都不在同一台物理机上，因此需要将标...
Redisson 自旋锁（Spin Lock）详解与应用
最新发布
nihao2q的博客
03-18 318
自旋锁（Spin Lock）是一种不断循环尝试获取锁的实现方式。与传统的阻塞锁不同，自旋锁不会让线程进入等待状态，而是通过循环不断尝试获取锁，直到成功为止。这种方式适用于锁竞争频繁但持有时间非常短的场景。在 Redisson 中，自旋锁并不是一个单独的类，而是可以通过设置来实现自旋方式的锁获取。某些版本中可能会单独命名为SpinLock。
Redisson分布式锁，重试锁和锁续命的原理
weixin_53604412的博客
04-28 3179
获取当前时间，线程ID，尝试获取锁，判断锁失效后自动释放的时间是否等于-1，如果不等于，就用自己的锁释放时间，如果等于-1，异步调用tryLockInnerAsync，返回值是个Future，第一个参数是等待时间，第二个参数是锁释放时间，看门狗的默认30秒，第三个是时间单位，第四个参数是线程ID，这个方法内是个lua脚本，成功返回空，是否返回过期时间；如果锁已经释放了，计算剩余等待时间，判断剩余等待时间>0，开始循环，就可以重新获取锁，和上面一样，如果失败，同时上，但这里用的是信号量。会在等待内不断重试；
2024年网络安全最全pygame学习(二)——绘制线条、圆、矩形等图案_pygame(1)，阿里P7亲自讲解
2401_84300255的博客
05-06 1110
需要完整版PDF学习资源私我sys.exit()#python的退出程序import pygame #导包import syspygame.init() #初始化#绘制一个600*600的框框。
基于go和redis实现分布式锁
10-14
本文将深入探讨如何使用Go语言（Golang）和Redis来实现分布式锁，并介绍其中涉及到的关键概念和实现方式，包括看门狗（Watchdog）和红锁（RedLock）策略。 **一、Redis作为分布式锁** Redis因其高性能、轻量级以及...
Springboot + Redis 分布式锁
weixin_42176639的博客
12-21 1544
Springboot 2.5.7 Redisson 3.16.6 分布式锁
深入理解Redis锁与Backoff重试机制在Go中的实现
tatasix的博客
10-15 1571
本文探讨了在Go语言中实现Redis锁及其与Backoff重试策略结合的重要性和方法。文章提供了Redis锁的获取和释放的实现代码，并强调了使用Lua脚本确保安全释放锁的重要性。同时，介绍了多种Backoff策略，如指数退避，以优化锁获取过程中的重试逻辑。结合Redis锁和Backoff策略，文章提出了一个健壮的锁获取机制，能够在高竞争环境下安全地获取锁。最后，文章强调了合理选择和调整这些策略对于提高分布式系统的性能和可靠性的重要性。
Redis分布式锁 + Spring原生定时任务
weixin_42230450的博客
02-28 463
前段时间，上手了一个新项目，项目中涉及到一些定时任务，常规的非单机项目的定时任务应该是要使用XXLJob或Quartz框架单独写一个定时任务服务来提供定时调度的能力，但项目新、时间赶、任务重，直接就用原生的Spring定时任务来顶上去了，主要的精力还是花在业务开发上，但后续问题就出来了。在开发环境时，由于只开启了本地服务，而测试环境只有一个节点，并没有发现这个问题，但服务发布到预生产环境，面对三个节点时，问题就暴露了：在到达定时任务的执行时间时，三个节点都会同时执行定时任务，导致了任务重复执行。
Redisson 源码解析系列二：分布式锁RedissonLock获取锁重试机制
Musclewl的博客
08-19 578
分布式锁RedissonLock获取锁重试机制
redis中的乐观锁的实现方式（代码）
荣山的博客
09-23 508
redis中的乐观锁的实现方式
Redis 篇-深入了解分布式锁 Redisson 原理（可重入原理、可重试原理、主从一致性原理、解决超时锁失效）
小扳手
09-08 5726
Redisson 是一个在 Redis 的基础上实现的 Java 驻内存数据网络。它不仅提供了一系列的分布式的 Java 常用对象，还提供了许多分布式服务，其中包含了各种分布式锁的实现。Redisson 解决了不可重入问题、不可重试问题、超时释放问题、主从一致性问题。比如说，分布式锁的可重入锁、公平锁、联锁、红锁等等。
面试官问：Redis 分布式锁如何自动续期？
技术专家
06-20 579
面试官问：Redis 分布式锁如何自动续期？
基于redis实现分布式锁的demo（循环重试）（比递归重试更好点）
荣山的博客
09-23 297
基于redis实现分布式锁的demo（循环重试）（比递归重试更好点）
Redisson分布式锁的可重入、重试、续约机制原理
Shadow_T的博客
03-05 5485
Redisson分布式锁的可重入、重试和看门狗机制的原理
【Redis】6、Redisson 分布式锁的简单使用（可重入、重试机制...）
m0_54189068的博客
07-19 3740
Redisson 的可重入锁原理、可重试原理
Redisson分布式锁：tryLock的源码解析重试机制以及其看门狗原理
Upup！
02-18 3124
Redisson分布式锁：tryLock的源码解析重试机制以及其看门狗原理
go语言 实现redis分布式锁
03-18
<think>好的，用户想了解如何用Go语言基于Redis实现分布式锁的最佳实践和示例代码。首先，我需要回忆一下分布式锁的基本概念和Redis的相关命令。记得Redis的SET命令加上NX和PX选项可以实现原子性的加锁操作，这样可以避免竞态条件。然后，解锁时需要确保只有锁的持有者才能释放锁，通常用Lua脚本来保证操作的原子性。 接下来，我需要考虑Go语言中的具体实现。用户可能希望看到具体的代码示例，比如使用github.com/go-redis/redis库来连接Redis，并编写加锁和解锁的函数。同时，还要处理锁的超时和自动续期问题，防止因为业务执行时间过长导致锁自动释放。此外，可重入锁可能也是一个需要考虑的高级特性，但根据引用内容，用户提供的引用中有提到可重入锁的实现，但可能用户更关注基础实现，所以可能需要先介绍基本方法，再提及可重入的扩展。 然后，引用中提到了redsync这个库，根据引用3，官方推荐使用redsync，所以可能需要介绍这个库的使用方法，并给出示例代码。同时，要比较手动实现和使用库的优缺点，比如redsync支持多Redis实例的RedLock算法，提高可靠性，而单实例实现更简单但可能有单点故障风险。 另外，需要确保回答覆盖最佳实践，比如设置合理的超时时间、避免长时间阻塞、处理网络分区等。还要注意错误处理，比如加锁失败后的重试策略，以及解锁时可能遇到的错误。 最后，根据用户提供的引用，特别是引用1、2、3，需要正确引用相关内容，比如引用1提到使用SET命令，引用2提到Lua脚本和可重入锁，引用3提到redsync库。因此，在回答中要自然地插入这些引用，确保信息的准确性和来源的可信度。 可能还需要生成相关问题，比如如何实现锁的可重入性，如何处理锁的自动续期，RedLock算法的原理等。这些问题可以帮助用户进一步深入学习。 总结步骤：介绍基本实现方法，给出代码示例；介绍redsync库的使用；讨论最佳实践和注意事项；引用相关资料；生成相关问题。</think>### Go语言基于Redis实现分布式锁的最佳实践 #### 一、基础实现方法（单Redis实例） 1. **加锁** 使用`SET`命令的`NX`（不存在时设置）和`PX`（过期时间）参数： ```go func AcquireLock(client *redis.Client, key string, value string, ttl time.Duration) (bool, error) { result, err := client.SetNX(context.Background(), key, value, ttl).Result() return result, err } ``` - `key`为锁的唯一标识，`value`通常为随机字符串（如UUID），用于安全释放锁[^1]。 2. **解锁** 使用Lua脚本保证原子性操作： ```lua if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end ``` Go代码实现： ```go func ReleaseLock(client *redis.Client, key string, value string) (bool, error) { script := redis.NewScript(` if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end `) result, err := script.Run(context.Background(), client, []string{key}, value).Int64() return result == 1, err } ``` **关键点**：验证`value`匹配后才删除锁，避免误删其他客户端的锁[^2]。 --- #### 二、使用Redsync库（推荐生产环境） Redis官方推荐的Go实现库`redsync`支持多节点容错（RedLock算法）： 1. **安装依赖** ```bash go get github.com/go-redsync/redsync/v4 go get github.com/gomodule/redigo/redis ``` 2. **示例代码** ```go package main import ( "github.com/gomodule/redigo/redis" "github.com/go-redsync/redsync/v4" "github.com/go-redsync/redsync/v4/redis/redigo" ) func main() { // 创建Redis连接池 pool := redigo.NewRedisPool(&redis.Pool{ Dial: func() (redis.Conn, error) { return redis.Dial("tcp", "localhost:6379") }, }) // 创建Redsync实例 rs := redsync.New(pool) // 获取锁 mutex := rs.NewMutex("my-distributed-lock", redsync.WithExpiry(10*time.Second)) if err := mutex.Lock(); err != nil { panic(err) } // 执行业务逻辑 // ... // 释放锁 if ok, err := mutex.Unlock(); !ok || err != nil { panic("unlock failed") } } ``` **优势**： - 自动处理锁续期（需配合`WithTries`配置重试） - 支持多Redis实例的RedLock算法（需传递多个连接池）[^3] --- #### 三、最佳实践 1. **设置合理的超时时间** 根据业务逻辑耗时设置`ttl`，避免锁长期未释放导致死锁。 2. **避免单点故障** 生产环境建议使用Redis集群或RedLock算法（多实例部署）。 3. **错误处理** - 加锁失败时实现重试机制（如指数退避） - 解锁失败需记录日志并人工介入检查 4. **锁续期** 对于长耗时任务，需后台定期续期： ```go func ExtendLock(mutex *redsync.Mutex) { go func() { for { select { case <-time.After(5 * time.Second): ok, err := mutex.Extend() if !ok || err != nil { return } } } }() } ``` --- #### 四、注意事项 - **网络分区问题**：Redis主从切换可能导致锁状态不一致，RedLock可缓解此问题 - **时钟同步**：多实例部署时需确保机器时钟同步 - **性能影响**：频繁加锁可能增加Redis负载，需监控QPS ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

徐同学呀

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值