章
目
录
在分布式环境下，会出现多个服务器并发修改同一资源的情况。这种情况下，由于多个服务器运行在不同的JRE环境中，而Java自带的锁机制局限于当前JRE，因此在这个场景下，Java自带的锁机制无效。因此，我们需要自己实现分布式锁。
采用Redis来实现分布式锁，我们可以在Redis中存储一个代表锁的数据，通常使用字符串格式即可。首先，加锁的逻辑可以通过setnx key value来实现。但如果客户端忘记解锁，就有可能导致死锁。另外，如果直接给锁增加过期时间，即使用expire key seconds，又会引发其他问题。因为这两个命令不是原子性的，如果第二步失败，仍然无法避免死锁问题。为了解决这些问题，我们可以通过set...nx...命令将加锁和过期命令组合成原子操作，以避免死锁。具体写法为set key value nx ex seconds。
解锁操作是将代表锁的数据删除。但不能简单地使用del key命令，因为会引发一些问题。例如，如果此时有进程A，如果在任务未完成时锁被到期释放了，进程A在任务完成后仍然会尝试释放锁，因为它的代码逻辑规定在任务结束后释放锁。然而，此时锁已经被释放，这可能导致进程A释放其他线程的锁。为了解决这种情况，我们可以在加锁时为key赋一个随机值，充当进程的标识。进程需要记住这个标识，然后在解锁时进行判断，只有自己持有的锁才能释放。此外，获取和删除操作需要保持原子性，否则如果第二步失败，就会造成死锁。因此，我们可以使用Lua脚本将这两个操作组合在一起，因为Lua脚本的执行是原子的。
综上所述，优化后的分布式锁命令如下：
# 加锁
set key random-value nx ex seconds
# 解锁
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end
扩展：
上述的分布式锁实现方式基于单节点，可能存在高可用性问题。例如，如果主节点宕机，新的主节点产生，那么另一个进程可能在新主节点上获得锁，而旧主节点重新启动后也可能成为从节点，导致系统中出现两个锁，违反了锁的唯一性原则。
为了保证分布式锁的高可用性，需要考虑多节点的实现方案。Redis的官方建议使用RedLock算法，它基于多个独立的Redis节点，其基本逻辑如下：
- 多个节点相互独立，不存在主从复制或集群协调机制；
- 加锁时向N个实例请求锁，只要超过一半的节点成功，则认为加锁成功；
- 解锁时向所有实例发送DEL命令进行解锁。
可以自行实现该算法，或者直接使用Redisson框架来实现高可用的分布式锁。
