redis分布式锁使用

方法一：利用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);
        }
    }

方法二：利用分布式锁命令 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() + "用户获得锁失败");
                }
            });
        }


    }

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

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

上述两种方式存在的问题

1. 单机，无法保证高可用
2. 主从，无法保证数据强一致性，会去从库重复获得锁
   
3. 无法续租，超过expireTime后，不能继续使用

根本原因分析

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

分布式锁的应用场景

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

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

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

zk分布式锁的使用案例

对比：该部分摘自知乎文章

对于 Redis 的分布式锁而言，它有以下缺点：

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

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

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

对于 ZK 分布式锁而言:

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

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

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

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

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

参数对比：

一个ap模型不适合强一致的场景 一个cp虽然适合，但是每次节点交互携带的数据会限制节点的数量。

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

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

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