教你如何使用redis分布式锁

一、redis客户端实现

应用

1.利用set nx命令实现分布式锁

    Jedis jedis = new Jedis("127.0.0.1", 6309);

    public boolean getLock(String lockKey, String requestId, int expireTime) {
        //NX:保证互斥性
        //hset 原子性操作 只要lockKey有效 则说明有进程在使用分布式锁
        // key:lockKey  value:requestId NX:仅在键不存在时设置键 EX:设置指定的到期时间(以秒为单位)
        String result = jedis.set(lockKey, requestId, "NX", "EX", expireTime);
        if ("OK".equals(result)) {
            return true;
        }
        return false;
    }

    /**
     * 释放分布式锁
     * @param lockKey
     * @param requestId
     */
    public void releaseLock(String lockKey,String requestId) {
        if (requestId.equals(jedis.get(lockKey))) {
            jedis.del(lockKey);
        }
    }

2.利用分布式锁命令 setnx

    public static boolean getLock2(Jedis jedis, String lockKey, String requestId, int expireTime) {
        Long result = jedis.setnx(lockKey, requestId);
        //成功设置 进程down 永久有效 别的进程就无法获得锁
        if(result == 1) {
            jedis.expire(lockKey, expireTime);
            return true;
        }
        return false;
    }

    public static boolean releaseLock2(Jedis jedis, String lockKey, String requestId) {
        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        
        Object result = jedis.eval(script, Collections.singletonList(lockKey),
                Collections.singletonList(requestId));
        if (result.equals(1L)) {
            return true;
        }
        return false;
    }
    public static void main(String[] args) {
        String redisLock = "my_lock";
        ExecutorService executorService = Executors.newFixedThreadPool(10);
        for (int i = 0; i <100; i++){
            executorService.execute(() -> {
                Jedis jedis = new Jedis("127.0.0.1", 6379);
                UUID uuid = UUID.randomUUID();
                System.out.println(uuid.toString() + "用户进来");
                boolean isLock = getLock2(jedis, redisLock, uuid.toString(), 30000);
                if (isLock){
                    System.out.println(uuid.toString() + "用户尝试获得锁成功!");
                    releaseLock2(jedis, redisLock, uuid.toString());
                    System.out.println(uuid.toString() + "用户释放锁");
                }else{
                    System.out.println(uuid.toString() + "用户获得锁失败");
                }
            });
        }


    }

在这里插入图片描述

问题

1.为什么不直接调用jedis.del(key)方法而采用redis+lua实现?

由于jedis.del(key)方法是删除当前key不会区别当前是哪个客户端,而采用redis+lua方式只有当前获得锁的客户端才有资格删除。例如,线程A获得分布式锁,线程B调用jedis.del(key)方法会把线程A的锁删除掉。

2.上述两种方式存在的问题?

  1. 单机,无法保证高可用
  2. 主从,无法保证数据强一致性,会去从库重复获得锁
    在这里插入图片描述
  3. 无法续租,超过expireTime后,不能继续使用

3.根本原因分析

CAP(Consistent一致性、Available可用性、Partition分区)原则,三者只能选其二,因此在分布式场景下p不能舍弃,那么只能是AP、CP原则。

二、分布式场景Redission分布式锁的使用

Redisson是架设在Redis基础上的一个java驻内存数据网格。
Redission在基于NIO的Netty框架上,生成环境使用分布式锁。

数据网格:是将空间上不均匀分布的数据,按一定方法(如滑动平均法、克里格法或其他适当的数值推算方法)归算成规则网格中的代表值(趋势值)的过程

Redis集群至少需要3个master节点,所以现在总共有6个节点,就只能是1master对应1slave这种方式,1master-2slave,redis集群需要9个节点,以此类推。

配置代码:

package com.learn.cache;

import org.redisson.Redisson;
import org.redisson.config.Config;

public class RedissonManager {

    private static Config config = new Config();

    private static Redisson redisson = null;


    static {
        config.useClusterServers()
                //集群状态扫描间隔时间,单位是毫秒
                .setScanInterval(2000)
                .addNodeAddress("redis://127.0.0.1:7001")
                .addNodeAddress("redis://127.0.0.1:7002")
                .addNodeAddress("redis://127.0.0.1:7003")
                .addNodeAddress("redis://127.0.0.1:7004")
                .addNodeAddress("redis://127.0.0.1:7005")
                .addNodeAddress("redis://127.0.0.1:7006");


        redisson = (Redisson) Redisson.create(config);
    }

    public static Redisson getRedisson() {
        return redisson;
    }

}

使用demo:

