思考：生产环境下Redis集群环境，怎么保证锁的同步？

我们先来回顾一下分布式锁的作用：就是保证同一时间只有一个客户端可以对共享资源进行操作。

当我们集群环境部署的时候，假如节点一在主节点获取分布式锁成功。Redis主节点再同步数据到从节点时宕机，数据没同步成功；高可用机制 则Redis从节点升级为主节点 （但是没有锁信息）。节点二 在新的Redis上也成功获取分布式锁，导致一个锁资源同时被两个节点获取，这个就出现了问题。

那么我们应该怎么去解决这个问题？

采用 RedLock 算法，Redis从3.0版本开始支持 Redlock 算法，通过在多个 Redis 节点上创建同一个锁来防止主从节点之间出现的数据不一致的问题。在 Redlock 算法中，需要从多个Redis节点获取锁，并对取锁结果进行校验，从而避免数据不一致性带来的问题。锁变量由多个实例维护，即使有实例发生了故障，锁变量仍然是存在的，客户端还是可以完成锁操作。需要注意的是, redlock算法会引入一定的错误率，需要根据业务场景进行权衡和控制。

RedLock加锁流程

• 客户端 获取当前毫秒级时间戳，并设置超时时间 TTL
• 依次向 N 个 Redis 服务发出请求，用能够保证全局唯一的 value 申请锁 key
• 如果从 N/2+1 个 redis 服务中都获取锁成功，那本次分布式锁的获取被视为成功，否则获取锁失败
• 如果获取锁失败，或执行达到 TTL，则向所有 Redis 服务都发出解锁请求

如果想搭建一个能够允许 N 台机器 down 掉的集群，那么就要部署一个由 2*N+1 台服务器构成的 集群。高可用部署最少的节点数计算公式 ：N( 总节点数) = 2 * X(宕机数) +1，X > 0，最少需要 3 台，半数以上节点选举，不包含半数。

• 宕机一台还可以高可用：3 = 2 * 1 + 1
• 宕机二台还可以高可用：5= 2 * 2 + 1

这种架构上redis全部节点都是主节点，没有从节点，抛弃了主从的异步复制。各个节点之间没关系，不是集群也不是主从，互相独立 。由于使用比较复杂且概率性较低，但多数公司还是采用了主从架构，在一些特定的场景且要求高的情况才会采用，且节点数会根据情况增加。

ok，下面我们先来进行环境的搭建。采用Docker的方式搭建三个Redis节点。

docker run -itd --name redlock-1 -p 6380:6379 redis:7.0.8 --requirepass 123456
docker run -itd --name redlock-2 -p 6381:6379 redis:7.0.8 --requirepass 123456
docker run -itd --name redlock-3 -p 6382:6379 redis:7.0.8 --requirepass 123456

查看Redis节点部署情况。

OK，接下来我们正式进入编码环节。我们采用SpringBoot+Redisson+Redis来实现RedLock

首先创建SpringBoot项目添加依赖。

<dependencies><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency><dependency><groupId>org.redisson</groupId><artifactId>redisson</artifactId><version>3.20.1</version></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-redis</artifactId><version>3.0.6</version></dependency></dependencies>

随后，我们编写程序主类，Redis的配置类。

/*** @author lixiang* @date 2023/6/25 11:33*/
@SpringBootApplication
public class RedLockApplication {public static void main(String[] args) {SpringApplication.run(RedLockApplication.class, args);}
}

