我想我的问题在这里: Problems flushing Magento Redis Cache on an installation with a separate backend server基于它获得的少量 View ,它有点太具体了,所以我要问一个更简单、更笼统的问题。
我的问题的详细信息在链接的问题中。但它的要点是,如果我尝试从管理区域刷新缓存或刷新 magento 缓存,它会尝试清除看起来像“zc:ti:403_FPC”的不存在的东西。相反,它们被命名为“zc:ti:109_FPC”等。存在一些 403 键,但还有更多的 109。
我怀疑问题是由于管理员在单独的服务器和不同的子域 (admin.example.com) 上引起的。因为当应用服务器生成和清除 key 时,它们似乎将它们命名为 109,而管理服务器生成 403 key 。或者可能是拥有多个应用程序服务器的问题。或者使用redis。
由于我的实际问题太具体了,如果有人能告诉我保存名称时如何生成名称以及检索名称时使用的名称,那将是一个好的开始。谢谢。
编辑: 我很快就测试了一些东西。好像是用admin刷新缓存调用
Mage::app()->getCacheInstance()->clean() etc.
getCacheInstance() 看起来像:
/**
* Get core cache model
*
* @return Mage_Core_Model_Cache
*/
public function getCacheInstance()
{
if (!$this->_cache) {
$this->_initCache();
}
return $this->_cache;
}
我试过一次
Mage::app()->getCache()->clean()
它似乎奏效了!我需要多花点时间才能确定。 getCache 看起来像这样:
/**
* Retrieve cache object
*
* @return Zend_Cache_Core
*/
public function getCache()
{
if (!$this->_cache) {
$this->_initCache();
}
return $this->_cache->getFrontend();
}
为什么人们会使用 getCacheInstance 而不是 getCache 来刷新缓存?有什么理由说明这只会影响我而不影响其他人吗?
再次编辑:
它之所以起作用,是因为它发送了一个 flushdb 命令。
再次编辑:
我一直在四处寻找,在 Zend/Cache/Core.php 中发现了一些有趣的东西。我找到了一个名为“cache_id_prefix”的选项。这听起来很有希望。当我在管理服务器上运行以下命令时:
<?php
require_once('/var/www/html/app/Mage.php');
$cip = Mage::app()->getCache()->getOption('cache_id_prefix');
echo $cip;
?>
我得到了“403_”——正是我所期望的值。我在应用服务器上试了一下,得到了“109_”。现在,我只需要找到使用 setOption() 设置这些选项的位置。
最佳答案
在以下位置找到答案: http://blog.nexcess.net/2011/05/21/clearing-the-cache-in-magento/
As you can see, there’s a distinct pattern to the cache file names. Magento’s implementation of the Zend Cache prefixes all files with “mage”, followed by an id prefix (technically: the first 3 characters from an md5 hash of the path to your app/etc/ directory)...
这很可能是我的答案。我的管理服务器在默认的/var/www/html 中有一个文档根目录。应用程序服务器位于 elastic beanstalk 上,根位于/var/app/current。
关于php - magento 如何得出缓存键名?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/25463704/