PHP OpCache、Redis与Memcached多级缓存优化实战-php教程-PHP中文网

opcache必须启用并配置为生产模式（opcache.validate_timestamps=0），redis适合结构化热点数据，memcached适用于高并发简单键值读；三者按场景分层协作，非简单二选一。

php opcache、redis与memcached多级缓存优化实战

OpCache 必须开，Redis 和 Memcached 不是二选一，而是按场景分层用。 多级缓存不是堆砌工具，而是让每层干它最擅长的事：OpCache 拦住 PHP 解析编译，Redis 管结构化热点数据，Memcached 抢简单键值的高并发读。

常见错误是改了 php.ini 但没重启 PHP-FPM 或 Apache，或者生产环境仍开着 opcache.validate_timestamps=1，导致每次请求都校验文件时间戳，完全抵消加速效果。

opcache.validate_timestamps=0 是生产环境刚需，配合部署流程（如发布后 opcache_reset()）保证更新可见
opcache.memory_consumption 至少设为 128，小项目 256 更稳；opcache.max_accelerated_files 要覆盖你实际加载的文件数，低于该值会导致旧文件被挤出
CLI 模式默认不启用 OpCache，需显式加 opcache.enable_cli=1 才能加速 Artisan 命令或脚本
验证是否生效：调用 opcache_get_status()，看 opcache_enabled 为 true 且 memory_usage.used_memory 在增长

Redis 不是万能筐。存错结构或数据量失控，反而拖慢响应、挤占内存、触发频繁淘汰。

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

适合：用户会话（user:123）、排行榜（zset）、带过期的配置项（config:api_timeout）、小而热的关联数据（如 post:456:author）
不适合：原始日志、未压缩的 HTML 片段、超过 10KB 的序列化大对象——这类应走文件缓存或 CDN
哈希（HSET）比字符串（SET）省内存，但字段过多（>1000）时查单个字段反而变慢；不如拆成多个 key
用 EXPIRE 或 SETEX 显式设 TTL，避免全库扫描清理；对冷数据，考虑 LFU 淘汰策略（Redis 6+）

Memcached 的毫秒级延迟优势，来自无持久化、无复杂数据结构、纯内存 + slab allocator 设计。但它也更“脆”：不支持原子操作、无数据类型、挂了就全丢。

$memcached->addServer() 后必须确认连接成功，否则 get() 返回 false 容易被当成缓存未命中去查 DB
Slab class 大小决定你能存多大的 value；默认最大 chunk 是 1MB，但若你存 800KB 的序列化数组，可能因无法复用 slab 导致内存浪费
批量读用 getMulti()，别循环 get()；写入前先 delete() 再 set()，避免旧值残留（Memcached 不自动覆盖过期 key）
和 Redis 不同，Memcached 不区分连接池；高并发下建议用 libmemcached C 扩展而非纯 PHP 实现

真实线上故障往往始于一个高频查询的 get('user:9999999')——ID 根本不存在，却反复穿透到 DB。

穿透：对非法/不存在 key，缓存空对象（如 set('user:9999999', null, 60)），并加布隆过滤器前置拦截（PHP 可用 redis-bloom 扩展）
击穿：热门 key 过期瞬间大量请求涌向 DB，用互斥锁（SETNX user:123_lock 1 EX 3）只放行一个回源请求
雪崩：大批 key 同一时刻过期，把 TTL 加随机偏移（如 3600 + rand(0, 300)），别写死整点
所有缓存读写都要有 fallback：get() 返回 false 时，不是直接报错，而是触发 load-from-db + set() 流程