PHP Webman分布式锁实现_Webman利用Redis防止任务重复执行【方案】

必须用SET key value NX EX原子命令加锁，value为唯一标识，解锁须用Lua脚本校验value后删除，防止误删；多worker需用pid等区分value，定时任务锁key应含时间维度，失败用Timer::after延迟重试。 Webman 项目里用 Redis 做分布式锁，核心就一条：别直接用+两步走，必须用原子命令，否则必然出现锁没设上但过期时间已写入的竞态漏洞。 Webman 中如何安全加锁（非 Laravel，无框架封装） Webman 是基于 Swoole 的轻量级框架，不自带分布式锁组件，得自己封装。关键不是“能不能加锁”，而是“加锁失败后是否误判”“释放锁时会不会删掉别人持有的锁”。 加锁必须用 ， 必须是当前进程/协程唯一标识（如 ），不能写死成 或 不要用 + 组合——这两步非原子，Redis 网络延迟或进程崩溃在中间时，会留下无过期时间的死锁 key Webman 多 worker 场景下， 要能区分不同 worker，建议拼上 或 锁的 必须大于业务最大执行时间（含网络、DB、第三方调用），否则任务未完锁先丢，多个 worker 同时进入临界区 释放锁必须校验 value 一致性 直接 是危险操作——A 拿到锁，执行慢超时自动释放；B 在 A 超时后抢到锁，A 接着执行完却把 B 的锁删了。后果是后续请求全部绕过锁。 释放锁必须用 Lua 脚本保证原子性： Webman 中可封装为 方法，内部调用 如果 Lua 不可用（如某些云 Redis 服务禁用 EVAL），退而求其次：先 校验再 ，但需接受极小概率的误删（加锁时设足够长 ttl 可缓解） 定时任务去重场景下的典型陷阱 Webman 配合 Cron 或 命令跑定时任务时，多实例部署极易重复触发。此时锁不是加在“整个命令入口”，而是加在“具体任务逻辑块”上。 PHP 8.5.5 PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。 下载 立即学习 “ PHP免费学习笔记（深入） ”； 错误做法： 启动多个 worker，每个都跑 ，然后在命令 handle 里对整个方法加锁——这锁不住，因为命令是新进程， 和 pid 完全不可控 正确做法：把锁 key 设为任务名 + 时间维度（如 ），在真正处理数据前加锁，且确保所有实例连接的是同一个 Redis 实例（不能连错 DB 或集群分片） 注意 Webman 的 插件默认每秒扫描一次，高频扫描 + 锁竞争会导致 Redis QPS 暴增，建议把扫描间隔拉长到 5–10 秒，或改用外部系统（如 Linux cron）触发 若任务本身有幂等标识（如订单号、批次 ID），优先用数据库唯一索引或 Redis 做业务层幂等，锁只是兜底 锁失效后如何安全重试 锁不是万能的。当 返回 false，说明锁被占，但你不能简单 ——这会压垮 Redis，也违背 Webman 异步非阻塞的设计初衷。 Webman 中推荐用 延迟重试，避免同步阻塞 worker；例如首次失败后 2 秒后再试，最多 3 次 重试逻辑要记录日志，比如 对非关键任务，可直接返回“跳过本次执行”，避免雪球效应；对关键任务（如支付回调处理），应抛出异常并由监控系统告警人工介入 别忽略 Redis 连接失败场景： 失败时， 会报错，需捕获 并降级为本地锁（仅限单机）或直接拒绝 最易被忽略的一点：Webman 的多 worker 共享一个 Redis 连接池时， 和 的 必须严格一致——字符串编码、空白符、大小写都不能差，否则 Lua 脚本比对永远失败，锁永远删不掉。