什么是分布式锁

分布式锁是一种用于在分布式系统中控制对共享资源的访问的锁。它与传统的单机锁不同，因为它需要在多个节点之间协调以确保互斥访问。

分布式锁的一些特点包括：

• 依赖于外部存储系统：分布式锁需要依赖于一个外部的存储系统来实现锁的状态共享。例如，可以使用Redis、ZooKeeper或数据库来实现分布式锁。
• 容错性：分布式锁需要具有容错性，以便在发生故障时能够快速恢复。
• 高可用性：分布式锁需要具有高可用性，以避免对业务造成影响。
• 跨进程：分布式锁可以跨越多个进程或节点，以实现对共享资源的互斥访问。

接下来锁它的使用：

• 一：SETNX + EXPIRE
• 二：使用Lua脚本(包含SETNX + EXPIRE两条指令)
• 三：SET的扩展命令（SET EX PX NX）
• 四: 开源框架~Redisson
• 五：多机实现的分布式锁Redlock红锁

方案一：SETNX+EXPIRE

在早期的Redis版本中，可以使用SETNX和EXPIRE命令来实现分布式锁。具体操作如下：

1. 使用SETNX命令创建一个锁。SETNX命令会尝试设置一个key，如果key不存在，那么设置成功并返回1，如果key已存在，那么设置失败并返回0。例如，我们可以尝试获取一个名为"lock"的锁，可以使用如下命令： SETNX lock 1
2. 如果上一步设置成功，那么表示我们已经获取到了锁。为了防止锁无法被释放，我们需要为锁设置一个超时时间，可以使用EXPIRE命令： EXPIRE lock 30
   这个命令会设置"lock"这个key在30秒后过期。这样就避免了因为持有锁的进程崩溃导致的锁无法释放的问题。
3. 当我们不再需要锁的时候，可以使用DEL命令来删除这个锁： DEL lock

然而，这种方式有一个问题，那就是SETNX和EXPIRE两个操作并不是原子的。如果在这两个操作之间，进程崩溃，那么可能会出现永久的锁，也就是说，锁被设置了，但是没有设置超时时间，所以这个锁会一直存在，导致其他进程无法获取到锁。

为了解决这个问题，从Redis 2.6.12版本开始，Redis提供了一种新的命令，可以在设置key的同时设置超时时间，这个命令是SET，如下：

SET lock 1 NX PX 30000

这个命令在设置key的同时，设置了超时时间，这两个操作是原子的，所以不会出现上述问题。

NX和PX是Redis的SET命令的可选参数，它们可以用来实现分布式锁的功能。NX表示只在键不存在时才设置值，相当于SETNX命令；PX表示设置键的过期时间为毫秒数，相当于PSETEX命令。结合使用NX和PX参数，可以保证锁的互斥性和活跃性。

方案二：使用Lua脚本(包含SETNX + EXPIRE两条指令)

在Redis中，你可以使用Lua脚本将SETNX和EXPIRE两个操作打包在一起，从而实现原子性。以下是一个使用Lua脚本实现的例子：

local key = KEYS[1]
local value = ARGV[1]
local ttl = ARGV[2]

local lockSet = redis.call('setnx', key, value)
if lockSet == 1 then
    redis.call('expire', key, ttl)
end

return lockSet

这段Lua脚本执行以下操作：

1. 尝试使用SETNX命令设置一个锁。如果锁已经存在，那么SETNX命令会返回0，如果锁不存在，那么SETNX命令会返回1，并且设置锁的值为value。
2. 如果上一步设置锁成功（即SETNX命令返回1），那么使用EXPIRE命令设置锁的过期时间。过期时间是ttl。
3. 最后，返回SETNX命令的结果。如果结果为1，那么表示成功获取到了锁，如果结果为0，那么表示获取锁失败。

在Redis客户端中，你可以这样调用这个Lua脚本：

EVAL <lua_script> 1 lock_key lock_value lock_ttl

其中，<lua_script>是上述Lua脚本，1是键的数量，lock_key是锁的键，lock_value是锁的值，lock_ttl是锁的过期时间。

这样，SETNX和EXPIRE两个操作就成为了一个原子操作，不会出现在两个操作之间进程崩溃导致的问题。

方案三：SET的扩展命令（SET EX PX NX）

Redis的SET命令在2.6.12及更高版本中被扩展，可以接收更多的参数，这些参数可以设置key的过期时间和当key不存在时才进行设置的条件，这就为我们实现分布式锁提供了便利。

SET命令的使用格式如下：

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

这些选项的含义如下：

• EX seconds：设置键的过期时间为seconds秒。Redis会自动删除过期的key。
• PX milliseconds：设置键的过期时间为milliseconds毫秒。这是EX的另一种形式，允许你以更精细的时间粒度设置过期时间。
• NX：只在键不存在时，才对键进行设置操作。SETNX命令的功能就是这个选项提供的。
• XX：只在键已经存在时，才对键进行设置操作。

