分布式锁简述
在传统的,老旧单机项目中要想实现锁机制,我们可以使用下面的方式
- 基于
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
实例宕机的时候,可能导致多个客户端同时完成加锁