1. 分布式锁概念
在多线程环境下,为了保证数据的线程安全,锁保证同一时刻,只有一个可以访问和更新共享数据。在单机系统我们可以使用 synchronized 锁、Lock 锁保证线程安全。
synchronized 锁是 Java 提供的一种内置锁,在单个 JVM 进程中提供线程之间的锁定机制,控制多线程并发。只适用于单机环境下的并发控制。
想要在多个节点中提供锁定,在分布式系统并发控制共享资源,确保同一时刻只有一个访问可以调用,避免多个调用者竞争调用和数据不一致问题,保证数据的一致性,就需要分布式锁。
分布式锁:控制分布式系统不同进程访问共享资源的一种锁的机制。不同进程之间调用需要保持互斥性,任意时刻,只有一个客户端能持有锁。
共享资源包含:
- 数据库
- 文件硬盘
- 共享内存
分布式锁特性:
- 互斥性:锁只能被持有的客户端删除,不能被其他客户端删除
- 锁超时释放:持有锁超时,可以释放,防止不必要的资源浪费,也可以防止死锁
- 可重入性:一个线程如果获取了锁之后,可以再次对其请求加锁。
- 高性能和高可用:加锁和解锁需要开销尽可能低,同时也要保证高可用,避免分布式锁失效
- 安全性:锁只能被持有的客户端删除,不能被其他客户端删除
模拟并发环境下单
①:添加 Redis 依赖:
<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
②:添加配置:
spring:redis:host: localhostport: 6379password:timeout: 2000s# 配置文件中添加 lettuce.pool 相关配置,则会使用到lettuce连接池lettuce:pool:max-active: 8 # 连接池最大连接数(使用负值表示没有限制) 默认为8max-wait: -1ms # 接池最大阻塞等待时间(使用负值表示没有限制) 默认为-1msmax-idle: 8 # 连接池中的最大空闲连接 默认为8min-idle: 0 # 连接池中的最小空闲连接 默认为 0
③:Redis 配置类:
@Configuration
public class RedisConfig {@Beanpublic RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {RedisTemplate<String, Object> template = new RedisTemplate<>();template.setConnectionFactory(redisConnectionFactory);ObjectMapper om = new ObjectMapper();om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);om.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);// json 序列化配置Jackson2JsonRedisSerializer<Object> jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer<>(Object.class);jackson2JsonRedisSerializer.setObjectMapper(om);// String 序列化StringRedisSerializer stringRedisSerializer = new StringRedisSerializer();// 所有的 key 采用 string 的序列化template.setKeySerializer(stringRedisSerializer);// 所有的 value 采用 jackson 的序列化template.setValueSerializer(jackson2JsonRedisSerializer);// hash 的 key 采用 string 的序列化template.setHashKeySerializer(stringRedisSerializer);// hash 的 value 采用 jackson 的序列化template.setHashValueSerializer(jackson2JsonRedisSerializer);template.afterPropertiesSet();return template;}}
Redis 工具类:
@Component
public class RedisUtil {@Autowiredprivate RedisTemplate<String, Object> redisTemplate;// 普通缓存获取public Object get(String key) {return key == null ? null : redisTemplate.opsForValue().get(key);}// 普通缓存放入public boolean set(String key, Object value) {try {redisTemplate.opsForValue().set(key, value);return true;} catch (Exception e) {e.printStackTrace();return false;}}public boolean setIfAbsent(String key, Object value, long timeout, TimeUnit unit) {return Boolean.TRUE.equals(redisTemplate.opsForValue().setIfAbsent(key, value, timeout, unit));}public void del(String... key) {if (key != null && key.length > 0) {if (key.length == 1) {redisTemplate.delete(key[0]);} else {//springboot2.4后用法redisTemplate.delete(Arrays.asList(key));}}}}
④:添加下单接口
@Slf4j
@RestController
@RequestMapping("/order")
public class OrderController {@Autowiredprivate RedisUtil redisUtil;@GetMapping("/initProductStock")public void initProductStock() {redisUtil.set("stock", 100);}@GetMapping("/create_order")public void createOrder() {// 获取当前库存int stock = (Integer) redisUtil.get("stock");if (stock > 0) {// 减库存int realStock = stock - 1;redisUtil.set("stock", realStock);// TODO 添加订单记录log.info("扣减成功,剩余库存:" + realStock);return;}log.error("扣减失败,库存不足");}}
接口说明:
/order/initProductStock
:先向 Redis 中初始化一个库存/order/create_order
:下单接口:先从缓存获取库存,如果库存大于 0,则库存减 1
⑤:并发测试
使用 JMeter 进行并发环境测试,10 个线程,循环 5 次。
⑥:测试结果,打印日志如下:
使用 JMeter 调用了 50 次接口后,按照正常情况下,库存应该为:50 = 100 - 50。
但通过日志显示,最终库存为:95。
这是因为在并发环境下,多个线程下单操作,前面的线程还未更新库存,后面的线程已经请求进来,并获取到了未更新的库存,后续扣减库存都不是扣减最近的库存。线程越多,扣减的库存越少。这就是在高并发场景下发生的超卖问题。
很明显,上述问题是出现了线程安全的问题,我们首先能想到的肯定是给它加 synchronized 锁。
是的,没问题,但是我们知道,synchronized 锁是属于JVM 级别的,也就是我们所谓的“单机锁”,如果是多机部署的环境中,还能保证数据的一致性吗?
答案肯定是不能的。这个时候,就需要用到了我们 Redis 分布式锁
用 Redis 实现分布式锁的几种方案,都是用 SETNX 命令(设置 key 等于某 value)。只是高阶方案传的参数个数不一样,以及考虑了异常情况
SETNX 是SET IF NOT EXISTS的简写。命令格式:SETNX key value,如果 key不存在,则 SETNX 成功返回 1,如果这个 key 已经存在了,则返回 0
setIfAbsent()
是 setnx + expire 的合并命令
2. Redis分布式锁方案一:SETNX + EXPIRE
问题:为什么要加过期时间
如果在释放锁之前 Redis 宕机了,就会造成一直死锁。
setnx
命令 和 expire
命令一定要是原子操作。
伪代码如下:
if(jedis.setnx(key_resource_id,lock_value) == 1){ //加锁expire(key_resource_id,100); //设置过期时间try {do something //业务请求}catch(){}finally {jedis.del(key_resource_id); //释放锁}
}
setnx
和 expire
两个命令分开了,「不是原子操作」。如果执行完 setnx
加锁,正要执行 expire
设置过期时间时,进程 crash 或者要重启维护了,那么这个锁就“长生不老”了,「别的线程永远获取不到锁啦」
@GetMapping("/create_order")
public void createOrder() {String key = "lock_key";// 1.加锁boolean lock = tryLock(key, 1, 60L, TimeUnit.SECONDS);if (lock) {try {// 获取当前库存int stock = (Integer) redisUtil.get("stock");if (stock > 0) {// 减库存int realStock = stock - 1;redisUtil.set("stock", realStock);// TODO 添加订单记录log.info("扣减成功,剩余库存:" + realStock);return;}log.error("扣减失败,库存不足");} catch (Exception e) {log.error("扣减库存失败");} finally {// 3.解锁unlock(key);}} else {log.info("未获取到锁...");}
}public boolean tryLock(String key, Object value, long timeout, TimeUnit unit) {return redisUtil.setIfAbsent(key, value, timeout, unit);
}public void unlock(String key) {redisUtil.del(key);
}
使用 JMeter 运行后,结果如下:
获取到锁的线程已成功扣除库存,没有获取到锁的线程只打印日志。
3. Redis分布式锁方案二:SETNX + EXPIRE + 校验唯一随机值
方案一还是有一定的缺陷的:假设线程 A 获取锁成功,一直在执行业务逻辑,但是 60s 过去了,还没执行完。但是,此时,锁已经过期了。线程 B 又请求过来了,显然,线程 B 也可以获取锁成功,也开始执行业务逻辑代码。那么问题就来了:在线程 B 执行过程中,线程 A 已经执行完了,就会把线程 B 的锁给释放掉!
既然锁可能被别的线程误删,那我们给 value 值设置一个标记当前线程唯一的随机数,在删除的时候,校验一下,就OK了
@GetMapping("/create_order")
public void createOrder() {String key = "lock_key";String value = "ID_PREFIX" + Thread.currentThread().getId();// 1.加锁boolean lock = tryLock(key, value, 60L, TimeUnit.SECONDS);if (lock) {// ...
}public void unlock(String key, String value) {String currentValue = (String)redisUtil.get(key);if (StringUtils.hasText(currentValue) && currentValue.equals(value)) {redisUtil.del(key);}
}
这里需要注意的是:释放锁时,先 get 再删除,这并不是原子操作,无法保证进程安全。为了更严谨,这里用 lua 脚本代替
lua 脚本
Lua脚本是redis已经内置的一种轻量小巧语言,其执行是通过 redis 的 eval/evalsha 命令来运行,把操作封装成一个 Lua 脚本,如论如何都是一次执行的原子操作
lockDel.lua如下:resources/lua/lockDel.lua
if redis.call('get', KEYS[1]) == ARGV[1]then-- 执行删除操作return redis.call('del', KEYS[1])else-- 不成功,返回0return 0
end
public void unlock(String key, String value) {// 解锁脚本DefaultRedisScript<Long> unlockScript = new DefaultRedisScript<>();unlockScript.setScriptSource(new ResourceScriptSource(new ClassPathResource("lua/lockDel.lua")));unlockScript.setResultType(Long.class);// 执行lua脚本解锁Long execute = redisTemplate.execute(unlockScript, Collections.singletonList(key), value);
}
或者:
public void unlock(String key, String value) {// 解锁脚本String script = "if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";redisTemplate.execute(new DefaultRedisScript<Long>(script, Long.class), Collections.singletonList(key), value);
}
4. Redis分布式锁方案三:Redisson
方案二还存在问题:「锁过期释放,业务没执行完」。 如果设置的超时时间比较短,而业务执行的时间比较长。比如超时时间设置5s,而业务执行需要10s,此时业务还未执行完,其他请求就会获取到锁,两个请求同时请求业务数据,不满足分布式锁的互斥性,无法保证线程的安全
4.1 Redisson 概念
其实我们设想一下,是否可以给获得锁的线程,开启一个定时守护线程,每隔一段时间检查锁是否还存在,存在则对锁的过期时间延长,防止锁过期提前释放。当前开源框架 Redisson 解决了这个问题。Redisson 底层原理图如下:
只要线程一加锁成功,就会启动一个 watch dog
看门狗,它是一个后台线程,会每隔 10 秒检查一下,如果线程 1 还持有锁,那么就会不断的延长锁 key 的生存时间。因此,Redisson 就是使用 watch dog 解决了「锁过期释放,业务没执行完」问题
Redis 虽然作为分布式锁来说,性能是最好的。但是也是最复杂的。上面总结 Redis 主要有下面几个问题:
- 未设置过期时间,会死锁
- 设置过期时间
- 锁误删
- 业务还继续执行,导致多个线程并发执行
线上都是用 Redission
实现分布式锁,Redisson 是一个在 Redis 的基础上实现的 Java 驻内存数据网格(In-Memory Data Grid)。它不仅提供了一系列的分布式的 Java 常用对象,还提供了许多分布式服务。Redisson 是基于 netty 通信框架实现的,所以支持非阻塞通信,性能优于 Jedis。
Redisson 分布式锁四层保护:
- 防死锁
- 防误删
- 可重入(一个线程可以在获取锁之后再次获取同一个锁,而不需要等待锁释放)
- 自动续期
Redisson 实现 Redis 分布式锁,支持单机和集群模式
4.2 Redisson 实现
使用 Redission 分布式锁,分成三个步骤:
- 获取锁
redissonClient.getLock("lock")
- 加锁
rLock.lock()
- 解锁
rLock.unlock()
引入依赖:
<dependency><groupId>org.redisson</groupId><artifactId>redisson</artifactId><version>3.20.0</version>
</dependency>
Redisson 配置类:
@Configuration
public class RedissionConfig {@Value("${spring.redis.host}")private String redisHost;@Value("${spring.redis.password}")private String password;private int port = 6379;@Beanpublic RedissonClient getRedisson() {Config config = new Config();// 单机版config.useSingleServer().setAddress("redis://" + redisHost + ":" + port);//.setPassword(password);config.setCodec(new JsonJacksonCodec());return Redisson.create(config);}}
集群版:
@Bean
public RedissonClient getRedisson() {Config config = new Config();config.useClusterServers().setScanInterval(2000) // 集群状态扫描间隔时间,单位是毫秒//可以用"rediss://"来启用SSL连接.addNodeAddress("redis://127.0.0.1:7000", "redis://127.0.0.1:7001").addNodeAddress("redis://127.0.0.1:7002");return Redisson.create(config);
}
下单接口:
@Slf4j
@RestController
@RequestMapping("/order")
public class OrderController {@Autowiredprivate RedissonClient redissonClient;@GetMapping("/create_order")public void createOrder() {String key = "lock_key";RLock rLock = redissonClient.getLock(key);// 1.加锁rLock.lock();try {// 获取当前库存int stock = (Integer) redisUtil.get("stock");if (stock > 0) {// 减库存int realStock = stock - 1;redisUtil.set("stock", realStock);// TODO 添加订单记录log.info("扣减成功,剩余库存:" + realStock);return;}log.error("扣减失败,库存不足");} catch (Exception e) {log.error("扣减库存失败");} finally {// 3.解锁rLock.unlock();}}
}
使用 JMeter 并发运行后:
Redission 实现的分布式锁,直接调用,不需要锁异常、超时并发、锁删除等问题,它把处理上面的问题的代码都封装好了,直接调用即可