WordPress 对象缓存：Redis 到底能解决什么问题

对象缓存与页面缓存的分工

WordPress 每次页面请求都会走 WP_Object_Cache，把 options、posts、terms、transients 等查询结果放在 PHP 数组里，请求结束即销毁。对象缓存是把这个数组外置到 Redis，跨请求复用，减少 MySQL 查询。

页面缓存（如 Nginx FastCGI Cache、WP Rocket 生成的静态 HTML）是在 Web 层直接吐 HTML，根本不进 PHP 和 MySQL。两者是不同层：页面缓存挡在前面，对象缓存兜住漏过来的动态请求。

2026 年 WordPress 6.8 仍默认只带内存态 WP_Object_Cache，需靠 object-cache.php drop-in 切到 Redis。官方说明见 developer.wordpress.org WP_Object_Cache。若站点动态请求多（WooCommerce、会员中心、REST API），Redis 才有意义；纯文章站开页面缓存即可。

我们给客户做 WordPress 企业网站开发 时，会先画请求链路图，确认对象缓存补的是哪一段，再动 Redis。

分工对照表

层	代表方案	生效位置	解决什么
页面缓存	Nginx Cache / WP Rocket	Web 服务器	整页 HTML 直出，不进 PHP
对象缓存	Redis + drop-in	PHP 内 wp_cache	复用 DB 查询结果，降 MySQL 负载
数据库	MySQL / MariaDB	存储引擎	持久化，兜底所有未命中

什么负载下才有收益

Redis 不是万能提速器。单台小站每天几千 PV、MySQL 查询在个位数毫秒时，加 Redis 反而多一跳网络开销，TTFB 可能变差。

有收益的典型负载：并发动态请求高（后台编辑、WooCommerce 结账、未登录用户也被 CDN 回源到动态）、MySQL 慢查询日志里大量 SELECT wp_options / wp_postmeta、QPS 超过 200 且 PHP 进程常等 DB。

判断方法：在 MySQL 开 slow log，long_query_time = 0.5，跑一天。若 wp_options 的 autoload 查询、wp_posts 按 ID 取单条占比高，且这些能被 wp_cache_get/set 覆盖，就值得上。

2026 年云 Redis 延迟普遍在 0.2-0.5ms，同可用区内几乎无损；跨区或走公网则不要用于对象缓存。可用 redis-cli --latency -h 10.0.0.5 实测。

实施步骤：从零接入 Redis 对象缓存

1. 确认 PHP 装了 redis 扩展：php -m | grep redis，没有则 apt install php8.3-redis（2026 年主流 PHP 8.3）。
2. 安装 Redis 服务：apt install redis-server，改 /etc/redis/redis.conf 的 maxmemory 256mb 与 maxmemory-policy allkeys-lru。
3. 站点装 Redis Object Cache 插件，或手工把 object-cache.php 放到 /wp-content/。
4. wp-config.php 加 define('WP_REDIS_HOST', '10.0.0.5'); 与 define('WP_CACHE_KEY_SALT', 'mysite_');。
5. 后台启用 Object Cache，或执行 wp redis enable（WP-CLI）。
6. 用 redis-cli 监控：redis-cli info stats | grep keyspace，并压测对比 TTFB。

最小可运行示例

下面是一段不依赖插件的最小 object-cache.php 片段，演示 wp_cache_get/set 如何落到 Redis。生产请用成熟 drop-in，此处只为讲机制：

<?php
// wp-content/object-cache.php 最小示意，勿直接用于生产
class Mini_Redis_Cache {
    private $redis;
    private $prefix = 'mysite_';
    public function __construct() {
        $this->redis = new Redis();
        $this->redis->connect('10.0.0.5', 6379);
    }
    public function get($key, $group = 'default') {
        $val = $this->redis->get($this->prefix . $group . '_' . $key);
        return $val === false ? false : maybe_unserialize($val);
    }
    public function set($key, $data, $group = 'default', $expire = 0) {
        $val = maybe_serialize($data);
        return $this->redis->set($this->prefix . $group . '_' . $key, $val);
    }
}
$GLOBALS['wp_object_cache'] = new Mini_Redis_Cache();

真实 drop-in 要实现 add、delete、flush、incr 等全部 WP_Object_Cache 接口，并处理非持久化组（如 wp_cache_add_non_persistent_groups）。

