SpringBoot整合Redisson实现分布式锁

分布式锁简述

在传统的，老旧单机项目中要想实现锁机制，我们可以使用下面的方式

• 基于 Java API 层面的 Lock ：代表实现类 ReentrantLock
• 基于 Java API 层面的 ReadWriteLock ：代表实现类 ReentrantReadWriteLock
• 基于 JVM 的 synchronized 关键字

但随着业务场景越来越复杂，伴随着技术的不断发展，在分布式的环境中，想要实现锁机制，使用上述的方式已无法实现业务功能。所以提出了分布式锁的概念及技术

分布式锁的实现，常见的有使用 redis 和 zookeeper 两种方式，而这两种方式个人认为实现有点复杂，我们可以使用 redis 官网提供的分布式锁解决方案 Redission 来实现

Redission官网：https://redisson.org/
github：https://github.com/redisson/redisson

分布式锁的常见应用场景

在分布式的环境中存在高并发，比如秒杀，抢票，抢购这些场景，都存在对核心资源，商品库存的争夺，控制不好，库存数量可能被减少到负数，出现超卖的情况，或者产生唯一的一个递增 ID，由于 web 应用部署在多个机器上，简单的同步加锁是无法实现的，给数据库加锁的话，数据库可能由行锁变成表锁，性能下降会厉害。那相对而言，redis 的分布式锁，相对而言，是个很好的选择，redis 官方推荐使用的 Redisson 就提供了分布式锁和相关服务

分布式锁应遵循的原则

• 互斥：在分布式高并发的条件下，我们最需要保证，同一时刻只能有一个线程获得锁，这是最基本的一点
• 防止死锁：在分布式高并发的条件下，比如有个线程获得锁的同时，还没有来得及去释放锁，就因为系统故障或者其它原因使它无法执行释放锁的命令，导致其它线程都无法获得锁，造成死锁。所以分布式非常有必要设置锁的有效时间，确保系统出现故障后，在一定时间内能够主动去释放锁，避免造成死锁的情况
• 可重入：我们知道 ReentrantLock 是可重入锁，那它的特点就是：同一个线程可以重复拿到同一个资源的锁。重入锁非常有利于资源的高效利用
• 性能：对于访问量大的共享资源，需要考虑减少锁等待的时间，避免导致大量线程阻塞。所以在锁的设计时，需要考虑两点。1、锁的颗粒度要尽量小。比如你要通过锁来减库存，那这个锁的名称你可以设置成是商品的 ID,而不是任取名称。这样这个锁只对当前商品有效，锁的颗粒度小。2、锁的范围尽量要小。比如只要锁 2 行代码就可以解决问题的，那就不要去锁 10 行代码了

springboot 整合 Redisson 实现分布式锁示例

引入依赖

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

<dependency>
	<groupId>org.redisson</groupId>
	<artifactId>redisson-spring-boot-starter</artifactId>
	<version>3.11.0</version>
</dependency>

配置文件配置 redis 信息

# redis 的配置
spring.redis.host=127.0.0.1
spring.redis.port=6379
spring.redis.password=
spring.redis.database=0
spring.redis.timeout=2000
spring.redis.lettuce.pool.max-active=10
spring.redis.lettuce.pool.max-wait=2
spring.redis.lettuce.pool.min-idle=5
spring.redis.lettuce.pool.max-idle=10

Redisson 配置类

@Configuration
public class RedissonConfig {
    
    

	@Bean
	public RedissonClient redissonClient() {
    
    
		Config config = new Config();
		config.useSingleServer().setAddress("redis://127.0.0.1:6379");
		RedissonClient client = Redisson.create(config);
		return client;
	}
}

Service 层使用分布式锁

@Service
public class ItemKillSuccessServiceImpl implements ItemKillSuccessService {
    
    

	@Autowired
	private ItemKillSuccessRepository itemKillSuccessRepository;

	@Autowired
	private MQSendService mQSendService;

	@Autowired
	private RedissonClient redissonClient;

