qq_39666711的博客

在Java中，如果你使用Spring Boot并集成了Spring Data Redis，那么redisTemplate是一个常用的操作Redis的模板类。unlock方法则使用了一个Lua脚本来执行解锁操作，该脚本首先检查Redis中存储的锁的值是否与客户端提供的值相匹配，如果匹配则删除锁。如果不匹配，则返回0，表示解锁失败（非锁的持有者）。使用Redis中加锁和解锁的开发中，解锁需要验证当前客户端是否是锁的持有者，然后再解锁，具体怎么验证，下面是一个示例（使用redisTemplate来实现）

在Redis中加锁和解锁通常是通过Redis的原子性命令来实现的，以保证操作的原子性和线程安全。

@TOC]背景：在日常开发过程中，遇到了一个需求，比如有一个对象User（name，age、sex）有三个属性，现在需要用户新增接口中，防止此接口被多人同时请求访问，产生了姓名&年龄相同的，还有年龄&性别相同的数据；

Service）是阿里巴巴开源的一个动态服务发现和配置管理平台，专为微服务架构和云原生应用设计。它旨在简化服务注册、配置管理和服务治理的复杂性，通过提供一套简单易用的特性集，帮助开发者快速构建、部署和管理微服务应用。

例如，在更新缓存中的数据时，先加锁，更新完成后再释放锁，确保同一时间只有一个服务实例能够修改缓存数据。在看代码过程中发现，下单这块代码可能会出现问题，这可是分布式部署的，如果多个用户同时购买同一个商品，就可能导致商品出现 库存超卖 (数据不一致) 现象，对于这种情况代码中并没有做任何控制。小T下面的一位兄弟正在压测，发现个小问题，因为在终端设备上跟鹅厂有紧密合作，调用他们的接口时需要获取到access_token，但是这个access_token过期时间是2小时，过期后需要重新获取。

如果条件表达式的值为假（例如，如果我们将a的值改为30），则Lua会跳过then后面的代码块，直接执行else后面的代码块（如果提供了else部分的话）。因此，Lua执行了then后面的print语句，输出了"a is less than b"，然后遇到了end关键字，if语句的执行结束。在redission中也是支持锁重入的，他采用了hash结构来存储锁，其中大key标识这把锁是否存在，小key表示这把锁当前被谁持有。首先，我们先基本的熟悉一下lua脚本的逻辑。对于源码中的Lua脚本又是什么意思？

总结：在调用lock（）方法时，我们可以传入自定义的超时时间，也可以不传，如果不传那么将会使用Redisson默认的看门狗时间30s，需要注意的是，如果我们使用了自定义超时时间，那么Redisson不会自动为我们的锁续期，而不传时间Redisson会使用默认30s超时时间并且会自动为我们的锁进行续期。进入tryAcquire（）→ tryAcquireAsync（）方法，该方法首先会判断释放时间是否为-1，如果为-1则代表我们在前面没有传入超时时间，根据这个判断结果将会走两条不同的路。

接着上一节，我们遇到了超卖的问题，并通过Redis实现分布式锁，进行了解决。本节 我将换一种方式实现分布式锁。可以看到，没有超卖现象。至此Redission实现分布式锁已经OK。provider-and-consumer 端口 8023。rabbitmq-consumer 端口 8021。

线程1休息的时间超过了过期时间，此时锁会自动释放。此时就会发生蝴蝶效应，线程1删除了线程2的锁，线程2删除了线程3的锁，直到最后一个"哥们：wc，我锁了?最后删除锁的时候，我这里使用了先判断是否是当前处理的服务的本次处理设置的分布式锁，如果是，才删除，否则不让删除其他线程的服务处理产生的锁，这里一定需要注意，否则会产生锁误删的情况，会让分布式锁失效！我们发现，这两个服务虽然单独的看，销售的商品都是正确的，但是放在一起看，就会发现有相同的库存，这就说明，同一个库存被卖了两次，我们上文提到的超卖问题仍然存在！

后两者的使用较为常见。但是使用不同的分布式锁，又会需要考虑不同的风险，对不同的风险予以应对。不同的实现风险及解决方案可见我的另外一篇博客：待补充。