PHP并发防手抖：分布式锁的落地拆解与避坑指南

跑PHP的开发者都经历过这种噩梦：明明做了接口幂等，数据库加了唯一索引，上线后还是会出现超卖、重复发券、队列任务被多个FPM Worker反复吞掉的问题。多机部署环境下，传统的文件锁或内存变量根本管不到其他节点。这时候，分布式锁就成了缝合多实例竞争的必备胶水。别把它当成能解决一切并发问题的神器，它本质上是用外部存储给共享资源划一道同步围栏。围栏画得粗糙，不如不画。

选对基座并保证操作的原子性，是避开死锁的第一道防火墙。Redis因为内存读写极快且生态完善，成了绝大多数PHP项目的默认选择。但这里踩坑率最高的是经典写法：先用setnx抢锁，再单独调expire设超时时间。这两条命令分属两次网络请求，一旦中间发生断电或重启，锁就会永久滞留，直接卡死后续所有请求。必须用单次原子操作完成“加锁+设定生命周期”。现代Redis客户端直接调用SET key unique_value EX timeout NX即可，语法更短且天然不可分割。如果历史版本受限，务必将加锁逻辑封装成Lua脚本交付Redis服务端执行，利用其单线程特性阻断竞态。

抢到锁只是起点，如何优雅释放才是检验工程功底的试金石。不少团队为了图省事，释放时直接DEL对应的Key。这种做法在大促流量洪峰下极易翻车：假设业务逻辑耗时较长，超出预设超时时间，Redis被动清理了锁，此时另一个实例抢占了位置。原实例执行完毕后若盲目删除，等于顺手把别人的锁也给拆了。安全的释放路径是：持有方必须带唯一身份令牌写入，释放时先验明正身再动手。结合一段三行Lua脚本，先判断当前Value是否与持有令牌完全一致，匹配则放行删除，不匹配则静默返回。这一步能把误删概率压到零。

线上网络的波动从来不会准时按点下班。网卡延迟、PHP-FPM Worker回收、甚至垃圾回收停顿，都可能让持锁线程的执行节奏被打乱。面对这种不确定性，推荐采用“基础租期+异步心跳续命”的租期管理模式。主业务线程获取锁时只保留最短可用窗口（例如5秒），同时在后台拉起一个轻量级协程或定时任务，只要主逻辑还在运转，就每隔一定间隔向Redis发送一次PUBLISH或SETNX续期。一旦主线程意外崩溃，心跳中断，锁自然随TTL到期而回收。这种方式把状态维护和异常兜底彻底解耦，大幅降低人工干预成本。

架构设计层面，别一遇到资源竞争就往分布式锁上堆料。很多场景其实用乐观锁或纯数据库行锁就能干净解决。比如商品扣减，直接跑UPDATE stock SET num = num - 1 WHERE sku_id = ? AND num >= 1，一行语句把并发控制交给引擎自身消化，既省了缓存往返，又把复杂度收敛在事务隔离级别内。分布式锁真正该发力的地方，是跨越多个服务边界的复杂状态机流转，或者是无法靠单表约束覆盖的协调动作。动手前多推敲一层：有没有办法用消息重排、状态补偿或无锁数据结构绕开同步阻塞？能不用就不用。

分布式锁从来不是性能加速器，它是用短暂可用性交换强一致性的妥协方案。把原子加锁做扎实，用唯一标识防串场，配上合理的租期与重试退避机制，这套组合拳足以稳住十之八九的线上并发场景。把精力前置到接口幂等设计、任务拆分和流量削峰上，远比事后靠层层锁具来补救要从容得多。