PHP如何用缓存降低API压力

缓存核心是命中、失效及时且不拖慢响应；仅适用于读多写少、变化不频繁、允许短暂过期的接口，如商品详情、配置列表；禁用场景包括订单状态、实时消息等；需按请求参数构造key、结构稳定；单机用APCu，集群用Redis；更新策略推荐先删缓存再延迟双删。

用缓存减轻 PHP API 压力，核心不是“加一层缓存”，而是让缓存真正命中、及时失效、不拖慢响应——否则反而增加延迟和内存开销。

判断哪些接口适合加缓存

缓存只对「读多写少、数据变化不频繁、允许短暂过期」的接口有效。比如商品详情、配置列表、地区字典；但用户订单状态、实时聊天消息、支付回调结果这类绝对不能简单缓存。

• GET 请求且无敏感参数（如 user_id、token）才考虑全量缓存
• 带分页参数的接口（如 page=2&limit=10），需把完整查询字符串作为缓存 key 的一部分
• 返回 JSON 且结构稳定（避免缓存了空数组或 null 导致前端报错）

选对缓存方式：APCu vs Redis vs 文件缓存

本地缓存快但不共享，分布式缓存可共享但有网络开销。单机部署用 apcu_store() 足够；集群环境必须用 Redis，否则节点间缓存不一致。

• apcu_store() 适合高频、短时效（<10 秒）、无需跨进程同步的数据，比如接口调用计数器
• Redis::setex() 是最常用选择，支持自动过期、原子操作，key 建议带前缀如 "api:product:123"
• 别用 file_put_contents() 做缓存——并发写入容易损坏文件，且 I/O 比内存慢 2~3 个数量级

绕不开的缓存穿透与雪崩问题

缓存穿透是查一个根本不存在的 ID（比如 /api/user/999999999），导致每次请求都打到 DB；缓存雪崩是大量 key 同时过期，DB 瞬间被压垮。

• 对空结果也缓存（如 Redis::setex("api:user:999999999", 60, "null")），但 value 要能区分“真空”和“查无此 ID”
• 设置随机过期时间：基础 TTL 设为 300 秒，再加 ±60 秒抖动，避免集中失效
• 关键接口加 mutex 锁：查不到缓存时，用 Redis::set("lock:api:user:123", 1, ["nx", "ex" => 5]) 防止多个请求同时重建缓存

缓存更新策略：先删缓存，还是先改 DB？

写操作发生时，缓存必须失效或更新，否则一致性立刻破坏。推荐「删除缓存 + 延迟双删」而非更新缓存。

• 修改 DB 后立即 Redis::del("api:product:123")，下次读自动重建——简单可靠
• 如果 DB 更新失败，缓存没删，最多旧数据多活几秒；但如果删缓存失败而 DB 更新成功，就会永久脏数据
• 高一致性场景（如库存扣减）可在 DB 更新后，再删一次缓存（即「双删」），中间加 sleep(100) 或异步队列确保主从同步完成

最难的从来不是加缓存，而是决定哪条数据该缓存多久、谁来负责清理、出错时怎么降级——这些逻辑一旦散落在各处，比没缓存还难维护。