PHP 实现的，支持面向对象和面向过程两种接口，2004年就实现了，是老客户端，而且功能少，属性也可设置的少。

前面我们介绍了「使用 Memcached 内存缓存来实现 WordPress 站点秒开」，很多用户都开始使用 Memcached 来提高 WordPress 站点速度，但是使用的时候碰到第一个或者说最多的问题就是，同台服务器上多个 WordPress 网站怎么同时使用 Memcached？

站点间数据互串

如果同时将 #WPJAM Basic# 插件 template 目录下的 object-cache.php 文件复制到同个服务器上多个 WordPress 站点的 wp-content 目录下来同时开启 Memcached 缓存，可能会出现这样的问题：

访问一个网站会跳转到另外一个网站，也就是说数据会串了。

这是怎么回事呢？这是因为 object-cache.php 默认是使用 WordPress 的表前缀（$table_prefix）来区分不同站点在内存中的缓存的。

如果你在同个服务器多个 WordPress 网站的表前缀都相同，都是默认的 wp_，那么 object-cache.php 就无法区分是哪个站点了。

那么怎么解决呢？

怎么同时使用 Memcached

定位了问题，那么就非常好解决，有两个解决方法：

1. 修改表前缀，让不同的 WordPress 博客使用不同的表前缀。我开发了一个 WordPress 数据库表前缀修改器，一键生成修改数据库表前缀所需的SQL，让你在 WordPress 修改表前缀之后能够更加方便全站修改。

2. 如果修改表前缀不方便，我还提供了 WP_CACHE_KEY_SALT 这个缓存 key 盐值的常量，你只需要在不同站点的 wp-config.php 文件定义不同的 WP_CACHE_KEY_SALT 值即可。

比如两个站点分别定义为：

define('WP_CACHE_KEY_SALT', 'site1');

define('WP_CACHE_KEY_SALT', 'site2');

如果设置了还不行，可能你的 object-cache.php 不是最新版，那就下载一下最新版的 WPJAM Basic 插件，然后将 wpjam-basic/template/ 目录下的 object-cache.php 文件复制到 wp-content 目录下。

如何设置 Memcache 服务器地址

此外还有一些用户服务器的设置，他们的 Memcached 的服务器地址不是默认的 127.0.0.1，或者它们使用的云服务器的 Memcached 服务，很多聪明的同学会自己修改 object-cache.php 中的 Memcached 服务器地址。

其实不用那么麻烦 #WPJAM Basic# 提供的 object-cache.php 支持自定义服务器地址的， 只要在 wp-config.php 文件填下如下代码，将相应的服务器地址和端口改成自己的即可：

global $memcached_servers;

$memcached_servers	= [
	[
		'127.0.0.1', // Memcached 服务器地址
		11211        // Memcached 服务器端口
	]
];

---

最后，关于在 WordPress 中使用 Memcached：

1. 使用 Memcached 内存缓存来实现 WordPress 站点秒开

2. Memcached 和 Redis 有什么区别，做缓存 WordPress 用哪个好？

3. WordPress 是如何缓存的？对象缓存（Object Cache）详细介绍和使用！

继续「如何构建安全的 WordPress」系列文章，这是 WordPress 搜索安全相关的第二篇，前面我们介绍了「限制搜索频率，防止搜索滥用攻击」，今天讲讲 WordPress 搜索第二个重大的安全隐患， SEO 垃圾攻击（SEO Spam）。

SEO 垃圾攻击

什么是SEO 垃圾攻击（SEO Spam）：

SEO 垃圾攻击（SEO Spam）​，也称为 ​搜索引擎投毒（Search Engine Poisoning）​，是指黑客或黑产通过操纵搜索引擎优化（SEO）技术，向目标网站注入垃圾内容或篡改网页元素（如标题、关键词、链接等），使其在搜索引擎结果中显示恶意或无关信息，从而误导用户或提升黑产网站的排名。如下（我做个演示）：

它还有一下几个行业通用术语：

