Webman分布式锁原理与资源竞争解决方案

在Webman多worker、多实例的高并发场景下，分布式锁设计稍有不慎就会引发死锁、误删、重复执行等确定性数据事故；必须严格采用SET key value NX EX原子命令加锁，value嵌入pid与uniqid确保唯一性，锁粒度精准覆盖DB操作逻辑块而非命令入口，key需携带时间维度以隔离不同周期任务，所有实例共用同一Redis DB，并通过Lua脚本实现安全解锁——任何看似“简单”的替代方案（如setnx+expire、GET+DEL、固定value、全局new Redis）在长时任务、协程中断或进程重启下都会暴露致命竞态，线上稳定性的底线就藏在这一个个不可妥协的细节里。

Webman 多实例部署下，不加分布式锁就跑定时任务或共享写操作，必然重复执行、数据错乱——这不是概率问题，是确定性事故。

为什么 setnx + expire 组合在 Webman 里绝对不能用

Webman 基于 Swoole，worker 进程常驻内存，网络延迟或协程中断时，setnx() 成功但 expire() 失败，就会留下一个无过期时间的 key。这个 key 不会自动消失，后续所有加锁请求都失败，整个业务卡死。

• 必须用原子命令：$redis->set($key, $value, ['NX', 'EX' => $ttl])
• $value 不能是固定字符串（如 '1'），必须带上下文唯一性，推荐 getmypid().'_'.uniqid('', true)
• Webman 的多 worker 场景下，只用 uniqid() 有极小概率碰撞，拼上 getmypid() 才真正隔离

定时任务去重，锁要加在“处理逻辑块”，不是命令入口

很多人把锁写在 php webman task:run --name=sync_order 的 handle 方法开头，这是无效的：命令行启动的是全新 PHP 进程，getmypid() 和 uniqid() 完全不可控，不同实例生成的 $value 可能相同，导致锁校验失效。

• 真正该加锁的位置，是 DB 查询/更新那几行代码之前，例如 Db::table('orders')->where('status', 'pending')->update(...) 前
• $key 必须含时间维度，比如 task:sync_order:20260525 或 task:sync_order:hour_12，避免昨天和今天的任务互相干扰
• 所有 Webman 实例必须连同一个 Redis DB（注意不是不同 cluster 分片），否则锁根本不同步

解锁必须走 Lua 脚本，GET + DEL 是危险幻觉

直接 $redis->del($key) 看似简单，但在 Webman 长耗时任务中极易出事：A 拿到锁，执行慢超时，Redis 自动删 key；B 紧接着抢到锁开始执行；A 此时刚好完成，调用 del —— 删掉的是 B 的锁。

• 正确解锁方式：$redis->eval("if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end", 1, $key, $value)
• 如果所用云 Redis 禁用 EVAL（如某些阿里云 Redis 社区版），只能退化为 GET 校验后 DEL，但必须把 $ttl 设得足够长（比如任务最长可能耗时 300 秒，$ttl 至少设 600），用时间换安全余量
• 别信“我测试了几十次都没问题”——竞态窗口极小，但线上一旦触发就是批量数据错误

Webman 连接池与锁生命周期的隐性冲突

Webman 使用 webman/redis 扩展时，默认连接池复用连接。但如果加锁和解锁不在同一个协程上下文（比如锁在主协程加，解锁在 Timer::after 回调里），可能拿到不同连接，而 Lua 脚本的原子性依赖单连接上下文。

• 确保加锁和解锁使用同一个 Redis 实例对象（例如通过 DI 容器注入或静态缓存）
• 不要在 onWorkerStart 里 new Redis 并赋给全局变量，Swoole 多进程间无法共享资源，会导致连接错乱或序列化失败
• 若任务需异步解锁（如失败后延迟重试），建议把 $key 和 $value 传进回调，仍用同一个 Redis 实例执行 Lua

最易被忽略的一点：Webman 的定时任务往往由系统 crontab 触发，但实际执行逻辑在 worker 进程内——这意味着锁的持有者是 worker，不是 crontab 进程。一旦 worker 重启或 reload，锁可能残留，所以 $ttl 不仅要大于业务耗时，还得预留进程启停缓冲时间。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。