在具有单独后端服务器的安装上刷新Magento Redis Cache时出现问题

Question

我的问题是我认为我无法从管理页面刷新magento redis缓存。我意识到问题可能来自许多来源，但我的直觉告诉我它与后端在一个单独的服务器上有关。我的magento安装如下：

• Magento CE 1.8
• Amazon AWS EC2上的后端服务器和NFS（媒体） http://admin.example.com
• AWS RDS MySQL 2应用服务器上的数据库 （{3}}上的AWS Elastic Beanstalk上的（可扩展到更多） （route53）
• 常规后端缓存（数据库0），Lesti-FPC（数据库0）和 AWS elasticache redis上的redis_session（数据库1）

我最初将我的Lesti-FPC配置为在redis缓存上使用数据库2。据我所知，我认为它工作得很好，直到我意识到我无法从管理系统＆gt;缓存管理页面刷新缓存。 “Flush Magento Cache”，“Flush Cache Storage”，“disable”和“refresh”什么也没做。我只能通过重新启动redis节点或使用redis-cli并使用redis命令来刷新它。

然后我尝试将Lesti-FPC配置为使用如上所述的数据库0。它工作得更好。现在，我可以使用“Flush Cache Storage”刷新FPC，尽管其他选项仍然不起作用。当时，我认为这是Lesti-FPC特有的问题。但无论如何，使用“Flush Cache Storage”对我来说已经足够了，特别是一旦我发现我可以使用

通过代码刷新缓存

Mage::app()->getCacheInstance()->flush();

我刚刚发现问题可能不是Lesti-FPC特有的。在尝试修复Lesti问题时，我尝试监控redis。我对redis或缓存一无所知，但是当我尝试刷新FPC时，我会看到如下命令：

“del” “zc:ti:403_FPC”
“srem” “zc:tags” “403_FPC”

但这些标签从未存在过。这样做的：

keys *FPC*

redis中的

会给我

“zc:ti:109_FPC”

但403没有任何内容。所以这意味着我的fpc缓存不会像产品/类别更改和重建索引之后那样失效。我通过在更改后手动刷新缓存并运行cron作业来每隔几个小时刷新并填充fpc来解决这个问题。

但这让我很怀疑。我尝试从管理员刷新其他缓存，我发现magento总是会尝试删除并读取403密钥（其中一些存在而其中一些没有）但从未有任何109密钥（其中有很多密钥）。

我的猜测是403键是特定于管理服务器的，而109键是特定于应用服务器的。管理服务器，可能因为它位于不同的子域，不会触及应用服务器的缓存内容。但是应用程序服务器能够很好地找到自己的密钥，正如FPC工作得很好所证明的那样。

这有意义吗？有什么我可以做的来解决这个问题吗？我是否错误地配置了某些内容或者这是一个magento错误？

Answer 1

事实证明，Zend缓存前缀是etc文件夹路径的md5哈希的前三个字符。

我的应用服务器的文档根位于/ var / www / html。 / var / www / html / app / etc的完整路径给出了403.在弹性beanstalk上运行的app服务器的文档根目录在/ var / app / current，这是在部署时自动完成的。

看起来很蠢。为什么不是数据库地址和数据库名称的哈希呢？这会更有意义。

无论如何，我希望这有助于某人。