31

我们将 Zend Cache 与一个 memcached 后端一起使用，该后端指向一个具有 2 个缓存节点的 AWS ElastiCache 集群。我们的缓存设置如下所示：

$frontend = array(
    'lifetime' => (60*60*48),
    'automatic_serialization' => true,
    'cache_id_prefix' => $prefix
);
$backend = array(
    'servers' => array(
        array( 'host' => $node1 ),
        array( 'host' => $node2 )
    )
);
$cache = Zend_Cache::factory('Output', 'memecached', $frontend, $backend);

过去，当使用单个 EC2 服务器从缓存中写入和读取时，我们没有注意到缓存有任何问题。

但是，我们最近引入了第二台 EC2 服务器，突然间我们发现从一台服务器写入缓存并从另一台服务器读取时出现问题。两台服务器都由同一个 AWS 账户管理，两台服务器都没有单独写入或读取缓存的问题。两者使用相同的缓存配置。

服务器 A执行$cache->save('hello', 'message');

$cache->load('message');来自服务器 A的后续调用返回hello的预期结果。

但是，当服务器 B执行时$cache->load('message');，我们得到false。

就我对 ElastiCache 的理解而言，发出读取请求的服务器应该与返回的缓存值无关。任何人都可以对此有所了解吗？

4

2 回答 2

1

你能说出你为内存缓存使用的 hash_strategy 吗？过去我在使用默认标准时遇到过问题，但自从更改为一致后一切都很好：

http://php.net/manual/en/memcache.ini.php#ini.memcache.hash-strategy

于 2013-01-02T11:09:20.013 回答
0

使用普通的散列算法，改变服务器的数量会导致许多键被重新映射到不同的服务器，从而导致大量的缓存未命中。

假设您的缓存集群中有 5 个 ElastiCache 节点，添加第六台服务器可能会导致 40% 以上的密钥突然指向不同的服务器。此活动是不可取的，可能会导致缓存未命中并最终用请求淹没您的后端数据库。为了尽量减少这种重新映射，建议在缓存客户端中遵循一致的哈希模型。

Consistent Hashing 是一种模型，允许在添加或删除服务器的情况下更稳定地分发密钥。一致散列描述了将键映射到服务器列表的方法，其中添加或删除服务器会导致键映射到的位置发生非常小的变化。使用这种方法，添加第十一个服务器应该会导致不到 10% 的密钥被重新分配。这个百分比在生产中可能会有所不同，但与普通哈希算法相比，在这种弹性场景中它的效率要高得多。还建议在所有客户端配置中保持 memcached 服务器顺序和服务器数量相同，同时使用一致的哈希。Java 应用程序可以通过 spymemcached 使用“Ketama 库”将该算法集成到他们的系统中。有关一致性哈希的更多信息，请参见http://www.last.fm/user/RJ/journal/2007/04/10/rz_libketama_-_a_consistent_hashing_algo_for_memcache_clients

于 2013-04-17T12:37:50.187 回答