	@Override
	public Boolean killItem(Integer id, String userId) throws InterruptedException {
    
    
		final String lockKey = id + userId + "-RedissonLock";
		// 获取 RLock 对象
		RLock rLock = redissonClient.getLock(lockKey);

		try {
    
    
			// 上锁
			boolean resultLock = rLock.tryLock(30, 10, TimeUnit.SECONDS);
			// 业务逻辑开始
			if (resultLock) {
    
    
				ItemKillSuccess itemKillSuccess = itemKillSuccessRepository.findByUserId(userId);
				if (StringUtils.isEmpty(itemKillSuccess)) {
    
    
					ItemReponse itemReponse = itemKillService.getItemKill(id);
					if (!StringUtils.isEmpty(itemReponse)) {
    
    
						try {
    
    
							mQSendService.sendMessage(itemReponse, userId);
							return true;
						} catch (Exception e) {
    
    
							return false;
						}
					} else {
    
    						
						throw new BusinessException(ResponseCode.ITEM_NOT_EXIST);
					}
				} else {
    
    
					throw new BusinessException(ResponseCode.USER_ALREADY_KILL);
				}
			}
		} finally {
    
    
			// 释放锁
			rLock.unlock();
		}
		return null;
	}
}

使用分布式锁的核心步骤

• 获取 RLock 接口对象，使用 RLock 对象加锁。注意：防止死锁
• 编写业务逻辑
• 使用 RLock 对象释放锁。注意：一般在 finally 块中释放

Controller 层

@Controller
@RequestMapping(path = {
    
     "/kill" })
public class ItemKillSuccessController {
    
    

	@Autowired
	private ItemKillSuccessService itemKillSuccessService;

	@RequestMapping(path = {
    
     "/execute" }, method = {
    
     RequestMethod.POST })
	@ResponseBody
	public ResponseMap execute(Integer id, @NotNull HttpServletRequest request) throws InterruptedException {
    
    
	
		String token = request.getHeader(Constant.ACCESS_TOKEN);
		String userId = JwtTokenUtil.getUserId(token);
		if (id == null) {
    
    
			throw new BusinessException(ResponseCode.ITEM_ID_NOT_EXIST);
		}
		if (StringUtils.isEmpty(userId)) {
    
    
			throw new BusinessException(ResponseCode.USER_ID_NOT_EXIST);
		}
		
		Boolean result = itemKillSuccessService.killItem(id, userId);
		
		if (result) {
    
    
			return new ResponseMap().success().message("亲，系统正在计算订单，请等待......");
		} else {
    
    
			return new ResponseMap().fail().message("亲，您的商品抢购失败");
		}
	}
}

Redisson 分布式锁的原理

加锁机制

• 线程去获取锁，获取成功：执行 lua 脚本，保存数据到 redis 数据库
• 线程去获取锁，获取失败：一直通过 while 循环尝试获取锁，获取成功后，执行 lua 脚本，保存数据到 redis 数据库

Watch dog 自动延期机制

在分布式环境下，假如一个线程获得锁后，突然服务器宕机了，那么这个时候在一定时间后这个锁会自动释放，你也可以设置锁的有效时间（不设置默认 30 秒），这样的目的主要是防止死锁的发生

但在实际开发中会有下面一种情况

// 设置锁 1 秒过期
redissonLock.lock("redisson", 1);

// 业务逻辑需要执行 2 秒
redissonLock.release("redisson");

线程 1 进来获得锁后，线程一切正常并没有宕机，但它的业务逻辑需要执行 2 秒，这就会有个问题，在线程 1 执行 1 秒后，这个锁就自动过期了，那么这个时候线程 2 进来了。那么就存在线程 1 和线程 2 同时在这段业务逻辑里执行代码，这当然是不合理的。而且如果是这种情况，那么在解锁时系统会抛异常，因为解锁和加锁已经不是同一线程了

所以这个时候 Watch dog 就出现了，它的作用就是线程 1 业务还没有执行完，时间就过了，线程 1 还想持有锁的话，就会启动一个 watch dog 后台线程，不断的延长锁 key 的生存时间

注意：正常这个 Watch dog 线程是不启动的，还有就是这个 Watch dog 启动后对整体性能也会有一定影响，所以不建议开启

Redisson 分布式锁的缺点

Redisson 分布式锁会有个缺陷，就是在 Redis 哨兵模式下

客户端 1 对某个 master 节点写入了 redisson 锁，此时会异步复制给对应的 slave 节点。但是这个过程中一旦发生 master 节点宕机，主备切换，slave 节点变为了 master 节点。这时客户端 2 来尝试加锁的时候，在新的 master 节点上也能加锁，此时就会导致多个客户端对同一个分布式锁完成了加锁。这时系统在业务语义上一定会出现问题，导致各种脏数据的产生

缺陷在哨兵模式或者主从模式下，如果 master 实例宕机的时候，可能导致多个客户端同时完成加锁