我的问题是我认为我无法从管理页面刷新magento redis缓存。 我意识到问题可能来自许多来源，但是我的直觉告诉我，这与后端位于单独的服务器上有关。 我的magento安装如下：
我最初将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的错误？
事实证明，Zend缓存前缀是etc文件夹路径的md5哈希的前三个字符。
我的应用服务器的文档根目录为/ var / www / html。 / var / www / html / app / etc的完整路径给出的ID为403。在Elastic Beanstalk上运行的应用程序服务器的文档根目录为/ var / app / current，这在部署时自动完成。
好像很傻 为什么不对数据库地址和数据库名称进行哈希运算？ 那会更有意义。
无论如何，我希望这对某人有帮助。