如何同服务器多个WordPress网站共用Memcached？100%防错乱终极配置指南

一台服务器运行多个වර්ඩ්ප්රෙස්网站，共用Memcached导致数据覆盖或串线错乱？

本文手把手教你如何通过配置独立的缓存前缀（WP_CACHE_KEY_SALT）及对象缓存脚本，完美隔离各个站点的瞬态和对象缓存数据。

100%杜绝数据冲突，让多站点同时享受内存级极致加速体验，附带生产环境安全防坑提示！

前几天有个朋友问我，说他服务器上跑了三个 WordPress 网站，想给它们都配上 Memcached 加速，但又担心数据会乱套。

我当时就笑了，因为这事儿我自己也踩过坑。

说真的，Memcached 这玩意，单站点配起来简单得要命，但一旦涉及到多站点共存，就变得有意思了。为啥呢？

因为默认情况下，Memcached 会把所有网站的 transient 和对象缓存都扔进同一个池子里。你想想看，A 网站和 B 网站如果恰好用了相同的缓存键，那可就热闹了，A 的数据会直接把 B 的覆盖掉，然后两个网站就开始互相「串台」。

我当时遇到的情况更搞笑，一个ඊ-වාණිජ්‍යය网站的商品详情页，居然显示出了另一个博客网站的文章内容。我当时就愣住了，心想这是什么东西？？？

后来折腾了一晚上才搞明白，原来是缓存键冲突了。

所以今天就把我自己的配置方法分享出来，希望能帮到有同样需求的朋友。我自己也还在摸索，可能有些想法还不成熟，但这套方法至少我自己用着是没问题的。

服务器环境准备

在开始配置 WordPress 之前，你得先确保服务器已经装好了 Memcached 服务和 PHP 的 Memcached 扩展。

HestiaCP හි Memcached ස්ථාපනය කරන්නේ කෙසේද?

以 Ubuntu 系统为例，就三行命令的事

sudo apt update
sudo apt install memcached php-memcached
sudo systemctl restart php8.x-fpm  # 根据你的 PHP 版本改

装完之后，记得检查一下 Memcached 服务有没有跑起来

sudo systemctl status memcached

如果看到 active (running)，就说明没问题了。

这块需要注意一下，不同系统的包名可能不太一样。Debian 系基本都是这个命令，如果是 CentOS 或者其他发行版，你可能得用 yum 或者 dnf 来装。

我自己当时用的是 Ubuntu 20.04，整个过程还算顺利。

核心操作，配置缓存前缀

这一步是整个配置的灵魂，也是防止数据混淆的关键。

你需要在每个 WordPress 网站根目录下的 wp-config.php 文件里，添加一个独立的缓存前缀。

打开第一个网站的 wp-config.php，找到这行注释

/* That's all, stop editing! Happy blogging. */

在这行的上方，添加

// 网站 A 的配置
define( 'WP_CACHE_KEY_SALT', 'site1_unique_string_' );

然后打开第二个网站的 wp-config.php，添加类似的配置

// 网站 B 的配置
define( 'WP_CACHE_KEY_SALT', 'site2_unique_string_' );

我跟你说，这个 WP_CACHE_KEY_SALT 后面的字符串必须是绝对唯一的。建议你直接用网站域名或者缩写，比如 site1_com_、site2_net_ 这样的格式。

我当时就是偷懒用了数字编号，结果三个月后完全忘了哪个编号对应哪个网站，又得一个一个去查，真的很头疼。

你想想看，Memcached 的工作原理就是根据缓存键来存取数据的。如果你给每个网站都设置了唯一的前缀，那它们的数据自然就被隔离开来了，互不干扰。

这就好比给每个网站都发了一个专属的储物柜，虽然都在同一个房间里，但钥匙不同，数据就乱不了。

开启对象缓存

前缀配好之后，接下来就是让 WordPress 真正用上 Memcached。

这里有两个方案，我两个都试过，各有各的好。

方案一，插件方式（最省心）

登录 WordPress 后台，装一个支持 Memcached 的缓存插件。

推荐用 W3 සම්පූර්ණ කෑෂය，，稳定性不错。装好之后，在插件设置里把缓存类型选成 Memcached，服务器填 127.0.0.1，端口填默认的 11211，保存就行了。

如果你想要更纯粹的方案，可以直接装 Memcached Object Cache 这个插件，它专门干这个事，没有其他杂七杂八的功能。

说实话我一开始也觉得插件方式挺好的，毕竟省事儿。但后来发现有些插件会带一堆用不上的功能，每次更新都提心吊胆的，生怕它突然加个什么特性把我的配置搞乱了。

