Redis分布式锁应使用SET命令原子性加锁，配合唯一标识、过期时间和Lua脚本安全释放；锁粒度需细化到业务ID；PHP-FPM下须依赖自动过期而非客户端清理。
Redis 实现分布式锁：用 SET 命令加原子性保障
PHP 里最常用、最快落地的分布式锁方案是 Redis，但别直接用 SETNX + EXPIRE 两步走——这会因网络延迟或进程崩溃导致锁无法释放，形成死锁。
正确做法是使用带过期时间和原子性的 SET 命令：
SET lock:order:123 "8f4d6a" EX 30 NX
其中 "8f4d6a" 是客户端唯一标识（建议用 uniqid('', true) 生成），EX 30 设定 30 秒自动过期，NX 确保只在 key 不存在时设置成功。
- 获取锁失败时，不要立即重试，应加随机短延时（如
usleep(rand(10000, 50000))）避免羊群效应 - 释放锁必须用 Lua 脚本校验 value 是否匹配，防止误删别人持有的锁：
EVAL "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end" 1 lock:order:123 8f4d6a - 业务执行时间必须严格小于锁过期时间；若可能超时，需另起协程/定时器续期（即 “看门狗”），但 PHP-FPM 场景下续期较难实现，更推荐预估+冗余时间（如设 60s 过期，业务逻辑控制在 45s 内）
ZooKeeper 方案：适合强一致性场景，但 PHP 生态支持弱
ZooKeeper 的临时顺序节点天然适配分布式锁，可靠性高于 Redis，但 PHP 缺乏成熟、维护活跃的原生客户端。当前主流选择是通过 zkCli.sh 或封装好的 CLI 工具间接调用，或改用 Go/Java 做锁服务网关。
如果你坚持 PHP 直连 ZooKeeper，可用 ext-zookeeper 扩展（需手动编译安装），但要注意：
- 该扩展已多年未更新，不兼容 PHP 8.1+，且连接异常处理粗糙，容易卡死进程
- 加锁流程为：创建临时顺序节点 → 获取所有子节点 → 判断自己是否序号最小 → 不是最小则监听前一个节点的删除事件
- ZooKeeper 的 session timeout 默认 40s，而 PHP 请求生命周期通常远小于此，频繁重建连接会导致大量临时节点残留，必须配合健康检查和清理脚本
锁粒度与业务耦合：别锁整个订单表，要锁具体订单 ID
分布式锁的价值在于精准控制并发点，不是“越严越好”。常见错误是把锁键写成固定字符串如 "order_lock"，结果所有订单串行处理，吞吐归零。
正确方式是让锁 key 包含业务上下文：
- 扣减库存：用
"stock:sku_1001"，而非"stock_lock" - 支付回调幂等：用
"pay:notify_" . md5($out_trade_no)，确保同一笔订单回调只被处理一次 - 避免 key 过长或含特殊字符；Redis key 最好控制在 256 字节内，且不含空格、换行、控制字符
- 高并发下 key 命中率影响 Redis 性能，可考虑对 ID 做简单哈希分片（如
"lock:order:" . ($order_id % 16)），但仅当单 key 成为瓶颈时才需要
PHP-FPM 环境下的陷阱：锁失效、进程复用、信号中断
FPM worker 复用、请求超时 kill、SIGTERM 中断这些底层行为，会让很多看似正确的锁逻辑静默失败。
- 不要在
register_shutdown_function()里释放锁——它不一定被执行（比如 FPM 被kill -9或超时强制终止） - 不要依赖
__destruct()清理锁——对象可能被 GC 延迟回收，甚至不回收（循环引用） - PHP 的
pcntl_signal()在 FPM 下基本不可用，无法可靠捕获中断信号来主动解锁 - 真正稳妥的做法是：锁必须设过期时间（靠 Redis/ZK 自动清理），释放操作只作为“尽力而为”的优化，不能作为唯一保障
锁最难的部分从来不是怎么加，而是怎么在各种非理想条件下确保它既不漏放、也不死锁。尤其是 PHP 这种无状态、生命周期不可控的语言，过度依赖客户端逻辑做锁管理，比选 Redis 还危险。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
