1

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

  • Magento CE 1.8
  • 位于http://admin.example.com的 Amazon AWS EC2 上的后端服务器和 NFS（媒体）
  • AWS Elastic Beanstalk 上的 AWS RDS MySQL 2 应用程序服务器（可扩展至更多）上的数据库，网址为http://www.example.com (route53)
  • AWS elasticache redis 上的常规后端缓存（数据库 0）、Lesti-FPC（数据库 0）和 redis_session（数据库 1）

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

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

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错误？

4

1 回答 1

1

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

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

这似乎很愚蠢。为什么不是数据库地址和数据库名称的哈希值之类的？那会更有意义。

无论如何，我希望这对某人有所帮助。

于 2014-08-28T06:17:16.700 回答