因此，你可以用以下命令在Redis中实现一个分布式锁：

SET lock_key lock_value PX 30000 NX

这个命令尝试设置一个名为lock_key的锁，锁的值是lock_value，过期时间是30000毫秒（30秒），只有当lock_key不存在时（即没有其他进程持有锁），才会设置成功。如果设置成功，命令返回"OK"，你就可以进行需要同步的操作了。如果设置失败，命令返回nil，你就知道你没有获取到锁。

这个命令将获取锁、设置锁的值和设置锁的过期时间这三个操作打包在一起，作为一个原子操作，从而避免了在这些操作之间进程崩溃可能导致的问题。

方案四：开源框架~Redisson

Redisson是一个在Java中实现的Redis客户端，它提供了很多高级功能，包括分布式锁，信号量，队列等等。

在Redisson中，你可以很方便地使用分布式锁。以下是一个例子：

import org.redisson.Redisson;
import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;

public class RedissonLockExample {

    public static void main(String[] args) throws Exception {
        // 创建RedissonClient实例
        Config config = new Config();
        config.useSingleServer().setAddress("redis://127.0.0.1:6379");
        RedissonClient redisson = Redisson.create(config);

        // 获取锁
        RLock lock = redisson.getLock("myLock");
        
        // 上锁，同时设置锁过期时间为10秒，防止死锁
        lock.lock(10, TimeUnit.SECONDS);

        // 执行需要同步的业务代码
        // ...

        // 释放锁
        lock.unlock();

        // 关闭RedissonClient
        redisson.shutdown();
    }
}

Redisson的分布式锁实现了JDK的java.util.concurrent.locks.Lock接口，因此它可以作为Java的标准Lock对象来使用，这使得使用Redisson非常方便。

方案五：多机实现的分布式锁Redlock红锁

为什么要多机实现分布式锁?

1. 容错性：如果使用单个Redis节点实现分布式锁，那么当这个节点宕机时，就无法使用锁了。而Redlock算法使用多个Redis节点，只要大多数节点是可用的，就可以正常使用锁。这提高了系统的可用性。
2. 安全性：在某些情况下，使用单个Redis节点实现的分布式锁可能出现安全问题。例如，如果在获取锁和设置锁过期时间之间，进程崩溃了，那么可能出现锁永远无法释放的情况。虽然可以通过Lua脚本或者SET命令的扩展参数解决这个问题，但是在网络分区等复杂情况下，还可能存在其他安全问题。而Redlock算法考虑了这些问题，提供了更为安全的保障。

使用：

public static void main(String[] args) throws Exception {
    // 创建RedissonClient实例
    Config config1 = new Config();
    config1.useSingleServer().setAddress("redis://127.0.0.1:6379");
    RedissonClient redisson1 = Redisson.create(config1);

    Config config2 = new Config();
    config2.useSingleServer().setAddress("redis://127.0.0.1:6380");
    RedissonClient redisson2 = Redisson.create(config2);

    Config config3 = new Config();
    config3.useSingleServer().setAddress("redis://127.0.0.1:6381");
    RedissonClient redisson3 = Redisson.create(config3);

    // 创建Redlock
    RLock lock1 = redisson1.getLock("lockKey");
    RLock lock2 = redisson2.getLock("lockKey");
    RLock lock3 = redisson3.getLock("lockKey");
    RedissonRedLock redLock = new RedissonRedLock(lock1, lock2, lock3);

    // 尝试获取锁，同时设置锁过期时间为10秒，防止死锁
    if (redLock.tryLock(10, 10, TimeUnit.SECONDS)) {
        try {
            // 执行需要同步的业务代码
            // ...
        } finally {
            // 释放锁
            redLock.unlock();
        }
    }

    // 关闭RedissonClient
    redisson1.shutdown();
    redisson2.shutdown();
    redisson3.shutdown();
}

难道这就完了么?

红锁存在的问题

红锁它通过在多个独立的 Redis 节点上同时执行 setnx 操作来实现加锁。如果大多数节点都加锁成功，那么整个红锁就算加锁成功。也就是说，如果成功设置锁的实例数 >= N/2 + 1，那么加锁成功 。

1、它不像zk有崩溃恢复，所以会产生脑裂，比如有五个节点A、B、C、D、E，线程1成功上锁了A、B、C，线程一成功加上了锁，现在节点C崩溃，线程二来了，那么他也能加上锁

2、红锁算法依赖于时间来计算锁的超时时间。如果存在时钟漂移，可能会导致锁的超时时间计算错误，从而影响到锁的正确性。例如，如果某个节点的时钟比其他节点快，那么它可能会认为锁已经超时并释放锁，而其他节点仍然认为锁是有效的。这种情况下，可能会出现多个客户端同时持有锁的情况。