php高并发排队必须用redis实现原子化队列，禁用文件锁/session；核心是lpush/lpos/lpop组合+唯一订单号+过期机制，配合服务端频控缓存与独立常驻消费者进程。
PHP 本身没有内置的高并发排队机制，直接用 sleep() 或文件锁模拟队列，在真实高并发场景下会迅速崩掉——这不是代码写得不够“优雅”，而是模型错了。
为什么不能用 session 或文件锁做排队
常见错误是：用户请求进来，先写一个 queue.lock 文件，再读取当前排队位置，最后 unlink()。问题在于：
- 文件系统 I/O 在并发高时成为瓶颈，
flock()争抢严重，甚至出现死锁或漏锁 - PHP-FPM 进程间不共享内存，
$_SESSION是单进程视角，无法跨 worker 感知全局排队状态 - 如果某个请求超时或崩溃，锁没释放，整个队列就卡死
- 横向扩容后，多台机器之间完全无法同步排队序号
用 Redis 实现原子化排队（推荐方案）
核心是利用 Redis 的 LPUSH + LLEN + LPOP 组合，配合过期时间与唯一 Token，保证入队、查位、出队三步都可回溯且不重复。
示例关键逻辑：
立即学习“PHP免费学习笔记（深入）”；
if (Redis::command('EXISTS', 'queue:order:' . $order_id)) { // 已存在，直接返回排队位置 $pos = Redis::command('LPOS', 'queue:main', $order_id) + 1; } else { // 入队（带 10 分钟过期，防堆积） Redis::command('LPUSH', 'queue:main', $order_id); Redis::command('EXPIRE', 'queue:main', 600); // 记录该订单元信息，含创建时间、用户ID等，用于后续校验 Redis::command('HSET', 'queue:order:' . $order_id, 'uid', $uid, 'ts', time()); $pos = Redis::command('LLEN', 'queue:main'); }注意点：
- 不要依赖
LLEN实时算位置——它在大列表中性能差，应改用LPOS查索引（Redis 6.0.6+） - 必须给每个排队项绑定唯一标识（如订单号），避免不同用户共用同一位置
-
LPOP只应在后台消费者进程里调用，Web 请求只负责入队和查位，不主动触发处理
如何防止用户反复刷“我的排队位置”
前端频繁轮询会放大后端压力，但又不能完全禁止查询。折中做法是服务端加一层轻量缓存 + 频控：
- 每次查位置前，先检查
cache:pos:{$order_id}是否存在，有则直接返回（TTL 设 2–3 秒） - 若缓存未命中，才走 Redis 队列查；查完立刻写回缓存，并附带一个
last_update时间戳 - 对同一
$order_id，限制 5 秒内最多查 2 次，超出则返回 “请稍后再试”，响应码 429 - 避免用 IP 做频控——用户可能走代理或 NAT，误伤面太大；优先绑定业务 ID
后台消费进程必须独立部署
排队只是第一步，真正难的是稳定、可控地执行队列任务。绝不能把消费逻辑塞进 Web 请求生命周期里：
- 用
php artisan queue:work --daemon（laravel）或自建while(true)+LPOP循环，常驻运行 - 每消费一条，先
HGETALL queue:order:xxx校验合法性，再执行业务，成功后DEL queue:order:xxx - 必须设置最大重试次数（如 3 次），失败任务转入
queue:failed，人工干预 - 进程要监听
SIGTERM，支持平滑重启，避免正在处理的任务被中断
真正棘手的不是“怎么排”，而是“谁来清”和“排错了怎么办”。Redis 队列能扛住万级 QPS 入队，但一旦消费者延迟或异常，积压数据就会快速膨胀——监控 queue:main 长度、各订单的 ts 时间戳、失败队列条目数，比写对入队逻辑更重要。