• ​SEO Spam / SEO Poisoning：通过操纵页面元素（如标题、描述）提升黑产网站在搜索引擎中的可见性。
• ​Title Tag Hijacking：直接劫持标题标签内容，属于 ​On-Page SEO 攻击 的一种。
• ​Search Index Pollution：污染搜索引擎索引的恶意行为（Google 官方文档曾用此术语描述类似攻击）。

攻击者通过构造恶意搜索请求（如 ?s=黑产关键词+域名），利用 WordPress 默认的搜索结果页动态标题机制（例如 wp_title() 函数），将恶意内容注入到 <title> 标签中。这属于 ​注入攻击（Injection Attack）​ 的子类，但更贴近 ​SEO 滥用 场景。

为什么 WordPress 经常被这类攻击呢？因为WordPress 默认将搜索关键词动态插入标题（例如 搜索：{关键词} - 网站名），而黑产通过自动化工具高频请求含恶意关键词的搜索页（如 ?s=赌博网站），导致这些关键词被收录到搜索引擎索引中，甚至排名靠前。

这类攻击造成的损害也是很大的，一旦你的网站有这类情况，可能会被搜索引擎误判为关联黑产内容，导致网站降权或标记为恶意。万一用户通过搜索敏感词进入站点，可能触发安全平台（如 Google Safe Browsing）的警告。

静态化搜索结果标题

那么怎么办呢？其实很简单，禁用 WordPress 搜索结果动态标题，静态化搜索结果标题，​比如只显示「搜索结果」这四个字：

WPJAM 搜索优化插件 已经集成了该功能，如下图所示，「搜索增强」的第三个选项「搜索结果页面标题不显示关键字，只显示「搜索结果」四个字」勾选上即可：

WPJAM 搜索优化插件 已经集上面所有的功能和相关代码，直接启用即可，点击查看 WPJAM 搜索优化插件 的详细介绍，Modular 主题也集成了，我会在介绍 WordPress 安全这系列文章的时候，将这些安全相关代码也整合到 Modular 主题中，争取打造最安全的 WordPress 主题。

前面介绍了使用 Memcached 内存缓存来实现 WordPress 站点秒开，但是很多人问到了 Redis，就是做缓存 Redis 和 Memcached 有什么区别，用哪个更好？今天就给大家做一个简单介绍。

Memcached 和 Redis 有什么区别

首先从模型上看，Memcached 是一个分布式内存缓存系统，专注于简单的键-值对存储，设计简单易用，它不支持复杂数据类型，而 Redis 是一个内存数据结构存储，支持更多的数据结构（如列表、集合、排序集合、哈希等），不仅仅是简单的键-值对。

所以 Memcached 是为简单的读写操作优化的，适合需要快速缓存大量数据的场景，而 Redis 提供了丰富的数据操作功能，对复杂数据操作优化良好，同时也提供了高性能的读写速度，并且 Redis 支持数据持久化，可以将内存数据保存到磁盘，Memcached 没有持久性功能，所有数据都存储在内存中，服务器重启时数据就会丢失，作为缓存这个问题不大。

此外，它们还有一点比较大的区别，就是 Memcached 支持多线程，所以支持高并发访问，而 Redis 一般使用单线程模型，虽然通过 I/O 多路复用技术提供高吞吐量，这样就比较在秒杀等场景下使用，不需要考虑并发的问题，因为单线程。

简单做个功能特性对比表格：

特性	​Memcached	​Redis
​数据结构	仅支持键值对（String）	支持 String、List、Hash、Set 等
​持久化	不支持	支持 RDB 快照和 AOF 日志
​线程模型	多线程（高并发读优）	单线程（避免锁竞争，顺序执行）
​内存管理	预分配固定内存，LRU 淘汰	支持内存淘汰策略，可配置虚拟内存
​集群模式	依赖客户端分片（如 Twemproxy）	原生 Cluster 模式支持
​适用场景	简单键值缓存（如会话、HTML片段）	缓存、消息队列、实时统计等复杂场景

