IT俱乐部 Redis Redis分布式锁及4种常见实现方法

Redis分布式锁及4种常见实现方法

发布: 2024年 6月 11日 136阅读

线程锁

主要用来给方法、代码块加锁。当某个方法或代码使用锁，在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一JVM中有效果，因为线程锁的实现在根本上是依靠线程之间共享内存实现的，比如Synchronized、Lock等。

进程锁

控制同一操作系统中多个进程访问某个共享资源，因为进程具有独立性，各个进程无法访问其他进程的资源，因此无法通过synchronized等线程锁实现进程锁

什么是分布式锁

分布式锁：满足分布式系统或集群模式下多进程可见并且互斥的锁；一个方法在同一时间只能被一个机器的一个线程执行。

分布式锁应具备的条件

  • 多进程可见
  • 互斥
  • 高可用的获取锁与释放锁；
  • 高性能的获取锁与释放锁；
  • 具备锁失效机制，防止死锁；
  • 具备可重入特性；
  • 具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败；

分布式锁常见的实现方式

基于Mysql

在数据库中创建一个表，表中包含方法名等字段，并在方法名name字段上创建唯一索引，想要执行某个方法，就使用这个方法名向表中插入一条记录，成功插入则获取锁，删除对应的行就是锁释放。

CREATE TABLE `method_lock` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `method_name` varchar(64) NOT NULL COMMENT '锁定的方法名',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uidx_method_name` (`method_name`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COMMENT='锁定中的方法';

这里主要是用method_name字段作为唯一索引来实现，唯一索引保证了该记录的唯一性，锁释放就直接删掉该条记录就行了。

INSERT INTO method_lock (method_name) VALUES ('methodName');

delete from method_lock where method_name ='methodName';

缺点

1、因为是基于数据库实现的，数据库的可用性和性能将直接影响分布式锁的可用性及性能。高并发状态下，数据库读写效率一般都非常缓慢。所以，数据库需要双机部署、数据同步、主备切换；

2、不具备可重入的特性，因为同一个线程在释放锁之前，行数据一直存在，无法再次成功插入数据，所以，需要在表中新增一列，用于记录当前获取到锁的机器和线程信息，在再次获取锁的时候，先查询表中机器和线程信息是否和当前机器和线程相同，若相同则直接获取锁；

3、没有锁失效机制，因为有可能出现成功插入数据后，服务器宕机了，对应的数据没有被删除，当服务恢复后一直获取不到锁。所以，需要在表中新增一列，用于记录失效时间，并且需要有定时任务清除这些失效的数据；

4、不具备阻塞锁特性，获取不到锁直接返回失败，所以需要优化获取逻辑，循环多次去获取。

5、在实施的过程中会遇到各种不同的问题，为了解决这些问题，实现方式将会越来越复杂；依赖数据库需要一定的资源开销，性能问题需要考虑。

基于Redis分布式锁

获取锁

利用setnx这种互斥命令，利用锁超时时间进行到期释放避免死锁，且Redis具有高可用高性能等特点及优势。

Redis 的分布式锁， setnx 命令并设置过期时间就行吗？

setnx [key] [value] 
expire [key] 30

虽然setnx是原子性的，但是setnx + expire就不是了，也就是说setnx和expire是分两步执行的，【加锁和超时】两个操作是分开的，如果expire执行失败了，那么锁同样得不到释放。

获取锁的原子性问题

# 设置某个 key 的值并设置多少毫秒或秒 过期
set  PX  NX
或
set  EX  NX
# 设置一个键为lock，值为thread，ex表示以秒为单位，px以微秒为单位，nx表示不存在该key的时候才能设置
set lock thread1 nx ex 10

当且仅当key值lock不存在时，set一个key为lock，val为thread1的字符串，返回1；若key存在，则什么都不做，返回0。

Java的实现

	public boolean tryLock(long timeoutSec) {
        // 获取线程标识,ID_PREFIX为
        String threadId = ID_PREFIX +  Thread.currentThread().getId();
        // 获取锁,name为自定义的业务名称
        Boolean success = stringRedisTemplate.opsForValue().setIfAbsent(KEY_PREFIX + name, threadId, timeoutSec, TimeUnit.SECONDS);
        return Boolean.TRUE.equals(success);
    }

释放锁

  • 手动释放
# 将对应的键删除即可
del [key]
  • 超时释放

释放错误的锁

假设如下三个线程是同一个用户的业务线程，即假设线程1、线程2、线程3申请的分布式锁key一样：

  • 线程1获取成功了一个分布式锁，由于一些问题，线程1执行超时了，分布式锁被超期释放。
  • 在锁释放后，有一个线程2又来获取锁，并且成功。
  • 在线程2执行过程中，线程1运行结束，由于不知道自己锁已经被超期释放，所以它直接手动释放锁，错误的释放了线程2的锁。
  • 这时如果又有一个线程3前来获取锁，就能获取成功；而线程2此时也持有锁。

所以，设置锁的过期时间时，还需要设置唯一编号。在编程实现释放锁的时候，需要判断当前释放的锁的值是否与之前的一致;若一致，则删除；不一致，则不操作。

代码示例：

	public void unlock() {
        // 获取线程标识
        String threadId = ID_PREFIX +  Thread.currentThread().getId();
        // 获取锁中的标识
        String id = stringRedisTemplate.opsForValue().get(KEY_PREFIX + name);
        // 判断标识是否一致
        if (threadId.equals(id)) {
            // 释放锁
            stringRedisTemplate.delete(KEY_PREFIX + name);
        }
    }

删除锁的原子性问题

  • 线程1在时限内完成了业务，它开始执行删除锁的操作。
  • 线程1判断完当前锁的标识(对应的value)一样后，由于一些问题，线程1被阻塞，该key超期被删除了
  • 线程2过来申请分布式锁，并且成功
  • 此时，线程1才正式对分布式锁执行删除，由于可能是同一个用户的业务线程，线程1与线程2的申请的分布式锁key一样，所以线程1调用的删除锁操作将线程2的锁删掉了（悲！故技重施！）…

所以，我们还得确保获取和删除操作之间的原子性。可以借助Lua脚本保证原子性，释放锁的核心逻辑【GET、判断、DEL】，写成 Lua 脚本，让Redis调用。

使用Lua脚本改进Redis释放分布式锁

Lua中Redis的调用函数

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

比如我们执行set name jack命令，可以使用:

redis.call('set','name','jack')

使用Redis调用Lua脚本

调用方法

# script脚本语句；numkeys脚本需要的key类型的参数个数
eval script numkeys key [key ...] arg [arg ...]

例如，执行redis.call('set', 'name', 'Jack')脚本设置redis键值，语法如下：

eval "return redis.call('set', 'name', 'Jack')" 0

如果key和value不想写死，可以使用如下格式

eval "return redis.call('set', KEYS[1], ARGV[1])" 1 name Jack

Lua中，数组下标从1开始，此处1标识只有一个key类型的参数，其他参数都会放入ARGV数组。在脚本中，可以通过KEYS数组和ARGV数组获取参数

Lua脚本（unlock.lua）

if(redis.call('get', KEYS[1]) == ARGV[1]) then
    return redis.call('del', KEYS[1])
end
return 0

参考完整代码

import cn.hutool.core.lang.UUID;
import org.springframework.core.io.ClassPathResource;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.data.redis.core.script.DefaultRedisScript;

import java.util.Collections;
import java.util.concurrent.TimeUnit;

public class SimpleRedisLock {
    private String name;
    private StringRedisTemplate stringRedisTemplate;
    private static final String KEY_PREFIX = "lock:";
    private static final String ID_PREFIX = UUID.randomUUID().toString(true) + "-";
    // 加载脚本
    private static final DefaultRedisScript UNLOCK_SCRIPT;

    static {
        UNLOCK_SCRIPT = new DefaultRedisScript();
        // 加载工程resourcecs下的unlock.lua文件
        UNLOCK_SCRIPT.setLocation(new ClassPathResource("unlock.lua"));
        UNLOCK_SCRIPT.setResultType(Long.class);
    }
    public SimpleRedisLock(String name, StringRedisTemplate stringRedisTemplate) {
        this.name = name;
        this.stringRedisTemplate = stringRedisTemplate;
    }
    
    public boolean tryLock(long timeoutSec) {
        // 获取线程标识
        String threadId = ID_PREFIX +  Thread.currentThread().getId();
        // 获取锁
        Boolean success = stringRedisTemplate.opsForValue().setIfAbsent(KEY_PREFIX + name, threadId, timeoutSec, TimeUnit.SECONDS);
        return Boolean.TRUE.equals(success);
    }

    public void unlock() {
        // 调用Lua脚本
        stringRedisTemplate.execute(UNLOCK_SCRIPT,
                Collections.singletonList(KEY_PREFIX + name),
                ID_PREFIX +  Thread.currentThread().getId());
    }
}

业务调用使用方法

	/**
	* 业务service导入
	*/
	@Resource
    private RedissonClient redissonClient;

	/** 
	* 业务方法内
	*/
	SimpleRedisLock lock = new SimpleRedisLock("order:" + userId, stringRedisTemplate);
	// 创建锁对象
    RLock lock = redissonClient.getLock("lock:order:" + userId);
    // 尝试获取锁
    boolean isLock = lock.tryLock();
    // 判断是否成功
    if (!isLock) {
    	// 获取失败
        return Result.fail("不允许重复下单");
    }
	try {
    	// 需要锁执行的业务代码部分
    } finally {
        // 释放锁
        lock.unlock();
    }

当前还存在的问题

  • 不可重入：同一个线程无法多次获取同一把锁(线程1在执行方法1的时候调用了方法2，而方法2也需要锁)
  • 不可重试：获取锁只尝试一次就返回false，没有重试机制；当前直接返回结果。
  • 超时释放：锁超时释放虽然可以避免死锁，但是如果业务执行耗时较长，也会导致锁释放，存在安全隐患。
  • 主从一致性：如果redis提供了主从集群，主存同步存在延迟。当主结点宕机时，从节点尚未同步主结点锁数据，则会造成锁失效。

Redisson框架中就实现了WatchDog（看门狗），加锁时没有指定加锁时间时会启用 watchdog 机制，默认加锁 30 秒，每 10 秒钟检查一次，如果存在就重新设置过期时间。

RedLock应对主从一致性问题

Redis 的作者提出一种解决方案 Redlock ，基于多个 Redis 节点，不再需要部署从库和哨兵实例，只部署主库。但主库要部署多个，官方推荐至少 5 个实例。

流程：

  • Client先获取「当前时间戳T1」

  • Client依次向这 5 个 Redis 实例发起加锁请求（用前面讲到的 SET 命令），且每个请求会设置超时时间（毫秒级，要远小于锁的有效时间），如果某一个实例加锁失败（包括网络超时、锁被其它人持有等各种异常情况），就立即向下一个 Redis 实例申请加锁

  • 如果Client从 >=3 个（大多数）以上 Redis 实例加锁成功，则再次获取「当前时间戳T2」，如果 T2 – T1

  • 加锁成功，去操作共享资源（例如修改 MySQL 某一行，或发起一个 API 请求）

  • 加锁失败，Client向「全部节点」发起释放锁请求（前面讲到的 Lua 脚本释放锁）

为什么要向多个Redis申请锁？

向多台Redis申请锁，即使部分服务器异常宕机，剩余的Redis加锁成功，整个锁服务依旧可用。

为什么步骤 3 加锁成功后，还要计算加锁的累计耗时？

加锁操作的针对的是分布式中的多个节点，所以耗时肯定是比单个实例耗时更，还要考虑网络延迟、丢包、超时等情况发生，网络请求次数越多，异常的概率越大。
所以即使 N/2+1 个节点加锁成功，但如果加锁的累计耗时已经超过了锁的过期时间，那么此时的锁已经没有意义了

释放锁操作为什么要针对所有结点？

为了清除干净所有的锁。在之前申请锁的操作过程中，锁虽然已经加在Redis上，但是在获取结果的时候，出现网络等方面的问题，导致显示失败。所以在释放锁的时候，不管以前有没有加锁成功，都要释放所有节点相关锁。

Zookeeper

ZooKeeper 的数据存储结构就像一棵树，这棵树由节点组成，这种节点叫做 Znode。

  • Client尝试创建一个 znode 节点，比如/lock，比如Client1先到达就创建成功了，相当于拿到了锁

  • 其它的客户端会创建失败（znode 已存在），获取锁失败。

  • Client2可以进入一种等待状态，等待当/lock 节点被删除的时候，ZooKeeper 通过 watch 机制通知它

  • 持有锁的Client1访问共享资源完成后，将 znode 删掉，锁释放掉了

  • Client2继续完成获取锁操作，直到获取到锁为止

ZooKeeper不需要考虑过期时间，而是用【临时节点】，Client拿到锁之后，只要连接不断，就会一直持有锁。即使Client崩溃，相应临时节点Znode也会自动删除，保证了锁释放。

Zookeeper 是检测客户端是否崩溃

每个客户端都与 ZooKeeper 维护着一个 Session，这个 Session 依赖定期的心跳(heartbeat)来维持。

如果 Zookeeper 长时间收不到客户端的心跳，就认为这个 Session 过期了，也会把这个临时节点删除。

当然这也并不是完美的解决方案

以下场景中Client1和Client2在窗口时间内可能同时获得锁：

  • Client 1 创建了 znode 节点/lock，获得了锁。

  • Client 1 进入了长时间的 GC pause。（或者网络出现问题、或者 zk 服务检测心跳线程出现问题等等）

  • Client 1 连接到 ZooKeeper 的 Session 过期了。znode 节点/lock 被自动删除。

  • Client 2 创建了 znode 节点/lock，从而获得了锁。

  • Client 1 从 GC pause 中恢复过来，它仍然认为自己持有锁。

Zookeeper 的优点

  • 不需要考虑锁的过期时间，使用起来比较方便

  • watch 机制，加锁失败，可以 watch 等待锁释放，实现乐观锁

Zookeeper 的缺点

  • 性能不如 Redis

  • 部署和运维成本高

  • 客户端与 Zookeeper 的长时间失联，锁被释放问题

Etcd

Etcd是一个Go语言实现的非常可靠的kv存储系统，常在分布式系统中存储着关键的数据，通常应用在配置中心、服务发现与注册、分布式锁等场景。

Etcd特性

  • Lease机制：即租约机制(TTL,Time To Live)，etcd可以为存储的kv对设置租约，当租约到期，kv将失效删除；同时也支持续约，keepalive
  • Revision机制：每个key带有一个Revision属性值，etcd每进行一次事务对应的全局Revision值都会+1，因此每个key对应的Revision属性值都是全局唯一的。通过比较Revision的大小就可以知道进行写操作的顺序
  • 在实现分布式锁时，多个程序同时抢锁，根据Revision值大小依次获得锁，避免“惊群效应”，实现公平锁
  • Prefix机制：也称为目录机制，可以根据前缀获得该目录下所有的key及其对应的属性值
  • Watch机制：watch支持watch某个固定的key或者一个前缀目录，当watch的key发生变化，客户端将收到通知

满足分布式锁的特性：

  • 租约机制(Lease)：用于支撑异常情况下的锁自动释放能力
  • 前缀和 Revision 机制：用于支撑公平获取锁和排队等待的能力
  • 监听机制(Watch)：用于支撑抢锁能力
  • 集群模式：用于支撑锁服务的高可用
func main() {
    config := clientv3.Config{
        Endpoints:   []string{"xxx.xxx.xxx.xxx:2379"},
        DialTimeout: 5 * time.Second,
    }
 
    // 获取客户端连接
    client, err := clientv3.New(config)
    if err != nil {
        fmt.Println(err)
        return
    }
 
    // 1. 上锁（创建租约，自动续租，拿着租约去抢占一个key ）
    // 用于申请租约
    lease := clientv3.NewLease(client)
 
    // 申请一个10s的租约
    leaseGrantResp, err := lease.Grant(context.TODO(), 10) //10s
    if err != nil {
        fmt.Println(err)
        return
    }
 
    // 拿到租约的id
    leaseID := leaseGrantResp.ID
 
    // 准备一个用于取消续租的context
    ctx, cancelFunc := context.WithCancel(context.TODO())
 
    // 确保函数退出后，自动续租会停止
    defer cancelFunc()
        // 确保函数退出后，租约会失效
    defer lease.Revoke(context.TODO(), leaseID)
 
    // 自动续租
    keepRespChan, err := lease.KeepAlive(ctx, leaseID)
    if err != nil {
        fmt.Println(err)
        return
    }
 
    // 处理续租应答的协程
    go func() {
        select {
        case keepResp :=

clientv3提供的concurrency包也实现了分布式锁

  • 首先concurrency.NewSession方法创建Session对象
  • 然后Session对象通过concurrency.NewMutex 创建了一个Mutex对象
  • 加锁和释放锁分别调用Lock和UnLock

笔记Zookeeper和Etcd部分参考：https://mp.weixin.qq.com/s/wL9MRnx8HVXNFOt6ZTWELw

到此这篇关于Redis分布式锁及4种常见实现方法的文章就介绍到这了,更多相关Redis分布式锁内容请搜索IT俱乐部以前的文章或继续浏览下面的相关文章希望大家以后多多支持IT俱乐部！

本文收集自网络，不代表IT俱乐部立场，转载请注明出处。https://www.2it.club/database/redis/12085.html
27赞
标签:
上一篇
下一篇

相关推荐

联系我们

联系我们

在线咨询: QQ交谈

邮箱: 1120393934@qq.com

工作时间：周一至周五，9:00-17:30，节假日休息

关注微信
微信扫一扫关注我们

微信扫一扫关注我们

返回顶部