Valori della cache incoerenti con Zend Cache con AWS ElastiCache su più server

Question

Stiamo utilizzando Zend Cache con un backend memcached che punta a un cluster ElastiCache AWS con 2 nodi di cache. La nostra configurazione della cache si presenta così:

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

Non abbiamo notato alcun problema con la cache in passato, quando si utilizza un unico server EC2 di scrivere e leggere dalla cache.

Tuttavia, abbiamo recentemente introdotto un secondo server EC2 e all'improvviso riscontriamo problemi durante la scrittura nella cache da un server e la lettura da un altro. Entrambi i server sono gestiti dallo stesso account AWS e nessuno dei due server ha problemi di scrittura o lettura dalla cache individualmente. La stessa configurazione della cache è utilizzata per entrambi.

Server Un esegue $cache->save('hello', 'message');

Le chiamate successive a $cache->load('message'); da Server A restituire il risultato atteso di ciao.

Tuttavia, quando Server B esegue $cache->load('message');, otteniamo falsa.

Per quanto riguarda la mia comprensione di ElastiCache, il server che esegue la richiesta di lettura non dovrebbe incidere sul valore di cache restituito. Qualcuno può far luce su questo?

Answer 1

Puoi dire quale hash_strategy stai usando per memcache? Ho avuto problemi in passato con il default standard di ma tutto è stato messo dal passaggio a coerente:

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

Answer 2

Con un algoritmo di hashing normale, cambiando il numero di server può causare molte chiavi da rimappare su server diversi risultanti in enormi serie di errori di cache.

Immaginate di avere 5 nodi ElastiCache nel vostro cluster di cache, aggiungendo un sesto server potrebbe causare il 40% + delle vostre chiavi a puntare improvvisamente su server diversi rispetto al normale. Questa attività non è auspicabile, potrebbe causare errori di cache e infine impoverire il DB di back-end con le richieste. Per minimizzare questa rimappatura, si raccomanda di seguire un modello di hash coerente nei client di cache.

L'hash coerente è un modello che consente una distribuzione più stabile delle chiavi in ​​caso di aggiunta o rimozione di server. L'hash coerente descrive i metodi per mappare le chiavi a un elenco di server, dove l'aggiunta o la rimozione dei server causa uno spostamento minimo nel punto in cui le chiavi vengono mappate. Utilizzando questo approccio, l'aggiunta di un undicesimo server dovrebbe causare la riassegnazione di meno del 10% delle chiavi. Questa percentuale può variare in produzione ma è molto più efficiente in scenari così elastici rispetto ai normali algoritmi di hash. Si consiglia inoltre di mantenere l'ordine del server memcached e il numero di server uguali in tutte le configurazioni client mentre si utilizza l'hashing coerente. Le applicazioni Java possono usare "Ketama library" tramite spymemcached per integrare questo algoritmo nei loro sistemi. Maggiori informazioni sull'hash coerente possono essere trovate su http://www.last.fm/user/RJ/journal/2007/04/10/rz_libketama_-_a_consistent_hashing_algo_for_memcache_clients