Valeurs de cache incohérentes à l'aide de Zend Cache avec AWS ElastiCache sur plusieurs serveurs

Question

Nous sommes à l'aide de Zend Cache avec une memcached backend pointant vers une AWS cluster ElastiCache avec 2 nœuds de cache. Notre cache de configuration ressemble à ceci:

$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);

Nous n'avons pas remarqué des problèmes avec le cache dans le passé lors de l'utilisation d'un seul EC2 serveur à lire et à écrire à partir du cache.

Cependant, nous avons récemment introduit un deuxième EC2 serveur et tout à coup, nous voyons des problèmes lors de l'écriture dans le cache d'un serveur et de la lecture à partir d'un autre. Les deux serveurs sont gérés par le même compte AWS, et ni le serveur a des problèmes d'écriture ou de lecture de la mémoire cache individuellement. La même configuration de cache est utilisé pour les deux.

Serveur exécute $cache->save('hello', 'message');

Les appels ultérieurs $cache->load('message'); à partir d' Un Serveur à renvoyer le résultat attendu de bonjour.

Toutefois, lorsque le Serveur B exécute $cache->load('message');, nous obtenons faux.

Aussi loin que ma compréhension de ElastiCache, le serveur qui effectue la demande de lecture devrait pas avoir d'incidence sur le cache de la valeur retournée. Quelqu'un peut-il éclairer sur ce point?

Answer 1

Pouvez-vous dire quelle stratégie de hachage vous utilisez pour memcache? J'ai eu des problèmes dans le passé en utilisant la norme par défaut , mais tout s'est bien passé depuis le passage à cohérent :

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

Answer 2

Avec un algorithme de hachage, en modifiant le nombre de serveurs peuvent entraîner beaucoup de clés pour être redistribué aux différents serveurs, ce qui cause d'énormes ensembles de défauts de cache.

Imaginez que vous avez 5 ElastiCache les Nœuds de votre Cluster de cache, l'ajout d'un sixième serveur peut provoquer 40%+ de vos clés tout à coup le point sur différents serveurs que la normale. Cette activité n'est pas souhaitable, peut causer des défauts de cache et, éventuellement, l'envahissement de votre backend DB avec les demandes. Afin de minimiser cette reconfiguration il est recommandé de suivre cohérente de Hachage modèle dans votre cache clients.

Cohérente de Hachage est un modèle qui permet de la plus stable de la distribution des clés compte tenu de l'ajout ou la suppression de serveurs. Compatible Hachage décrit les méthodes de cartographie des clés d'une liste de serveurs, d'où l'ajout ou la suppression de serveurs provoque très peu de changement dans la où clés carte de. En utilisant cette approche, en ajoutant un onzième serveur devrait causer moins de 10% de vos clés pour être réaffectés. Cette % peuvent varier en production, mais il est beaucoup plus efficace dans de tels élastique scénarios par rapport à la normale algorithmes de hachage. Il est également conseillé de garder serveur memcache de la commande et le nombre de serveurs de même dans toutes les configurations du client lors de l'utilisation cohérente de Hachage. Les Applications Java peuvent utiliser "Ketama" la bibliothèque par le biais de spymemcached à intégrer cet algorithme dans leurs systèmes. Plus d'informations sur la constance de hachage peut être trouvé à http://www.last.fm/user/RJ/journal/2007/04/10/rz_libketama_-_a_consistent_hashing_algo_for_memcache_clients