How does magento come up with cache key names?

I think my question here: Problems flushing Magento Redis Cache on an installation with a separate backend server is a little too specific, based on the small number of views it's getting, so I'm asking a simpler, more general question.

The details of my problem are in the linked question. But the gist of it is that if I try to refresh a cache or flush magento cache from the admin area, it tries to clear stuff that looks like "zc:ti:403_FPC" which does not exist. Instead, they are named “zc:ti:109_FPC” and the like. Some 403 keys exist, but there are many more 109s.

My suspicion is that the problem is caused by having the admin on a separate server and a different subdomain (admin.example.com). Because when the app servers make and clear keys they seem to name them 109, while the admin server makes 403 keys. Or maybe the problem having multiple app servers. Or using redis.

Since my real problem is too specific, it would be a good start if someone could tell me how the names are made when they are saved, and what names are used when they are retrieved. Thanks.

Edit: I tested out something really quickly. It seems that using the admin to refresh caches calls

Mage::app()->getCacheInstance()->clean() etc.

getCacheInstance() looks like:

/**
* Get core cache model
*
* @return Mage_Core_Model_Cache
*/
public function getCacheInstance()
  {
      if (!$this->_cache) {
          $this->_initCache();
      }
      return $this->_cache;
  }

I tried doing this one time

Mage::app()->getCache()->clean()

And it seemed to work! I need to poke around a little bit more to be sure. getCache looks like this:

/**
       * Retrieve cache object
       *
       * @return Zend_Cache_Core
       */
      public function getCache()
      {
          if (!$this->_cache) {
              $this->_initCache();
          }
          return $this->_cache->getFrontend();
      }

Is there any reason why one would use getCacheInstance over getCache for refreshing the caches? Is there any reason why this would only affect me and not everyone else?

EDIT again:

It only worked because it sent a flushdb command.

EDIT yet again:

I've been poking around, and I came upon some interesting stuff in Zend/Cache/Core.php. I found an option called 'cache_id_prefix'. It sounded promising. When I ran the following on my admin server:

<?php 
require_once('/var/www/html/app/Mage.php');
$cip = Mage::app()->getCache()->getOption('cache_id_prefix');
echo $cip;
?>

I got "403_" - exactly the value that I expected. I tried it on the app server and got "109_". Now, I just need to find where these options are set with setOption().

回答1:

Found the answer at: 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)...

That is most likely my answer. My admin server has a document root at the default /var/www/html. The app servers are on elastic beanstalk and have their roots at /var/app/current.

回答2:

I've just read the relative code. I found out the cache prefix can be overrided by add one config id_prefix in app/etc/local.xml like this

<config>
    <global>
        <cache>
            ...
            <id_prefix>cache_prefix_</id_prefix>
            ...
        </cache>
    </global>
</config>

If you are using Lesti_fpc, edit app/etc/fpc.xml add one line like this,

<config>
    <global>
        <fpc>
            ...
            <id_prefix>cache_prefix_</id_prefix>
            ...
        </fpc>
    </global>
</config>

It works on 1.7.0.2, so I think this would work for newer version too.