高并发下PHP需异步化和缓存防护：用Redis List实现轻量队列，避免阻塞操作；通过互斥锁、随机过期、空值缓存防击穿雪崩；必须监控队列长度、缓存命中率及设置降级开关。
高并发下直接写数据库必挂，必须切走耗时操作
PHP 本身是阻塞式同步模型，每个请求独占一个 FPM 进程。一旦出现大量请求同时执行 INSERT 或复杂查询，数据库连接池打满、锁表、慢查询堆积，响应时间指数级上升，502/504 频发。
核心思路不是“优化 SQL”，而是“让请求不等结果”：把真正要做的动作（比如发通知、更新统计、写日志）挪到后台异步执行。
- 用户下单成功后，立即返回订单号，
order_created事件丢进队列，由独立 worker 消费并写库 - 避免在
$_POST处理逻辑里调用file_put_contents()或curl_exec()等阻塞操作 - 注意 PHP-FPM 的
pm.max_children设置，它决定了你最多能扛多少并发请求——但前提是这些请求都足够轻量
Redis + List 做轻量队列比 RabbitMQ 更快上手
中小项目不用一上来就上 RabbitMQ 或 Kafka。Redis 的 LPUSH + BRPOP 组合足够应对万级 QPS 的任务分发，延迟低、无额外服务依赖。
典型错误是用 GET/SET 模拟队列，导致轮询和并发冲突；或者用 MySQL 表存队列，结果队列表自己成了瓶颈。
立即学习“PHP免费学习笔记（深入）”；
- 生产端用
$redis->lPush('queue:notify', json_encode($payload)) - 消费端用
$redis->brPop(['queue:notify'], 30)，阻塞等待，不空转 CPU - 消费失败时别直接
DEL，先lPush回原队列末尾，并加重试计数字段，避免死信堆积 - 单个 worker 进程不要长期运行——用 supervisord 管理，崩溃后自动重启，防止内存泄漏累积
缓存击穿和雪崩不是理论问题，是上线当天就会遇到的坑
当热点数据（比如首页商品列表）过期瞬间，大量请求穿透到数据库，MySQL CPU 直冲 100%，这就是缓存击穿；如果所有缓存集中在同一时间过期，就是雪崩。
用 cache->get('goods:list') + if (!$data) { $data = $db->query(...); cache->set(...); } 这种写法，在并发下会反复查库。
- 对关键 key 加互斥锁：
$redis->set('lock:goods:list', 1, ['nx', 'ex' => 5])，只有拿到锁的请求去查库并回填缓存 - 过期时间别设成固定值，加随机偏移：
$ttl = 3600 + rand(1, 600)，分散失效时间 - 永远保留“空值缓存”：
cache->set('goods:id:999', null, 60)，防止恶意 ID 频繁穿透 - 不要依赖
memcached的 CAS 操作做锁——PHP 的Memcached::cas()在高并发下容易失败，不如 Redis 原生命令可靠
队列和缓存不是加了就完事，得监控它们是否真的在工作
没监控的队列等于没队列。你永远不知道 worker 是否卡住、Redis 是否连不上、缓存是否大面积失效。
最容易被忽略的是“缓存降级开关”和“队列积压告警”——系统出问题时，宁可返回旧数据或默认值，也不能让用户干等。
- 定期用
$redis->llen('queue:notify')查长度，超过阈值（如 10000）立刻告警 - 在关键路径埋点：
Cache::hit()/Cache::miss()记录比率，命中率掉到 80% 以下就得查原因 - 给所有异步任务加超时控制：
set_time_limit(30)放在 worker 脚本开头，防止单个任务拖垮整个进程 - 别把
serialize()后的数据直接塞 Redis——PHP 7.4+ 默认序列化格式不兼容老版本，跨环境部署极易出错；统一用json_encode()