方案二，手动部署 object-cache.php（更可控）

如果你跟我一样有点强迫症，不想装太多插件，可以用这个方案。

去 WordPress 官方插件库下载 Memcached Object Cache 这个插件，或者从 GitHub 找最新的 object-cache.php 文件。然后把解压出来的 object-cache.php 文件，通过 FTP 或者 SSH 上传到每个网站的 wp-content 目录下。

注意啊，是 wp-content 的根目录，不是 plugins 子目录。

放进去之后，WordPress 会自动识别并激活缓存。你什么都不用配置，因为它会读取你前面在 wp-config.php 里设置的 WP_CACHE_KEY_SALT。

确实想省事，就是用这个方案，主要是因为可控。出了问题知道去哪查，也不会被插件的自动更新搞出意外。

验证配置是否生效

配完之后你肯定想知道到底有没有成功，对吧？

最简单的方法就是去看 Memcached 的状态。用 telnet 或者 nc 工具连上去

echo "stats" | nc 127.0.0.1 11211

然后你会看到一堆统计数据。重点关注 cmd_set 和 get_hits 这两个值，刷新几次网页看看它们有没有在增长。如果在涨，说明缓存已经在正常工作了。

另外一个更直观的验证方法，就是同时打开两个网站，看看有没有互相串台的情况。如果 A 网站不会显示 B 网站的内容，那基本就说明前缀生效了。

我当时还做了一个更狠的测试，在两个网站上分别设置了不同的 transient，然后用 nc 工具直接去查 Memcached 里的数据，确实能看到两个不同前缀的键值对，完全没有混淆。

那一刻真的有种大功告成的感觉，想想就觉得爽。

安全问题别忽视

由于所有网站都共用一个 Memcached 实例，这里有个安全隐患你得知道。

理论上，如果服务器上有其他用户，他们可以通过本地端口读取你的缓存数据。虽然需要一定技术门槛，但防人之心不可无。

所以一定要确保你的 Memcached 绝对不要监听公网 IP。在 /etc/memcached.conf 配置文件里，确保有这一行

-l 127.0.0.1

这样 Memcached 就只会监听本地回环地址，外部访问不了。

如果你对安全性要求极高，或者服务器上跑着其他用户不太放心的网站，我建议你可以考虑用 Redis 来替代 Memcached。Redis 支持多数据库隔离，还有密码验证，安全性会好很多。

不过 Redis 的配置比 Memcached 稍微复杂一点，如果你只是个人用或者小团队用，Memcached 加上 127.0.0.1 的监听限制，基本够用了。

一些踩坑经验

最后再分享几个我踩过的坑，希望能帮你少走点弯路。

PHP 扩展版本要对上。我之前遇到过装了 php-memcached 扩展，但 WordPress 就是不认的情况，后来发现是 PHP 版本不匹配。你装扩展的时候一定要看清楚自己的 PHP 版本，别装错了。

object-cache.php 文件路径别搞错。一定要放在 wp-content 的根目录，不是 plugins 目录。我有个朋友就放错了位置，结果折腾了半天都没生效。

缓存前缀别用太短的字符串。我一开始用的 a_、b_ 这种，后来发现太短了，容易跟 WordPress 自己生成的缓存键撞车。至少用个七八位的随机字符串或者域名缩写。

清理缓存的时候记得两个网站都清。有一次我只清了一个网站的缓存，结果另一个网站还保留着旧数据，导致两个网站的内容不一致，花了好久才排查出来。

说实话我也不知道这些经验对大家有没有用，但我已经毫无保留的分享了。

අවසානයේ ලියන්න

其实给多站点配 Memcached 这事儿，技术上并不复杂，核心就是那一个缓存前缀的配置。但魔鬼藏在细节里，版本匹配、文件路径、安全配置这些小地方，任何一个出问题都够你折腾一阵子的。

我自己这套方法用了快一年了，跑了三个 WordPress 站点，到目前为止没出过什么大问题。如果你也在做类似的事情，不妨试试看。

对了，如果你有更好的方案或者踩过什么有趣的坑，欢迎留言分享，我也想学习一下。

毕竟，这玩意儿，多一个人知道就少一个人踩坑，对吧？

මෙච්චර දුරක් කියවලා ඉවර නිසා, මේක ප්‍රයෝජනවත් කියලා හිතුනනම් like කරලා share කරන්න. මුලින්ම updates ලබා ගන්න කැමති නම්, මාව follow කරන්නත් පුළුවන්!

මගේ ලිපිය කියෙව්වට ස්තූතියි. ඊළඟ වතාවේ හමුවෙමු.