/*** @author lixiang* @date 2023/6/25 10:59*/
@Configuration
public class RedisConfig {@Beanpublic RedisTemplate<Object, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {RedisTemplate<Object, Object> redisTemplate = new RedisTemplate<>();redisTemplate.setConnectionFactory(redisConnectionFactory);// 使用Jackson2JsonRedisSerialize 替换默认序列化Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);ObjectMapper objectMapper = new ObjectMapper();objectMapper.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);jackson2JsonRedisSerializer.setObjectMapper(objectMapper);// 设置key和value的序列化规则redisTemplate.setKeySerializer(new StringRedisSerializer());redisTemplate.setValueSerializer(jackson2JsonRedisSerializer);// 设置hashKey和hashValue的序列化规则redisTemplate.setHashKeySerializer(new StringRedisSerializer());redisTemplate.setHashValueSerializer(jackson2JsonRedisSerializer);// 设置支持事物//redisTemplate.setEnableTransactionSupport(true);redisTemplate.afterPropertiesSet();return redisTemplate;}@Beanpublic Redisson redissonClient1(){Config config = new Config();config.useSingleServer().setAddress("redis://ip:6380").setDatabase(0).setPassword("123456");return (Redisson) Redisson.create(config);}@Beanpublic Redisson redissonClient2(){Config config = new Config();config.useSingleServer().setAddress("redis://ip:6381").setDatabase(0).setPassword("123456");return (Redisson) Redisson.create(config);}@Beanpublic Redisson redissonClient3(){Config config = new Config();config.useSingleServer().setAddress("redis://ip:6382").setDatabase(0).setPassword("123456");return (Redisson) Redisson.create(config);}
}

编写Controller逻辑。

/*** @author lixiang* @date 2023/6/25 11:04*/
@RestController
@RequestMapping("/")
public class RedLockController {/*** 定义锁的名字*/public static final String CACHE_KEY_REDLOCK = "redlock";@Autowiredprivate RedissonClient redissonClient1;@Autowiredprivate RedissonClient redissonClient2;@Autowiredprivate RedissonClient redissonClient3;@RequestMapping("getRedLock")public String getRedLock(){//每个客户端分别获取锁资源RLock lock1 = redissonClient1.getLock(CACHE_KEY_REDLOCK);RLock lock2 = redissonClient2.getLock(CACHE_KEY_REDLOCK);RLock lock3 = redissonClient3.getLock(CACHE_KEY_REDLOCK);//创建红锁 客户端RedissonRedLock redLock = new RedissonRedLock(lock1, lock2, lock3);//定义获取锁标志位,默认是获取失败boolean isLockBoolean = false;try {/*** waitTime：等待获取锁的最长时间。如果在等待时间内无法获取锁，并且没有其他锁释放，则返回 false。如果 waitTime < 0，则无限期等待，直到获得锁定。* leaseTime：就是redis key的过期时间，锁的持有时间，可以使用 ttl  查看过期时间。* 如果在持有时间结束前锁未被释放，则锁将自动过期，没有进行key续期，并且其他线程可以获得此锁。如果 leaseTime = 0，则锁将永久存在，直到被显式释放。*/isLockBoolean = redLock.tryLock(1, 20, TimeUnit.SECONDS);System.out.printf("线程:"+Thread.currentThread().getId()+",是否拿到锁:" +isLockBoolean +"\n");if (isLockBoolean) {System.out.println("线程:"+Thread.currentThread().getId() + ",加锁成功，进入业务操作");try {//业务逻辑，40s模拟，超过了key的过期时间TimeUnit.SECONDS.sleep(40);} catch (InterruptedException e) {e.printStackTrace();}}} catch (Exception e) {System.err.printf("线程:"+Thread.currentThread().getId()+"发生异常,加锁失败");e.printStackTrace();} finally {// 无论如何，最后都要解锁redLock.unlock();}return isLockBoolean?"success":"fail";}}

测试启动，接口调用。

模拟加锁故障

• 3个节点停止1个节点，加锁成功
  

• 3个节点停止2个节点，加锁失败

注意，RedLock也是非绝对安全的

RedLock解决了单Redis节点的分布式锁在failover的时候锁失效的问题，但节点如果出现奔溃重启，对锁的安全性依旧存在问题。

• 假如一共有5个Redis节点：A, B, C, D, E
  • 客户端1成功锁住了A, B, C，获取锁成功（但D和E没有锁住）。
  • 节点C崩溃重启，但客户端1在C上加的锁没有持久化下来，aof机制导致。
  • 节点C重启后，客户端2锁住了C, D, E，获取锁成功。
• Redis 的 AOF 持久化方式是每秒执行fsync写一次磁盘，最坏情况下可能丢失1秒的数据。
• 尽可能不丢数据，Redis允许设置成每次修改数据都进行fsync，但会降低性能。
• 即使执行了fsync也仍然有可能丢失数据，因为也取决操作系统的刷盘策略，文件系统写到了buffer里面。
• 建议 延迟重启，一个节点崩溃后，先不立即重启它，而是等待一段时间再重启，这段时间应该大于锁的有效时间。
• 那这个节点在重启前所参与的锁都会过期，它在重启后就不会对现有的锁造成影响。

OK，RedLock相关的知识点以及案例实战，我们就介绍到这里了哦，记得三连下哦！