缓存命中率怎么看

命中率 = hits / (hits + misses)。Redis 侧用 redis-cli info stats 看 keyspace_hits 与 keyspace_misses：

redis-cli info stats
# Keyspace
keyspace_hits:84213
keyspace_misses:3120

算出来 84213/(84213+3120) ≈ 96.4%，对象缓存健康。若低于 90%，先看是否大量 miss 来自同一个 key 前缀。

WordPress 侧更准的做法是看 drop-in 自带统计。Redis Object Cache 插件后台直接显示 Hit Ratio；或用 WP-CLI：wp redis status 输出里含 hits/misses/ratio。

验证做对了的标准：连续观察 24 小时，ratio 稳定 ≥ 90%，且 MySQL 的 Questions 指标下降 30% 以上（在 Grafana 或 mysqladmin ext | grep Questions 对比）。

常见失效场景

第一是键前缀冲突。多站共用一个 Redis 且没设 WP_CACHE_KEY_SALT，A 站 flush 会把 B 站对象清掉，表现为随机掉登录态、option 回默认值。每个站必须独立 salt。

第二是序列化失败。对象里带 Closure、SimpleXML 或资源句柄时 maybe_serialize 写 Redis 会静默失败，get 回来 false，等于每次 miss。用 wp cache 组只存可序列化数据。

第三是 maxmemory 打满触发淘汰。allkeys-lru 下冷数据被挤掉，命中率骤降。用 redis-cli info memory 看 used_memory 与 maxmemory 比值，长期 > 90% 就扩容或拆实例。

第四是批量更新引发雪崩。WooCommerce 导订单、WP-CLI 批量改 post 会 delete 大量 group key，瞬间 miss 拉满。应在维护窗口做，并预热：wp post list --field=ID | xargs -n1 wp post get 触发回写。

第五是网络闪断。Redis 连不上时 drop-in 若没降级到内存数组，整站 500。回退方法：备份原 wp-content/object-cache.php，出问题直接 mv object-cache.php object-cache.php.bak，WordPress 自动退回默认内存缓存。

若站点曾因插件冲突白屏，可参考 升级后网站白屏/500 了：10 分钟定位法 里的分层排查思路来隔离 Redis 层。

常见问题

Redis 能代替页面缓存吗？

不能。页面缓存直出 HTML 不进 PHP，Redis 只在 PHP 内省 DB 查询。两者叠加才完整。

命中率 85% 要不要调？

要。先查 key 前缀与序列化，再查是否冷数据过多；调完仍低说明负载不适合对象缓存，撤掉即可。

怎么安全下线 Redis？

移走 object-cache.php drop-in，清 wp-content 缓存文件，观察 MySQL 负载与 TTFB，无异常即完成回退。

动作清单

1. 用 slow log 确认 MySQL 是否被 options/postmeta 查询拖垮，再决定是否上 Redis。
2. 同可用区部署 Redis，设 maxmemory 与 allkeys-lru，每站独立 WP_CACHE_KEY_SALT。
3. 通过插件或 drop-in 接入，用 wp redis status 与 redis-cli info 看 24 小时命中率。
4. 命中率 < 90% 时按前缀、序列化、内存、雪崩四类场景逐项排。
5. 留好 object-cache.php 备份，异常时秒级移走回退默认缓存。

需要落地 Redis 对象缓存或整体性能治理？看我们的 WordPress 开发服务，也欢迎读 技术栏目 更多实战。

“, “faq”: [{“question”: “Redis 能代替页面缓存吗？”, “answer”: “不能。页面缓存直出 HTML 不进 PHP，Redis 只在 PHP 内省 DB 查询。两者叠加才完整。”}, {“question”: “命中率 85% 要不要调？”, “answer”: “要。先查 key 前缀与序列化，再查是否冷数据过多；调完仍低说明负载不适合对象缓存，撤掉即可。”}, {“question”: “怎么安全下线 Redis？”, “answer”: “移走 object-cache.php drop-in，清 wp-content 缓存文件，观察 MySQL 负载与 TTFB，无异常即完成回退。”}], “cover”: “Flat technical illustration of WordPress object cache with Redis, server and database nodes connected by lines, abstract data flow arrows, blue and orange palette, no text no logo no watermark

参考资料与延伸阅读

• WordPress 开发者文档
• WordPress 主题开发手册
• WordPress 插件开发手册