我在 AWS 中有两台服务器。一台是实时生产服务器（一个多站点 WordPress 安装，有数百个站点和大约 5,000 个用户），另一台是正在为测试服务器配置的 prod 克隆。实时服务器有四台阵列服务器、一台 Elastic Load Balancer，并连接到 AWS 中的大型 RDS。直到昨天，我还天真地以为我们的缓存是通过 APC 和 WordPress 插件来处理的。但事实并非如此。原来有人在这里将 AWS 的 ElastiCache 添加到了我们的实时服务器中。本质上，ElastiCache 是针对不在云中的用户的内存缓存。
无论如何，两天前我们尝试在测试服务器上启用缓存，结果出现了一个非常奇怪的错误（重定向神秘地出现在我们实时站点的主管理仪表板上，然后转到我们的测试服务器）。因此，一旦我们意识到该错误很可能与我们不知道的缓存系统有关，我们就禁用了缓存。事实证明，当我们在测试服务器上启用缓存时，它使用了实时服务器正在使用的相同 Elasticache 服务器（因为测试是实时服务器的克隆）。因此，我们在删除/重命名 object-cache.php 文件时禁用了它。
禁用它解决了我们的重定向问题，但突然之间，我们 5,000 名用户中的许多（并非全部）用户无法再登录他们各自的网站。出于某种原因，我们数据库中的值对很大一部分用户不起作用，迫使他们不得不重置密码。显然，对于 5,000 名用户来说，这是一个巨大的问题。因此，我们在实时实例上重新启用了缓存，并决定通过 WP 配置更改来修复缓存重定向（我们在配置中添加了 define('RELOCATE',true); 以强制覆盖重定向到我们的测试服务器）。
我们在使用 memcache 时注意到的一件事是，它不断用测试服务器的域名来更新我们的 wp_options 表，而不是我们实际使用的域名。事实上，每当我运行查询来查找测试域的字符串并将其更新为实际域时，它仍然会这样做。每隔几分钟，缓存就会将其改回来。很可怕。但看起来我们的配置更改现在强制覆盖。这一切真正令人担忧的是，memcache 似乎是从自己的键：值对中提取用户密码，而不是直接从数据库中提取。我的意思是，启用缓存后，用户可以登录。没有它，许多用户被迫重置密码。
有谁能告诉我如何有效地了解这种情况下 memcache 发生了什么，以及如何修复它，以便数据库被正确写入，密码信息不只是被保存在缓存中？在我看来，这是一个定时炸弹。只需一个 flush_all 命令就可以让我的大多数用户的生活变得非常非常痛苦。
我们在 RDS 上使用 Nginx 和 MySQL。WordPress 3.4.2。
答案1
您的缓存已被测试实例中的数据和会话信息覆盖。使用 memcached 客户端清除缓存。重新启动缓存集群也可能会清除缓存。重置密码也会重置会话，因此这可能是一个可行的解决方案。
也就是说，您的安全组可能设置错误。您的测试实例应该永远无法连接到 ElastiCache 集群。Memcached 没有身份验证，因此如果您可以访问缓存服务器，则可以访问数据。检查并确保您的安全组未设置为允许每个地址进入。