Redis锁清理机制优化方案，高效清锁命令与实用技巧分享
Redis锁自动清理的核心在于合理设置锁的过期时间，并结合Lua脚本与逻辑判断，避免过期锁残留问题。
为什么需要优化锁清理机制？
很多时候，我们直接用Redis的SET命令加锁，比如用EX参数设置过期时间，但如果程序处理任务的时间比锁的过期时间还长，锁就会自动过期并被其他客户端获取，导致原来的锁虽然过期但可能还在执行操作，造成混乱；或者程序异常崩溃，锁没有被手动删除，就会一直占用，除非等它过期，但过期时间如果设得长，就会长时间阻塞其他请求。所以，清理机制不光是设置过期时间那么简单，还需要考虑各种意外情况，确保锁能及时、正确地被清理掉。
第一步：设置合理的过期时间
最简单的做法是给锁设置一个过期时间，比如用命令：SET lock_key unique_value EX 30，表示锁30秒后自动过期。但问题来了：如果任务需要40秒才完成，锁提前过期了怎么办？一种实用技巧是，不要用一个固定的时间，而是根据任务类型动态调整。比如，你可以先预估任务的最大耗时，然后设置过期时间比它长一些，比如长20%。如果任务耗时不确定，还可以用“看门狗”机制，也就是在任务执行期间，定期去延长锁的过期时间，确保锁不会在任务完成前过期。Redis本身没有内置看门狗，但你可以写代码来实现，比如用定时任务每过一段时间就执行EXPIRE命令来续期。
第二步：使用Lua脚本保证原子性
清理锁时，最怕的是误删别人的锁。假如客户端A加锁后，因为某些原因卡住了，锁过期后客户端B加锁成功，这时A恢复过来，想去删除锁，就可能把B的锁删掉。为了避免这个，我们通常在加锁时存一个唯一值（比如UUID），删锁前先检查这个值是否匹配。但检查值和删除是两个操作，如果不是原子的，中间可能被其他操作打断。所以，高效的做法是用Lua脚本把这两个操作绑在一起，确保原子执行。例如，写一个Lua脚本：if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end。这样，只有锁的值匹配时才会删除，安全又高效。
第三步：监控和自动化清理
除了依赖过期时间，你还可以主动监控锁的状态。比如，用Redis的SCAN命令定期扫描所有锁键，检查它们的过期时间或最后活跃时间，如果发现某些锁已经过期但还没删除（可能是因为程序崩溃残留），就可以强制清理。不过要注意，SCAN命令可能影响性能，所以不建议太频繁执行，可以放在低峰期做。另一个技巧是，给锁键加上前缀，比如“lock:”，这样扫描时可以更有针对性，减少扫描范围。同时，记录日志，当清理发生时，记下详情，方便问题排查。
高效清锁命令推荐
除了基本的DEL命令，结合上述技巧，这里推荐几个实用命令组合：1. 加锁：SET lock:order 123456 EX 60 NX – 设置60秒过期，且只在键不存在时加锁。2. 删锁：用EVAL命令执行前面提到的Lua脚本，例如 EVAL “if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end” 1 lock:order 123456。3. 监控锁：用TTL lock:order 查看剩余过期时间，或用OBJECT IDLETIME lock:order 查看空闲时间（如果支持），辅助判断是否该清理。这些命令简单直接，能帮你高效管理锁。
实用技巧分享
在实际项目中，还有一些小技巧能提升效率：一是避免锁粒度太细，不要为每个小操作都加锁，而是尽量合并，减少锁数量；二是设置锁的默认超时时间，比如所有业务锁默认30秒，特殊任务再调整，这样易于管理；三是用Redis集群时，注意锁的分布，确保锁键在同一个节点上，避免跨节点问题；四是测试时模拟网络延迟或崩溃，验证清理机制是否健壮。总之，锁清理不是一劳永逸的，需要根据应用场景不断调整优化。
FAQ
问：锁过期了但任务还没完成，有什么办法？答：可以用“看门狗”机制，在任务执行代码中启动一个后台线程或定时器，定期调用EXPIRE命令续期锁，直到任务完成才停止续期，确保锁始终有效。
问：如何防止误删其他人的锁？答：加锁时存储一个唯一标识（如UUID或客户端ID），删锁前用Lua脚本检查这个标识是否匹配，只有匹配才删除，避免误删。
问：Redis锁清理频率应该怎么设置？答：清理频率不宜过高，以免影响性能。建议根据锁的数量和业务峰值来定，比如每小时一次或每天低峰期执行扫描清理，同时结合过期时间自动清理。
引用来源：基于Redis官方文档（https://redis.io/commands/set）及分布式锁实践社区（如Redlock算法讨论和Lua脚本应用案例）。