php - services - Valores de caché inconsistentes con Zend Cache con AWS ElastiCache en varios servidores

que es elasticache aws

Question

Estamos utilizando Zend Cache con un backend de memcached apuntando a un clúster AWS ElastiCache con 2 nodos de caché. Nuestra configuración de caché se ve así:

$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 usamos un solo 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 el caché desde un servidor y leer desde 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.

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

Llamadas posteriores a $cache->load(''message''); desde el Servidor A devuelve el resultado esperado de hola .

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

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

¿Puedes decir qué hash_strategy estás usando para Memcache? He tenido problemas en el pasado con el estándar predeterminado pero todo ha ido bien desde que cambié a consistente :

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

Answer 2

Con un algoritmo hash normal, cambiar la cantidad de servidores puede hacer que muchas claves sean reasignadas a diferentes servidores, lo que resulta en grandes conjuntos de errores 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 señale 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é.

El algoritmo hash constante es un modelo que permite una distribución más estable de claves dada 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 hashing consistente en http://www.last.fm/user/RJ/journal/2007/04/10/rz_libketama_-_a_consistent_hashing_algo_for_memcache_clients