TP6应对一万并发需四层协同：防提交（前端禁用按钮、AJAX锁、回车拦截、Token动态更新）、控执行（Redis分布式锁+唯一锁值+Lua安全解锁）、削流量（异步队列处理非核心逻辑）、保一致（缓存防击穿、Nginx/中间件限流、熔断降级、CDN静态资源）。
TP6 应对一万并发重复请求，不能靠单一手段，得从“防提交、控执行、削流量、保一致”四个层面协同处理。核心不是拦住所有请求，而是让系统在高压下不崩、不脏、不重、不丢。
前端快速拦截重复操作
用户连续点提交按钮、回车多次、F5刷新重发——这些是第一道洪水，必须在发出前挡住。
- 按钮点击后立即禁用：
$btn.prop('disabled', true)，成功/失败后才恢复； - 全局 AJAX 遮罩层 + 请求锁标志（如
isSubmitting = true），避免同一表单并发发多条； - 回车提交需额外加
event.preventDefault()+ 标志判断，防止键盘触发绕过按钮控制； - Token 不依赖页面刷新更新：AJAX 提交后，用接口单独获取新 Token 并写入 meta，下次请求即可复用。
后端加分布式互斥锁
前端拦不住全部（比如脚本刷、Postman 模拟），真正关键资源（如下单、扣库存）必须服务端强锁。
- 用 Redis
SET key value NX PX 30000原子加锁，TP6 推荐写法：$redis->set('lock:order:'.$orderId, $reqId, ['nx', 'px' => 30000])； - 锁值必须唯一且可识别（如
server_ip:pid:timestamp:rand），避免 A 加锁超时释放后被 B 占用，结果 A 又误删； - 解锁必须 Lua 脚本校验：
if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end； - 超时时间按业务 P95 耗时 + 缓冲设置（如下单平均 800ms，设 5s），太短易误释放，太长易死锁。
异步化耗时流程
一万并发若全同步处理，数据库和 PHP 进程立刻打满。把“响应快”和“事情做完”拆开。
立即学习“PHP免费学习笔记（深入）”；
- 用户提交后，校验通过即返回“已受理”，立刻入队（Redis LIST 或 RabbitMQ）；
- 订单创建、发短信、写日志等非核心链路全扔进队列，由独立 worker 异步消费；
- TP6 用
think-queue+ Redis 驱动足够支撑万级 QPS，注意配置pool_size和retry_after； - 关键动作（如库存扣减）仍需在队列任务里再次加锁，避免多个 worker 同时消费同一商品导致超卖。
缓存与限流兜底
当瞬时流量远超承载能力，主动降级比硬扛更稳妥。
- 高频读接口（如商品详情）强制走 Redis 多级缓存，失效时用布隆过滤器+空值缓存防击穿；
- API 层加限流：Nginx 用
limit_req控制 IP 级每秒请求数，TP6 中间件用令牌桶做业务级限流（如每人每分钟最多提交 3 次订单）； - 熔断设计：当 DB 错误率 > 30% 或队列积压 > 1w 条，自动关闭非核心入口（如评价提交、优惠券领取），保障主链路可用；
- 静态资源、图标、JS/CSS 全部 CDN 化，减轻应用服务器压力。
