Redis 分布式锁的 Key 如何设计？

核心回答

锁的 Key 应标识真正需要互斥的业务资源，所有竞争者对同一资源必须算出同一个 Key。例如活动库存按“活动＋商品”互斥，可用 lock:stock:{activityId:skuId}；不同商品各自加锁，避免一把全局锁把所有请求串行化。

锁键里不放每次请求变化的随机数、线程号或时间戳，否则竞争者各锁各的，失去互斥效果。随机持有者标识放在锁的值里，用于续期和释放时确认身份。互斥资源标识、锁持有者标识和业务幂等标识是三种不同的东西。

先问清楚哪两个操作不能同时进行

库存扣减约束的是同一份库存；一人一单约束的是“活动＋用户”；重复提交约束的是同一次业务操作。这三种约束不一定用同一个键，也不一定都需要分布式锁。

例如用户 u1 和 u2 购买同一商品，若库存修改需要互斥，它们必须竞争同一个库存资源键；只按用户加锁，仍然不能防止两人同时修改同一库存。反过来，对所有订单使用一个键，会让互不相关的订单彼此阻塞。

命名与实现细节

• 加上业务、环境或租户命名空间，避免不同系统恰好使用相同标识；编码分隔符，避免不同字段拼接成相同字符串。
• 键保持稳定且不过长；敏感信息可以用不可逆摘要或内部标识代替，不把完整个人信息放入可观察的键名。
• 若 Redis Cluster 中的原子脚本需要操作多个键，再设计同槽的 hash tag；不是所有键都加同一个标签，以免形成热点槽。
• 多资源操作约定固定加锁顺序，控制临界区和最长等待时间。

锁只能协调并发进入。订单去重仍需要稳定的幂等键、数据库唯一约束或状态条件更新；锁过期、客户端暂停和主从切换的风险也不会因为键名设计正确而自动消失。

参考资料