Redis 的作者的建议

Redis 的作者 Salvatore Sanfilippo 曾经对这两种基于内存的数据存储系统进行过比较：

1. Redis 支持服务器端的数据操作：Redis 相比 Memcached 来说，拥有更多的数据结构和并支持更丰富的数据操作，通常在 Memcached 里，你需要将数据拿到客户端来进行类似的修改再 set 回去。这大大增加了网络 IO 的次数和数据体积。在 Redis 中，这些复杂的操作通常和一般的 GET/SET 一样高效。所以，如果需要缓存能够支持更复杂的结构和操作，那么 Redis 会是不错的选择。
2. 内存使用效率对比：使用简单的 key-value 存储的话，Memcached 的内存利用率更高，而如果 Redis 采用 hash 结构来做 key-value 存储，由于其组合式的压缩，其内存利用率会高于 Memcached。
3. 性能对比：由于 Redis 只使用单核，而 Memcached 可以使用多核，所以平均每一个核上 Redis 在存储小数据时比 Memcached 性能更高。而在 100k 以上的数据中，Memcached 性能要高于 Redis，虽然 Redis 最近也在存储大数据的性能上进行优化，但是比起 Memcached，还是稍有逊色。

总结一下：Memcached 是解决简单缓存问题的可靠选择，而 Redis 通过提供更丰富的功能和各种各样的特性而优于 Memcached，这些特性对于解决复杂的场景更有优势。

WordPress 使用哪个做缓存好？

如果单纯作为内存缓存来使用，两者其实没有什么区别，那么为什么 WPJAM Basic 为什么使用 Memcached 呢？

这里有一份 4 核 CPU / 8G 内存的服务器上的测试数据：

操作	​Memcached QPS	​Redis QPS
GET 请求	120,000+	100,000+
SET 请求	90,000+	80,000+

可以看出在 WordPress 这样简单的键-值缓存，并且需要处理大量简单数据，Memcached 是一个更好的选择。

此外我们一开始就选择了 Memcached 做 WordPress 的内存缓存的存储介质，并且在使用 Memcached 做内存缓存过程中，针对出现的各种的问题，我也做了很多的优化，比如我们在后台「WPJAM」菜单下的「系统信息」中展示「Memcached」的各种信息。

当然如果你已经使用了 Redis 做内存缓存或者更熟悉 Redis，WordPress 官方插件库也有很多第三方提供了 Redis 的 object-cache.php，和使用 Memcached 一样，只需要将对应的 object-cache.php 上传到 wp-content 目录即可。

此外也有小伙伴问，WPJAM Basic 会不会集成 Redis，让大家自己选，这个可以明确的说，目前作为简单缓存功能，Memcached 已经足够好用，不会再花时间集成 Redis。

最后还有个问题，Memcached 和 Redis 可以一起用吗？如果作为缓存，WordPress 只能选择一个，因为你上传谁的 object-cache.php，就是用谁得了。

但是不等于使用 Memcached 作为缓存，就不能使用 Redis 了，比如我们之前就利用 Redis 的一些特性做过一些开发，比如因为 Redis 单线程天然串行排队的特性，我们在花生小店秒杀的功能中就是使用 Redis 进行处理的，还有一些简单的消息队列的功能处理，也是基于 Redis 进行开发的。

简单总结

所以最后总结说一下，如果简单的 key-value 的内存缓存，建议使用 Memcached，WordPress 绝大部分站点也是使用 Memcached 进行缓存的，此外 WPJAM Basic 也对此优化得比较完善。

如果要进行复杂的程序开发，比如上面说的电商的秒杀功能 ，消息队列系统等，那么 Redis 才是发挥其长处的地方。

存储来自调用数据库和 API，或者页面渲染生成的任意类型的数据（字符串，对象）到内存中，也可以直接到内存中去读取。它的 API 支持目前大部分流行的编程语言，Memcached 的官方网站：