在具有单独的后端服务器的安装上刷新Magento Redis缓存时出现问题 [英] Problems flushing Magento Redis Cache on an installation with a separate backend server

问题描述

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

My problem is that I do not think I am able to refresh the magento redis cache from the admin page. I realize that the problem could come from many sources, but my gut tells me it has something to do with the backend being on a separate server. My magento installation is as follows:

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

• Magento CE 1.8
• Backend server and NFS(media) on an Amazon AWS EC2 at http://admin.example.com
• Database on AWS RDS MySQL 2 app servers (scalable to more) on AWS Elastic Beanstalk at http://www.example.com (route53)
• regular backend cache(database 0), Lesti-FPC(database 0), and redis_session (database 1) on AWS elasticache redis

我最初将Lesti-FPC配置为在Redis缓存上使用数据库2.据我所知，我认为它工作得很好，直到我意识到我根本无法从管理系统>缓存管理页面刷新缓存.刷新Magento缓存"，刷新缓存存储"，禁用"和刷新"没有任何作用.我只能通过重新启动redis节点或使用redis-cli并使用redis命令来刷新它.

I originally had my Lesti-FPC configured to use database 2 on the redis cache. I thought it worked pretty well as far as I could tell, until I realized that I couldn't flush the cache at all from the admin System>Cache Management page. "Flush Magento Cache," "Flush Cache Storage," "disable", and "refresh" did nothing. I could only flush it by rebooting the redis node or going in with redis-cli and using redis commands.

然后，我如上所述尝试将Lesti-FPC配置为使用数据库0.效果更好.现在，我可以使用刷新缓存存储"来刷新FPC，尽管其他选项仍然无效.当时，我认为这是Lesti-FPC特有的问题.但是无论如何，当时使用刷新缓存存储"对我来说已经足够了，尤其是当我发现我可以使用

I then tried configuring Lesti-FPC to use database 0 as described above. It worked better. Now, I could flush the FPC with "Flush Cache Storage," although the other options still didn't work. At the time, I assumed it was an issue specifically with Lesti-FPC. But anyway, using "Flush Cache Storage" was good enough for me at the time, especially once I discovered that I could flush the cache through code using

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

我最近才发现该问题可能并非特定于Lesti-FPC.在尝试解决Lesti问题时，我尝试监视Redis.我对redis或缓存一无所知，但是当我尝试刷新FPC时，会看到类似以下的命令:

I just recently found out that the problem may not be specific to Lesti-FPC. While trying to fix the Lesti issue, I tried monitoring redis. I know nothing about redis or caching, but when I would try to refresh the FPC, I would see commands like:

"del" "zc:ti:403_FPC"
"srem" "zc:tags" "403_FPC"

但是这些标签从未存在.正在执行:

But those tags never existed. Doing:

keys *FPC*

redis会给我

"zc:ti:109_FPC"

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

but nothing with 403. SO this means that my fpc caches do not get invalidated like they're supposed to after product/category changes and reindexing. I got around this by manually flushing the cache after changes and running cron jobs to flush and prime the fpc every few hours.

但这使我感到怀疑.我尝试从管理员刷新其他缓存，但我发现magento总是会尝试删除和读取403键(其中一些存在而某些不存在)，但从未尝试过109个键(其中有很多).

But it made me suspicious. I tried refreshing the other caches from the admin, and I found that magento would always try to delete and read the 403 keys(some of which existed and some of which did not) but never any 109 keys (of which there are many).

我的猜测是403键特定于管理服务器，而109键特定于应用程序服务器.管理服务器可能因为不在另一个子域中，所以没有接触应用程序服务器的缓存内容.但是应用服务器可以找到自己的密钥，这可以从FPC运行得很好的事实中得到证明.

My guess is that the 403 keys are specific to the admin server, and the 109 keys are specific to the app servers. The admin server, maybe because it is on a different subdomain, is not touching the app servers' cached stuff. But the app servers are able to find its own keys fine, as demonstrated by the fact that the FPC is working very well.

这有意义吗?有什么我可以解决的吗?我配置不正确还是这是magento的错误?

Does this make sense? Is there something I could do to fix this? Did I configure something incorrectly or is this a magento bug?

推荐答案

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

It turns out that the Zend cache prefix is the first three characters of an md5 hash of the path to your etc folder.

我的应用服务器的文档根目录为/var/www/html./var/www/html/app/etc的完整路径给出的ID为403.在Elastic Beantalk上运行的应用程序服务器的文档根目录为/var/app/current，这在部署时自动完成.

My app server has its document root at /var/www/html. The full path of /var/www/html/app/etc gives an id of 403. The app servers running on elastic beanstalk have their document roots at /var/app/current which is done automatically at deployment.

似乎很愚蠢.为什么不对数据库地址和数据库名称进行哈希运算呢?那会更有意义.

It seems pretty dumb. Why not a hash of the database address and database name or something? That would make more sense.

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

Anyway, I hope this helps someone.

这篇关于在具有单独的后端服务器的安装上刷新Magento Redis缓存时出现问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！