Redis怎样排查因驱逐引起的分布式锁丢失问题_严禁给锁Key启用allkeys淘汰并显式设置合理TTL

Redis怎样排查因驱逐引起的分布式锁丢失问题_严禁给锁Key启用allkeys淘汰并显式设置合理TTL

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

分布式锁用得好好的，怎么突然就失效了？如果排查下来，发现既不是客户端超时释放，也不是被人误删，那很可能撞上了一个隐蔽的“杀手”：Redis的键驱逐（Eviction）。简单来说，就是锁的Key被Redis自己主动清理掉了——不是过期，也不是被DEL命令删除，而是在内存不足时，被LRU、LFU这类淘汰策略给“踢”了出去。这种情况在高负载、小内存或配置不当的Redis实例上特别容易发生，而且问题往往难以复现，定位起来相当棘手。

为什么 allkeys-lru 会让锁突然消失

问题的核心在于淘汰策略的配置。当Redis配置为maxmemory-policy allkeys-lru（或者类似的allkeys-lfu、allkeys-random）时，它会平等地对待所有Key，包括那些你精心设置了TTL的锁Key。这意味着，即便你成功执行了SET lock:order:123 “uuid-abc” NX PX 30000，只要实例内存告急，这个锁Key完全可能在短短几秒后就被驱逐。关键在于，Redis执行驱逐时不会触发任何过期事件，客户端也收不到任何通知。

业务上的表现通常是：日志里找不到锁超时或主动释放的记录，但多个并发请求却同时进入了临界区。从监控上看，evicted_keys指标会突然增长，同时used_memory_rss会接近maxmemory上限。

哪些场景容易踩坑呢？

• 锁Key和普通的缓存Key混在同一个Redis实例里，没有做任何命名空间或业务隔离。
• 业务代码误用了set或hset等命令，写入了大量热数据，迅速挤占了内存空间。
• maxmemory设置得过小，或者没有为AOF重写、复制缓冲区等操作预留足够的内存缓冲。

如何确认锁丢失是驱逐导致的

与其在浩如烟海的业务日志里大海捞针，不如直接查看Redis的运行指标，这通常更直接有效：

• 执行INFO memory命令，重点关注evicted_keys的值是否大于0，并且这个增长的时间点是否与锁异常的时间吻合。
• 执行INFO stats命令，检查total_commands_processed（总处理命令数）和instantaneous_ops_per_sec（瞬时OPS）是否有突增，这往往意味着请求压力触发了内存淘汰。
• 使用MEMORY USAGE lock:order:123查看特定锁Key的内存占用，如果返回-1，说明Key已不存在。此时再执行get lock:order:123返回nil，也不能直接断定是自然过期，必须结合evicted_keys指标来判断。

这里有个细节需要注意：TTL lock:order:123命令返回-2表示Key不存在，返回-1表示Key存在但没有设置过期时间。如果你使用了PX参数，那么TTL返回值就绝不应该出现-1；如果返回了-2，就应该立刻去检查evicted_keys。

必须禁用 allkeys 类淘汰策略

对于分布式锁的Key，“不被主动驱逐”是一条技术底线。正确的做法其实很明确，主要有两条：

• 将存放锁的Redis实例的淘汰策略严格设置为noeviction。这意味着一旦内存写满，新的写入操作会直接失败（返回(error) OOM command not allowed when used memory > ‘maxmemory’. 错误）。这至少能把问题暴露在加锁阶段，而不是在系统运行中静默地丢失锁。
• 或者，更彻底的做法是进行资源隔离：用专门的Redis实例（哪怕是单节点）来服务分布式锁，缓存业务则使用另一套集群。锁实例的maxmemory只需要设置为能容纳几千个锁Key的大小即可，这样几乎永远不会触及淘汰阈值。

千万不要有这种想法：“我设置了PX参数，锁就一定能存活30秒。”在allkeys-lru策略下，这个假设毫无意义。TTL只约束Key的过期时间，而管不了内存驱逐。

显式 TTL + 原子写入仍是基础要求

即便禁用了驱逐策略，锁创建操作本身的安全性依然是基础。这包括：

• 必须使用SET key value NX PX 30000这样的原子命令，而不是分两步的SETNX加EXPIRE，后者存在竞态条件窗口。
• Value必须使用全局唯一的标识（例如UUID），以便后续通过Lua脚本安全地释放锁，避免误删其他客户端的锁。
• 避免对锁Key手动调用PERSIST或EXPIREAT等命令，这会破坏TTL的可预测性，增加运维复杂度。

最危险的组合莫过于：allkeys-lru + SETNX + 无TTL。这种情况下，锁既可能因为内存不足被驱逐，又因为没有过期时间而永远不会自动释放，最终变成一个难以察觉的“隐形死锁”。

最后，需要警惕的是，驱逐导致的锁丢失，往往发生在压力测试的后期，或者流量高峰的尾声。此时内存水平在高位反复波动，个别锁Key可能在毫秒级的窗口内被淘汰。它不像网络分区或进程崩溃那样有明确的事件信号，排查时很容易陷入“明明设置了30秒的锁，怎么5秒就没了”的思维定式。正确的排查顺序应该是：先看evicted_keys，再查内存使用情况，最后才去审视业务代码。