Redis分布式锁

1. 基于 SETNX 命令实现简单的分布式锁

   • SETNX 命令原理：SETNX（SET if Not eXists）是 Redis 中的一个原子操作命令。它的作用是在指定的键不存在时，设置键的值。可以利用这个特性来实现分布式锁。当一个客户端想要获取锁时，它尝试使用 SETNX 命令设置一个特定的键（例如，名为 “lock_key”），如果设置成功（返回 1），表示该客户端获取到了锁；如果键已经存在（返回 0），则表示锁已经被其他客户端获取，该客户端需要等待或者重试。
   • 示例代码（以 Python 和 Redis - Py 为例）：

     import redis
     import time

     # 连接Redis
     r = redis.Redis(host='localhost', port=6379, db=0)

     # 尝试获取锁
     lock_key = "my_lock"
     lock_value = "my_lock_value"
     lock_acquired = r.setnx(lock_key, lock_value)
     if lock_acquired:
         print("获取到锁")
         # 执行业务逻辑
         time.sleep(5)
         # 释放锁
         r.delete(lock_key)
         print("释放锁")
     else:
         print("未获取到锁")

• 缺点和问题：
  • 死锁风险：如果获取锁的客户端在执行业务逻辑过程中出现故障（如程序崩溃、网络中断等），没有来得及释放锁，就会导致其他客户端一直无法获取锁，产生死锁。
  • 锁过期问题：没有自动的过期机制，在一些复杂的场景下，如果业务逻辑执行时间过长，可能会导致锁一直被占用，影响系统的正常运行。

1. 使用 SET 命令的扩展参数实现带有过期时间的分布式锁

   • SET 命令改进：Redis 的 SET 命令在较新版本中有了一些扩展参数，其中包括可以在设置键值的同时设置过期时间，并且这个操作是原子的。例如，SET key value NX PX milliseconds，其中 “NX” 表示只有当键不存在时才设置，“PX” 表示设置过期时间（以毫秒为单位）。这样可以有效避免死锁和锁过期问题。
   • 示例代码（以 Java 和 Jedis 为例）：

     import redis.clients.jedis.Jedis;
     import java.util.concurrent.TimeUnit;

     public class RedisDistributedLock {
         private static final String LOCK_KEY = "my_lock";
         private static final String LOCK_VALUE = "my_lock_value";
         private static final int LOCK_EXPIRE_TIME_MS = 5000;

         public static void main(String[] args) {
             Jedis jedis = new Jedis("localhost", 6379);
             String result = jedis.set(LOCK_KEY, LOCK_VALUE, "NX", "PX", LOCK_EXPIRE_TIME_MS);
             if ("OK".equals(result)) {
                 System.out.println("获取到锁");
                 try {
                     // 执行业务逻辑
                     Thread.sleep(4000);
                 } catch (InterruptedException e) {
                     e.printStackTrace();
                 } finally {
                     // 释放锁（简单地删除键）
                     jedis.del(LOCK_KEY);
                     System.out.println("释放锁");
                 }
             } else {
                 System.out.println("未获取到锁");
             }
             jedis.close();
         }
     }

• 可能的问题及解决方法：
  • 误删锁问题：在上述代码中，虽然设置了锁的过期时间，但如果业务逻辑执行时间超过了过期时间，锁可能会自动释放，而其他客户端获取了锁。当原来的客户端执行完业务逻辑后，会错误地删除其他客户端获取的锁。为了解决这个问题，可以在每个客户端设置锁时，为锁的值设置一个唯一标识（如客户端 ID + 时间戳），在释放锁时，先判断锁的值是否是自己设置的，如果是则删除，否则不删除。

1. 使用 Redisson 实现分布式锁（更高级的解决方案）

   • Redisson 简介：Redisson 是一个在 Redis 的基础上实现的 Java 驻内存数据网格（In - Memory Data Grid）。它提供了一系列分布式对象和服务，其中分布式锁是一个重要的功能。Redisson 的分布式锁实现了可重入锁、公平锁等特性，并且具有更高的可靠性和易用性。
   • 示例代码（以 Java 为例）：

     import org.redisson.Redisson;
     import org.redisson.api.RLock;
     import org.redisson.api.RedissonClient;
     import org.redisson.config.Config;
     import java.util.concurrent.TimeUnit;

     public class RedissonLockExample {
         public static void main(String[] args) {
             // 配置Redisson
             Config config = new Config();
             config.useSingleServer().setAddress("redis://localhost:6379");
             RedissonClient redisson = Redisson.create(config);

             // 获取锁
             RLock lock = redisson.getLock("my_lock");
             try {
                 if (lock.tryLock(5, TimeUnit.SECONDS)) {
                     System.out.println("获取到锁");
                     // 执行业务逻辑
                     Thread.sleep(4000);
                 } else {
                     System.out.println("未获取到锁");
                 }
             } catch (InterruptedException e) {
                 e.printStackTrace();
             } finally {
                 // 释放锁
                 lock.unlock();
                 System.out.println("释放锁");
                 redisson.shutdown();
             }
         }
     }

• 优势：
  • 功能丰富：除了基本的锁功能，还支持可重入锁、公平锁、联锁、红锁等复杂的分布式锁场景。例如，在一个分布式事务处理系统中，可能需要同时获取多个资源的锁，Redisson 的联锁功能就可以很方便地实现。
  • 自动续期：Redisson 会在锁快要过期时自动为锁续期（看门狗），只要客户端的业务逻辑还在执行，就不用担心锁过期的问题。这大大提高了分布式锁的可靠性和易用性。
• 劣势：不能解决主从一致性的问题

        比如，当线程1加锁成功后，master节点数据会异步复制到slave节点，此时如果当前持有Redis锁的master节点宕机，slave节点被提升为新的master节点，假如现在来了一个线程2，再次加锁，会在新的master节点上加锁成功，这个时候就会出现两个节点同时持有一把锁的问题。

        可以利用Redisson提供的红锁来解决这个问题，它的主要作用是，不能只在一个Redis实例上创建锁，应该是在多个Redis实例上创建锁，并且要求在大多数Redis节点上都成功创建锁，红锁中要求是Redis的节点数量要过半。这样就能避免线程1加锁成功后master节点宕机导致线程2成功加锁到新的master节点上的问题了。

        但是，如果使用了红锁，因为需要同时在多个节点上都添加锁，性能就变得非常低，并且运维维护成本也非常高，所以，一般在项目中也不会直接使用红锁，并且官方也暂时废弃了这个红锁。

        Redis本身就是支持高可用的，要做到强一致性，就非常影响性能，所以，如果有强一致性要求高的业务，建议使用ZooKeeper实现的分布式锁，它是可以保证强一致性的。