Valores de caché inconsistentes utilizando Zend Cache con AWS ElastiCache en varios servidores

Question

Estamos utilizando Zend Cache con un servidor de memcached apuntando a un clúster AWS ElastiCache con 2 nodos de caché. Nuestra configuración de caché es el siguiente:

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

No hemos notado ningún problema con la memoria caché en el pasado cuando se utiliza un único servidor EC2 para escribir y leer desde la memoria caché.

Sin embargo, recientemente hemos introducido un segundo servidor EC2 y de repente estamos viendo problemas al escribir en la memoria caché de un servidor y leer de otro. Ambos servidores son administrados por la misma cuenta de AWS, y ninguno de los servidores tiene problemas para escribir o leer el caché de forma individual. La misma configuración de caché se usa para ambos.

servidor A ejecuta $cache->save('hello', 'message');

llamadas subsiguientes a $cache->load('message'); desde el servidor A devolver el resultado esperado de hola.

Sin embargo, cuando el servidor B ejecuta $cache->load('message');, obtenemos falsa.

En lo que respecta a mi comprensión de ElastiCache, el servidor que realiza la solicitud de lectura no debe tener relación con el valor de caché devuelto. ¿Alguien puede arrojar algo de luz sobre esto?

Answer 1

¿Puede decirnos qué hash_strategy está utilizando para Memcache? He tenido problemas en el pasado utilizando el estándar por defecto pero todo ha estado bien desde que se cambió a consistente:

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

Answer 2

Con un algoritmo de hash normal, cambiando el número de servidores puede causar muchas claves para ser reasignado a diferentes servidores que resultan en grandes conjuntos de fallas de caché.

Imagine que tiene 5 Nodos ElastiCache en su Clúster de caché, agregando un sexto servidor puede causar que el 40% + de sus claves apunte repentinamente a servidores diferentes de lo normal. Esta actividad no es deseable, puede causar fallas en el caché y eventualmente saturar su base de datos con solicitudes. Para minimizar esta reasignación, se recomienda seguir un modelo Hashing consistente en sus clientes de caché.

Constante Hashing es un modelo que permite una distribución más estable de las claves debido a la adición o eliminación de servidores. Constante Hashing describe métodos para asignar claves a una lista de servidores, donde agregar o eliminar servidores provoca un cambio muy mínimo en el destino de las claves. Usando este enfoque, agregar un undécimo servidor debería causar que se reasigne menos del 10% de sus claves. Este% puede variar en la producción, pero es mucho más eficiente en tales escenarios elásticos en comparación con los algoritmos hash normales. También se recomienda mantener ordenado el servidor de memcached y la cantidad de servidores en todas las configuraciones de cliente mientras se usa Hashing constante. Las aplicaciones Java pueden usar "biblioteca de Ketama" a través de spymemcached para integrar este algoritmo en sus sistemas. Se puede encontrar más información sobre el hash consistente en http://www.last.fm/user/RJ/journal/2007/04/10/rz_libketama_-_a_consistent_hashing_algo_for_memcache_clients