哎，说起分布式锁，这玩意儿吧，看似简单，实则暗藏玄机。刚开始搞的时候，总觉得用个SETNX就万事大吉了后来啊一上线各种问题冒出来简直让人崩溃！今天咱就来好好唠唠这个事儿，从Redis的细节问题到RedLock算法的原理，保证让你彻底搞明白。

为什么需要分布式锁？

在深入探讨分布式锁的细节之前,了解为什么需要它至关重要。 与分布式锁相对的是 单机锁 。在编写多线程程序时,为了防止因一边操作共享变量而导致的数据问题,我们通常使用锁来实现互斥,从而保证共享变量的正确性。只是,这种锁的范围仅限于同一个进程内。 如果多个进程需要一边操作... 一个直观的解决方案是在获取锁时设置一个 租期 。 在 Redis 中,这意味着给 key 设置一个过期时间。假设操作共享资源的时间不会超过 10 秒,我们可以在获取锁时将 key 设置为 10 秒后过期:，不忍直视。

127.0.0.1:6379 SETNX lock 1  1
127.0.0.1:6379 EXPIRE lock 10 // 10秒后自动过期  ...

Redis单机部署下的简单实现

最简单的实现方式就是使用SETNX命令，如果设置成功就代表获得了锁。看起来好像没什么问题？别高兴太早！这玩意儿建立在Redis单机部署的基础上。如果Redis挂了呢？那可就歇菜了！所有请求都获取不到锁，业务直接瘫痪。想象一下要是是电商平台的下单接口出现这种情况，损失得有多大啊，我们都...！

主从模式能解决问题吗？

客户端发起请求到redis通过hset key指令来设置锁， 看起来似乎没什么问题，但是这是建立在redis单机部署的情况下如果redis挂了呢？那么就获取不到锁， 进而导致后续的业务逻辑无法施行， 太虐了。 那么对整个业务的影响非常大，假设此时是某个电商项目的下单接口出现这种问题，那么带来的资损将会无法估量。那么这个问题可以解决吗？当然可以 redis是支持主从模式的，如下：

public String deductStockRedisLock { AbstractLock lock = null; try { // 创建基于Redis的分布式锁,锁的key为"lock"+商品ID lock = new RedisLock; // 尝试在5秒内获取锁 boolean result = lock.tryLock; if { // 获取锁成功,施行库存扣减逻辑 // 1. 查询商品库存数量 String stock = template.opsForValue.get; if ) { return "商品不存在"; } Integer lastStock = Integer.parseInt; // 2. 判断库存是否充足 if { return "库存不足"; } // 3. 扣减库存 template.opsForValue.set); return "库存扣减成功"; } else { // 获取锁超时的处理 System.out.println; return "系统繁忙"; } } catch { throw new RuntimeException; } finally { // 确保在finally块中释放锁 if { lock.unlock; } }}

public boolean tryLock throws InterruptedException { // 记录开始尝试获取锁的时间戳 long startTime = System.currentTimeMillis; // 记录当前时间戳 long currentTime = System.currentTimeMillis; boolean lockResult = false; // 在指定的等待时间内循环尝试获取锁 // time表示最大等待时间,超过这个时间还未获得锁就返回false while { // 尝试获取锁 boolean result = tryLockInternal; if { // 获取锁成功,记录后来啊并退出循环 lockResult = result; break; } // 更新当前时间戳 currentTime = System.currentTimeMillis; } return lockResult;}，太治愈了。

主从切换的问题

差点意思。 通过主从模式来部署redis能够提升系统的可用性。master在施行命令后会通过异步线程向slave中同步数据。但是如果master挂掉了之后通过哨兵机制选举出一个新的master怎么办呢?新master产生后后续请求都会到新的master上进行处理。

这个时候就会出现一个严重的问题：客户端A已经成功加了旧Master上的lock，旧Master宕机后变成了Slave；新Master上并没有这个lock信息； 摸鱼。 客户端B又成功加了新Master上的lock！这样就造成了两个客户端一边持有同一把lock！这简直是要命啊！

红锁算法：更可靠的选择

针对这个问题，redis的作者提出了著名的红锁算法来解决，坦白说...。

Lua脚本优化

.

代码语言：java

本文探讨了Redis分布式分布式