高并发抢单核心是“拦得住、锁得准、扣得稳”，需借redis分布式锁（set nx+ex）、原子化库存扣减（sql where校验或decrby+lua）、前置拦截无效流量，并辅以异步化与完备的超时降级机制。
高并发抢单的核心不是“写得快”，而是“拦得住、锁得准、扣得稳”。PHP本身是共享内存模型弱、无原生线程的脚本语言，直接靠代码逻辑硬扛高并发必然失败。关键在于借助外部组件做资源隔离与原子控制，PHP只负责协调和校验。
用 Redis 实现分布式秒杀锁（推荐）
Redis 的 SETNX + EXPIRE 或原子命令 SET key value EX seconds NX 是最常用且可靠的抢锁方式。它天然支持分布式、毫秒级响应、自动过期防死锁。
- 用户请求来时，先尝试用唯一订单/用户+商品ID拼接 key，执行
SET lock:goods_123:uid_456 "1" EX 10 NX - 返回 1 → 抢锁成功，继续后续库存校验与扣减；返回 nil → 已被抢走，直接返回“手慢了”
- 务必设置合理过期时间（如 10 秒），避免进程崩溃导致锁永久占用
- 不建议用 Redis 的 GETSET 或 WATCH/MULTI，前者无法判断旧值，后者在高并发下失败率高、开销大
库存扣减必须原子化，禁止先查后减
“SELECT stock FROM goods WHERE id=123” → “UPDATE goods SET stock=stock-1 WHERE id=123 AND stock>0” 是经典幻读陷阱：两个请求同时查到 stock=1，都执行 update 成功，超卖。
- 正确做法：用一条 SQL 完成校验与扣减，例如：
UPDATE goods SET stock = stock - 1 WHERE id = 123 AND stock >= 1 - 执行后检查 affected_rows === 1，为 0 表示库存不足或已被扣完
- 若用 Redis 存库存（更推荐），则用
DECRBY stock:123 1，再用GET判断结果是否 ≥ 0；或用 Lua 脚本封装“判断+扣减”原子逻辑
前置拦截：层层过滤无效流量
80% 的并发压力来自无效请求，应在到达业务层前就挡掉。
- 前端加按钮置灰 + 防重复提交（禁用 Submit 按钮、加 loading 状态）
- Nginx 层做简单限流（limit_req），或用 OpenResty + Lua 做用户级令牌桶
- PHP 接口层校验登录态、活动时间、用户资格（如黑名单、限购数）、商品状态（上架/售罄）
- 所有校验失败立即 return，不进数据库/Redis，减少下游压力
异步化与最终一致性（可选增强）
对极致一致性要求不高（如普通团购），可将“下单成功”和“真实扣库存”解耦：
- 抢锁成功 → 写入 MQ（如 RabbitMQ/Kafka）一条“抢单申请”消息
- 由消费者服务串行消费，执行库存扣减、订单生成、通知等
- 用户端显示“排队中”，通过轮询或 WebSocket 返回最终结果
- 优势：削峰填谷、避免 DB 瞬时压力爆炸；劣势：体验稍延迟、需处理消息幂等与失败重试
不复杂但容易忽略：每个环节都要有超时、重试、降级和日志。比如 Redis 连接超时要 fallback 到本地缓存（仅作兜底），扣库存失败要记录明细便于对账。真正的高并发能力，藏在边界处理里，不在主干逻辑中。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
