小编典典

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

redis

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

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

我最初将Lesti-
FPC配置为在Redis缓存上使用数据库2。据我所知,我认为它工作得很好,直到我意识到我根本无法从管理系统>缓存管理页面刷新缓存。“刷新Magento缓存”,“刷新缓存存储”,“禁用”和“刷新”没有任何作用。我只能通过重新引导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的错误?


阅读 290

收藏
2020-06-20

共1个答案

小编典典

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

我的应用服务器的文档根目录为/ var / www / html。/ var / www / html / app /
etc的完整路径给出的ID为403。在弹性beantalk上运行的应用程序服务器的文档根目录为/ var / app /
current,该文档根目录在部署时自动完成。

好像很傻 为什么不对数据库地址和数据库名称进行哈希运算?那会更有意义。

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

2020-06-20