tiempo de caducidad de memcached

Question

Memcached proporciona una opción de tiempo de caducidad de caché, que especifica cuánto tiempo se retienen los objetos en el caché. Suponiendo que todas las escrituras se realicen a través del caché, no entiendo por qué alguna vez querría eliminar un objeto de la caché. En otras palabras, si todas las operaciones de escritura actualizan la memoria caché antes de la base de datos, entonces la memoria caché nunca puede contener un objeto obsoleto, entonces ¿por qué eliminarlo?

Un posible argumento es que la caché crecerá indefinidamente si los objetos nunca se eliminan, pero la memoria caché le permite especificar un tamaño máximo. Una vez que se alcanza este tamaño, Memcached usa un algoritmo utilizado menos recientemente (LRU) para determinar qué elementos eliminar. En resumen, si se ha configurado un tamaño máximo razonable y todas las escrituras están en la memoria caché, ¿por qué desea caducar los objetos después de un cierto período de tiempo?

Gracias, Don

Answer 1

yo diría que se trata de la distinción entre 'El menos usado recientemente' y 'no va a ser en desuso' ... si se puede indicar explícitamente que los objetos pueden detraerse de el caché, que deja más espacio para los objetos que aún se pueden usar más adelante.

Answer 2

Los tiempos de caducidad son útiles cuando no necesita información precisa, solo quiere que sea precisa en un tiempo determinado. Entonces guarda en caché sus datos por (digamos) cinco minutos. Cuando se necesitan los datos, verifique la caché. Si está allí, úsalo. Si no (porque expiró), entonces ve y vuelve a calcular el valor.

Algunos valores almacenados en caché se basan en un gran conjunto de datos, e invalidar la memoria caché o escribir nuevos valores no es práctico. Esto suele ser cierto para los datos resumidos o los datos calculados a partir de un gran conjunto de datos originales.

Answer 3

Un caso sería aquel en el que un valor solo es válido durante un cierto período de tiempo.

Answer 4

Algunos datos en caché es costoso crear, pero pequeño (debe durar mucho tiempo) y otra parte es grande, pero relativamente barato (debe durar un tiempo más corto)

Además, para la mayoría de aplicaciones, es difícil hacer memcached funciona como un caché de escritura. Es difícil invalidar correctamente todas las memorias caché, especialmente las de las páginas representadas. La mayoría de los usuarios se perderán un par.

Answer 5

Tenía curiosidad sobre esto yo mismo, cuando comencé a trabajar con memcached. Preguntamos a amigos que trabajaban en hi5 y Facebook (ambos usuarios importantes de memcached).

Ambos dijeron que generalmente usan algo así como un tiempo de caducidad predeterminado de 3 horas como una especie de "por las dudas".

1. Para la mayoría de los objetos, que no es tan caro para reconstruirlas cada 3 horas
2. En la remota posibilidad de que tenga algún fallo que hace que las cosas se mantienen en caché que deberían de ninguna forma, esto puede impedir meterse en demasiados problemas

Así que supongo que la respuesta a la pregunta "¿Por qué?" es realmente, "¿Por qué no?". No le costará mucho tener una fecha de caducidad allí, y probablemente solo ayude a garantizar que no mantenga datos obsoletos en la memoria caché.

Answer 6

Si su diseño requiere un caché de escritura simultánea, aún tiene problemas para encontrar el límite de memoria asignado a memcached, que es donde LRU entra en juego.

LRU tiene dos reglas para determinar qué echar a, y lo hace en el siguiente orden:

1. losas caducados
2. El más antiguo losa sin usar

proporcionar diferentes fechas de caducidad de los diferentes grupos de objetos puede ayudar a mantener los datos de acceso menos frecuente que son más caros de almacenar en memoria caché mientras que permite el uso más frecuente de losas que aún pueden llegar al final de la cola, pero que son fáciles de recrear y caducar. También es el caso de que muchas claves de caché terminen convirtiéndose en agregados de otros objetos, y a menos que emplee un hash de búsqueda para esos objetos, es mucho más fácil dejar que los objetos caduquen después de unas horas que actualizar de manera proactiva todos los objetos. las claves asociadas, y también conserva la proporción de aciertos y fallas que estás compitiendo de manera efectiva mediante el uso de memcached en primer lugar.

Answer 7

Hay varias razones:

1. de almacenamiento de datos no es persistente entre reinicios del servidor. Deberá regenerar una gran cantidad de datos de caché después de reiniciar o volver a cargar un servidor de almacenamiento en caché.
2. Puede haber casos en que no se le notifique cuando un objeto se haya actualizado. p.ej. Detalles del usuario devueltos por las API.
3. Búsqueda de un objeto. SQL proporciona el uso de los mismos datos para generar resultados diferentes según los requisitos, como los más recientes y más votados, etc. Tendrá que usar diferentes claves de caché para almacenar los datos con resultados diferentes (duplicación de datos, un dolor de cabeza para actualizar todas las claves relevantes, incluso si cambios de dato común único). También con el Servidor de base de datos tiene una mayor flexibilidad en el escaneo de los datos (estadísticas personalizadas, etc.).

Answer 8

Hemos estado pensando en lo mismo y esto es lo que está en la wiki memcached "Incluso si está eliminando o sobreescribiendo activamente datos almacenados en caché, aún querrá que la caché caduque ocasionalmente. En caso de que su aplicación tiene un error, un bloqueo, un error de red, o algún otro problema en el que la memoria caché podría quedar fuera de sincronización ".

Esto tiene sentido ya que no podemos planear fallas de red y es importante si estamos lanzando código todos los días o 2 o semanas. lo único que pensamos es reiniciar el servidor memcached en cada lanzamiento, pero eso será realmente doloroso si hay 10 o más servidores memcached. Lo más simple que creo es establecer el vencimiento de los objetos.