PHP用Redis实现分布式锁需满足互斥性（SET key value NX EX）、锁归属验证（唯一value）和安全释放（Lua脚本）；消息队列按场景选List（FIFO）或Sorted Set（延迟/优先级），锁key须带业务ID，过期时间需大于最大执行耗时。
PHP 环境中用 Redis 扩展实现分布式锁和消息队列，核心在于两个基础能力：原子性操作支持与数据结构适配。不需要额外中间件，只要 PHP 安装了 phpredis（推荐 5.3+）或 predis，并能正常连接 Redis 服务，就能落地这两类关键机制。
分布式锁必须满足的三个硬性条件
不是简单 set/del 就算锁——它得真正可靠：
-
互斥性：同一时刻仅一个客户端能成功加锁。靠
SET key value NX EX 30命令实现，NX保证键不存在才写入，EX设置自动过期时间（如 30 秒），两者必须原子执行，不能拆成setnx + expire两步 -
锁归属验证：解锁时必须确认是自己加的锁。value 必须是客户端唯一标识（例如
uniqid('', true)生成的字符串），避免 A 加锁超时释放后，B 拿到锁，A 却误删 B 的锁 -
安全释放：解锁操作必须原子。使用 Lua 脚本执行
GET + DEL判断再删除，Redis 保证整个脚本一次性执行完毕，杜绝竞态
消息队列选型：List 还是 Sorted Set？
根据业务需求选择合适的数据结构：
-
简单 FIFO 场景（如发短信、日志归档）：用 List。生产者用
LPUSH queue:send sms_123入队，消费者用RPOP queue:send出队。注意高并发下RPOP可能返回 null，建议改用BRPOP queue:send 1阻塞等待，避免空轮询 -
需按优先级/延迟执行（如定时任务、重试队列）：用 Sorted Set。把执行时间戳作为 score，任务内容为 member：
ZADD queue:delay 1748000000 {"job":"sync_user","id":1001}。消费者用ZRANGEBYSCORE queue:delay -inf 1747999999 LIMIT 1拉取到期任务，处理完再ZREM
PHP 代码里最容易踩的坑
不是逻辑写错，而是细节没控住：
立即学习“PHP免费学习笔记（深入）”；
-
锁 Key 没带业务维度：写死
"order_lock"会导致所有订单串行处理。应拼接业务 ID，例如"lock:order:{$order_id}"或"lock:stock:sku_{$sku_id}" - 过期时间设得太短：锁过期时间必须明显大于业务最大执行耗时。比如下单逻辑平均 800ms，建议设 5～10 秒；若涉及远程调用，预留网络抖动余量
- 没做连接异常兜底：Redis 连接失败时，不要直接跳过加锁——应记录告警并拒绝请求（降级），而不是让临界区裸奔
扩展能力：从单点锁到可用锁
生产环境不能只依赖单个 Redis 实例：
- 单机 Redis 故障即锁失效。若要求更高可用，可基于 Redis Sentinel 做主从切换，PHP 客户端配置哨兵地址即可自动发现新主节点
- 集群模式下（Redis Cluster），key 被分片，
EVAL脚本涉及多个 key 会报错。此时锁 key 必须确保落在同一 slot（例如加{...}标签："{order}123"），或改用 Redlock 算法（需多数节点加锁成功） - 不建议在 PHP-FPM 场景下实现锁自动续期（“看门狗”），因子进程生命周期不可控；更稳妥的是预估耗时 + 冗余过期时间
