使用Redis锁：固定字符串锁键值可行性及最优方案咨询

1. 锁键设置为固定字符串是否可行？ #

完全可以。这种固定键本质是全局互斥锁，所有增删改请求都会竞争这同一个锁，只有拿到锁的请求才能执行操作，没拿到的需要等待或返回“操作进行中”的提示。但要注意，这种设计是把所有增删改操作都纳入同一互斥范围，后续如果业务扩展，不同类型的增删改不需要全局互斥时，固定键会过度限制并发能力。

2. 该方案能否解决问题？ #

在满足以下前提的情况下，这个方案可以解决全局互斥的需求：

• 用Redis原子命令加锁：必须用SET lock_key unique_client_id NX PX 30000这类命令（NX表示仅当键不存在时设置，PX是毫秒级过期时间），避免先查后设的竞态条件。
• 正确处理锁超时：设置合理的过期时间，防止操作执行超时或进程崩溃后锁永久占用；如果操作执行时间可能超过过期时间，要加看门狗线程自动续期锁。
• 安全解锁：不能直接DEL锁键，必须用Lua脚本验证自己持有的唯一值后再删除，比如：

  if redis.call('GET', KEYS[1]) == ARGV[1] then
      return redis.call('DEL', KEYS[1])
  else
      return 0
  end
  

  避免误删其他请求持有的锁。

如果不注意以上细节，比如用非原子方式加锁、解锁时不验证归属，会导致锁失效、互斥逻辑混乱，无法解决问题。

3. 更优实现方式？ #

针对全局互斥场景 #

直接用成熟框架替代手写锁逻辑：比如Redisson的可重入锁，它封装了原子加锁、自动续期、安全解锁等功能，还支持Redlock算法（多Redis实例部署，避免单节点故障导致锁失效），比自己手写Redis锁更可靠、更少踩坑。

针对业务维度互斥场景 #

如果不需要全局所有增删改都互斥，而是按特定业务维度（比如用户ID、订单ID）互斥，建议用动态锁键：

• 比如用户维度的增删改，锁键设为lock:user:{user_id}
• 订单维度的操作，锁键设为lock:order:{order_id}
  这样不同维度的操作可以并行执行，仅同一维度内互斥，既能满足互斥需求，又能提升系统并发能力。

其他替代方案 #

如果你的增删改操作都是针对数据库的，也可以考虑数据库层面的锁：

• 悲观锁：SELECT ... FOR UPDATE，适用于并发量不高的场景，但性能不如Redis锁。
• 乐观锁：通过版本号、时间戳字段实现，比如更新时校验WHERE id = ? AND version = ?，适合读多写少的场景，无锁等待，性能更高，但需要处理更新失败的重试逻辑。

内容的提问来源于stack exchange，提问作者ll kk