Redis分布式锁原理与实战，科普并发控制的核心机制与应用场景

使用Redis的SET命令配合NX和PX参数，可以原子性地设置一个带过期时间的键值对作为锁，确保在分布式系统中同一时间只有一个客户端能执行关键操作，避免并发问题。

为什么需要分布式锁

在现代软件中，很多应用会部署在多台服务器上，比如电商网站，当用户抢购商品时，如果多个服务器同时处理同一个商品的库存减少，就可能出现超卖问题。分布式锁就是用来控制这些服务器，让它们不要同时操作共享资源，比如数据库里的库存数量。

Redis分布式锁的基本原理

Redis分布式锁的核心是利用Redis的SET命令。这个命令可以设置一个键值对，并且通过NX选项，只有当键不存在时才会设置成功。同时，通过PX选项给这个键设置一个过期时间，比如10秒，这样即使持有锁的客户端崩溃了，锁也会自动释放，不会永远锁住。

举个例子，假设我们要锁定一个商品ID为1001的库存操作。客户端A执行SET lock:1001 "随机值" NX PX 10000。如果返回成功，表示A拿到了锁。客户端B也执行同样的命令，但由于键已存在，会失败，B就必须等待或重试。当A完成操作后，可以删除这个键来释放锁。但更安全的做法是，A在释放锁时，先检查这个键的值是不是自己当初设置的随机值，如果是才删除，避免误删其他客户端后来设置的锁。这通常用Lua脚本来原子性地完成。

实战步骤

第一步，获取锁。使用SET命令，设置一个唯一的键，比如用业务前缀加资源ID，值用一个随机字符串（比如UUID），并设置过期时间。第二步，执行业务逻辑。比如减少库存。第三步，释放锁。通过Lua脚本，先比较当前锁的值是否与自己设置的随机值相等，如果相等则删除，否则什么都不做。

在实际代码中，可以使用一些现成的库，比如在Java中，Redisson客户端提供了方便的分布式锁实现。但理解原理很重要，这样在出问题时能知道如何排查。

并发控制的核心机制

并发控制不只是加锁，还有乐观锁、CAS等机制。在分布式锁场景中，核心是互斥，即同一时间只有一个能进入。Redis锁通过单线程特性保证了SET命令的原子性，从而实现了互斥。另外，锁的过期时间避免了死锁，随机值避免了误删，这些都是关键点。

应用场景

除了抢购库存，分布式锁还用在很多地方。比如，定时任务在集群中只执行一次，多个节点竞争锁，谁拿到谁执行。再比如，防止重复提交，用户提交表单时生成一个唯一ID，用锁确保同一ID的请求只处理一次。还有分布式系统中的配置更新，需要加锁保证更新时不会产生冲突。

FAQ

问题1：Redis分布式锁会不会有安全问题？
答：有潜在风险。如果Redis是单点，宕机了锁就失效了。可以用Redis集群（如RedLock算法）来提高可靠性，但实现复杂。通常，如果业务可以容忍偶尔的并发问题，单Redis实例加过期时间就够了；如果要求高，可以考虑更严格的方案。

问题2：锁的过期时间设置多长合适？
答：这需要根据业务逻辑的执行时间来定。一般设置为业务执行时间的2-3倍。比如，业务通常需要1秒完成，那就设置3-5秒。太短可能导致业务还没完成锁就释放了，引起并发问题；太长则可能导致其他客户端等待过久。最好在代码中加入监控，观察锁持有时间，动态调整。

问题3：除了Redis，还有什么可以做分布式锁？
答：常用的还有ZooKeeper和数据库。ZooKeeper利用临时顺序节点，可靠性高，但性能不如Redis。数据库可以用唯一约束或乐观锁，但性能较差。选择哪种取决于业务对一致性、性能和复杂度的要求。

引用来源：基于Redis官方文档关于SET命令的命令，以及Martin Kleppmann和Antirez关于分布式锁的讨论。