Redis分布式锁
场景：在电商网站中，当面临抢购、秒杀等活动时，由于并发量大，可能会引发库存超卖的问题。
为了避免这种情况，可以使用分布式锁来控制并发访问。
分布式锁：是一种多节点共享的同步机制，在同一时间只有一个节点能获的锁并执行关键操作。
在电商网站中，可以将每个商品的库存作为共享资源，使用分布式锁来控制并发访问。
分布式锁的目的是保证在分布式部署的应用集群中，多个服务在请求同一个方法或者同一个业务操作的情况下，对应业务逻辑只能被一台机器上的一个线程执行，避免出现并发问题。
分布式锁要满足的条件：
- 多进程互斥：同一时刻，只有一个进程可以获取锁
- 保证锁可以释放：任务结束或出现异常，锁一定要释放，避免死锁
- 阻塞锁（可选）：获取锁失败时可否重试
- 重入锁（可选）：获取所得代码递归调用时，依然可以获取锁
避免死锁的方式：
设置有效期
set key value [seconds | milliseconds] [XX|NX]
直接在设置键值时，就设置时长
比如：时长为什么设置30s,由于业务执行需29s,30s提供充裕时间后 释放锁
实现分布式锁的方案：mysql redis zookeeper
分布式锁：
利用Redis的setnx命令，这个命令的特征是如果多次执行，只有第一次执行会成功，可以实现互斥的效果
获取锁：
- 互斥：确保只有一个线程获取锁
- 非阻塞设计，保证获取锁失败后，不在一直获取，尝试一次，成功返回true，失败返回false
SETNX lock thread1
释放锁：
- 手动释放
DEL key 释放锁，删除即可
问题一：如果获取所成功后服务宕机，那么永远不会释放锁怎么办？
超时释放：获取锁时添加一个超时时间（需要利用expire命令给锁设置一个有效期）
- SETNX lock thread1 尝试获取锁
- EXPIRE lock 10 设置有效期
public String tryLock(String name, long expire) { name = name + "_lock"; String token = UUID.randomUUID().toString(); RedisConnectionFactory factory = stringRedisTemplate.getConnectionFactory(); RedisConnection conn = factory.getConnection(); try { //参考redis命令： //set key value [EX seconds] [PX milliseconds] [NX|XX] Boolean result = conn.set( name.getBytes(), token.getBytes(), Expiration.from(expire, TimeUnit.MILLISECONDS), RedisStringCommands.SetOption.SET_IF_ABSENT //NX ); if (result != null && result) return token; } finally { RedisConnectionUtils.releaseConnection(conn, factory,false); } return null; } /** * 未来数据定时刷新 */ @Scheduled(cron = "0 */1 * * * ?") public void refresh() { String token = cacheService.tryLock("FUTRUE_TASK_SYNC", 1000 * 30); if(StringUtils.isNotBlank(token)){ log.info("未来数据定时刷新---定时任务"); //获取所有未来数据的集合key Set<String> futureKeys = cacheService.scan(ScheduleConstants.FUTURE + "*"); for (String futureKey : futureKeys) {//future_100_50 //获取当前数据的key topic String topicKey = ScheduleConstants.TOPIC + futureKey.split(ScheduleConstants.FUTURE)[1]; //按照key和分值查询符合条件的数据 Set<String> tasks = cacheService.zRangeByScore(futureKey, 0, System.currentTimeMillis()); //同步数据 if (!tasks.isEmpty()) { cacheService.refreshWithPipeline(futureKey, topicKey, tasks); log.info("成功的将" + futureKey + "刷新到了" + topicKey); } } } }
问题2：如果expire之前服务宕机怎么办？
要保证sentx和expire命令的原子性，redis的set命令可以满足，需要添加nx和ex的选项：
- NX:与sentx一致，第一次执行成功
- EX:设置过期时间
- set key value [EX time秒] [NX]
- set lock thread1 EX 10 NX
补充：
set属于String类型添加
sset key value 创建时 ，
若key存在，表示修改；
若key不存在，表示添加
set key value [seconds | milliseconds] [XX|NX]（模式）或setnx key value [seconds | milliseconds]
若加NX 模式
具有特性：
互斥性：若key存在，会添加失败
若key不存在，添加成功
开始：流程开始。
尝试获取锁：尝试获取分布式锁。
判断结果：根据获取锁的结果进行判断。
获取锁失败：如果获取锁失败，有两种情况：
业务超时：表示业务操作耗时过长，可能导致锁失效。
服务宕机：表示服务器出现问题，可能导致锁无法正常释放。
自动释放锁：在业务超时或服务宕机的情况下，需要自动释放锁，以免影响后续操作。
执行业务：如果获取锁成功，执行业务逻辑。
释放锁：无论是正常执行完业务还是出现异常，都需要释放锁，以保持系统的稳定性。
原文地址：https://blog.csdn.net/fada_da_da/article/details/142988810
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！