package com.learn.cache;

import org.redisson.Redisson;
import org.redisson.api.RLock;

import java.util.UUID;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

import static java.util.concurrent.TimeUnit.SECONDS;

public class DistributedRedisLock {
    private static final String LOCK_TITLE = "redisLock_";
    //从配置类中获取redisson对象
    private static Redisson redisson = RedissonManager.getRedisson();

    //加锁
    public static boolean acquire(String lockName) {
        //声明key对象
        String key = LOCK_TITLE + lockName;
        //获取锁对象
        RLock mylock = redisson.getLock(key);
        //加锁,并且设置锁过期时间3秒,防止死锁的产生 uuid+threadId
        mylock.lock(3, SECONDS);
        //加锁成功
        return true;
    }

    //锁的释放
    public static void release(String lockName) {
        //必须是和加锁时的同一个key
        String key = LOCK_TITLE + lockName;
        //获取所对象
        RLock mylock = redisson.getLock(key);
        //释放锁(解锁)
        mylock.unlock();
    }


    public static void main(String[] args) {
        String key = "lock001";
        ExecutorService executorService = Executors.newFixedThreadPool(20);
        for (int i = 0; i < 100; i++){
            executorService.execute(() -> {
                //加锁
                boolean acquire = acquire(key);
                String uuid = UUID.randomUUID().toString();
                if (acquire){
                    System.out.println(uuid + "用户获得锁成功");
                    release(key);
                    System.out.println(uuid + "用户释放锁");

                }else{
                    System.out.println(uuid + "用户获得锁失败");
                }
            });
        }

    }


}

1.分布式锁的特性

  1. 互斥性:任意时刻保持只能有一个客户端获得锁
  2. 同一性:锁只能被同一个客户端删除,不能被其他客户端删除,同上jedis.setnx(key)不能利用jedis.del(key)删除
  3. 可重入性:持有该锁的客户端可重复获得锁
  4. 容错性:锁对象由于服务挂掉,会自动释放锁,防止死锁

2.分布式锁的应用场景

  1. 抢红包、秒杀下单场景等,由于红包、库存的数量是确定的,如果此时同时有多个用户抢红包、下订单,此时如果不利用分布式锁处理的话,那么会出现并发问题。
  2. 详细应用场景可参考: 文章

三、zookeeper分布式锁和redis分布式的区别

彻底讲清楚ZooKeeper分布式锁的实现原理

zk分布式锁的使用案例

1.对于 Redis 的分布式锁而言,它有以下缺点:

  1. 它获取锁的方式简单粗暴,获取不到锁直接不断尝试获取锁,比较消耗性能。
  2. 另外来说的话,Redis的设计定位决定了它的数据并不是强一致性的,在某些极端情况下,可能会出现问题。锁的模型不够健壮。 即便使用 Redlock算法来实现,在某些复杂场景下,也无法保证其实现 100% 没有问题,关于 Redlock 的讨论可以看 How to do distributed locking。

但是另一方面使用 Redis 实现分布式锁在很多企业中非常常见,而且大部分情况下都不会遇到所谓的“极端复杂场景”。

所以使用 Redis 作为分布式锁也不失为一种好的方案,最重要的一点是 Redis 的性能很高,可以支撑高并发的获取、释放锁操作。

2.对于 ZK 分布式锁而言:

ZK 天生设计定位就是分布式协调,强一致性。锁的模型健壮、简单易用、适合做分布式锁。
如果获取不到锁,只需要添加一个监听器就可以了,不用一直轮询,性能消耗较小。

但是 ZK 也有其缺点:如果有较多的客户端频繁的申请加锁、释放锁,对于 ZK 集群的压力会比较大

3.使用建议

就个人而言的话,我比较推崇 ZK 实现的锁:因为 Redis 是有可能存在隐患的,可能会导致数据不对的情况。但是,怎么选用要看具体在公司的场景了。

如果有 ZK 集群条件,优先选用 ZK 实现,但是如果说公司里面只有 Redis 集群,没有条件搭建 ZK 集群。

那么其实用 Redis 来实现也可以,另外还可能是系统设计者考虑到了系统已经有 Redis,但是又不希望再次引入一些外部依赖的情况下,可以选用 Redis。这个是要系统设计者基于架构来考虑了。

4.参数对比

在这里插入图片描述
一个ap模型不适合强一致的场景 一个cp虽然适合,但是每次节点交互携带的数据会限制节点的数量。

zk写都在leader,不适合做高并发的分布式锁。

数据库实现分布式锁,性能太差。

具体采用何种,还需要根据自身业务场景去选择 !!!

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值