magento - 在使用单独后端服务器的安装上刷新 Magento Redis 缓存时出现问题

Question

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

• Magento CE 1.8
• Amazon AWS EC2 上的后端服务器和 NFS(媒体)，地址为 http://admin.example.com
• AWS RDS MySQL 2 应用服务器上的数据库(可扩展到更多)在 AWS Elastic Beanstalk 上 http://www.example.com(路线 53)
• 常规后端缓存(数据库 0)、Lesti-FPC(数据库 0)和AWS elasticache redis 上的 redis_session(数据库 1)

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

然后我尝试将 Lesti-FPC 配置为使用数据库 0，如上所述。它工作得更好。现在，我可以使用“Flush Cache Storage”刷新 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 key 特定​​于管理服务器，而 109 key 特定​​于应用服务器。管理服务器，可能是因为它在不同的子域上，没有触及应用服务器的缓存内容。但应用服务器能够很好地找到自己的 key ，FPC 运行良好这一事实证明了这一点。

这有意义吗？我可以做些什么来解决这个问题吗？我是否配置不正确或者这是一个 magento 错误？

Answer 1

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

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

看起来很蠢。为什么不是数据库地址和数据库名称的散列？那会更有意义。

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