Groupcache: cómo emular el tiempo de vencimiento
Me di cuenta de que en la decisión de diseño Setting and expiration time había omitido. Me imagino que esto se debe a que tiene una idea sobre cómo emular esta función.
El caso de uso que tengo en mente es crear un proxy inverso en caché frente a una aplicación web. Sé que las páginas deben estar en caché durante X min.
¿Podría explicar un poco cómo abordaría esto?
(No estoy seguro de que este sea el lugar adecuado para hacer preguntas).
yml
Todos 3 comentarios
Hasta donde he entendido el diseño de groupcache, no se pueden invalidar o actualizar elementos almacenados en caché. Esta característica se ha omitido porque es extremadamente difícil en un sistema distribuido y requeriría costosos algoritmos de consenso (por ejemplo, paxos).
Sin embargo, puede generar una clave de caché única cada X minutos codificando la información de tiempo en la clave de caché. Por ejemplo, "foo-12: 30" podría describir de forma única el elemento "foo" en el momento de las 12:30. Luego, su aplicación puede acceder a este elemento hasta, digamos, 12:40. En este momento, se podría generar un nuevo elemento, "foo-12: 40" y el elemento antiguo ("foo-12: 30") finalmente caducará una vez que los clientes hayan dejado de acceder a él.
Si su aplicación distribuida puede actualizar y recuperar números de revisión de manera consistente (puede hacerlo, por ejemplo, con doozerd, zookeeper o la solución de base de datos de su elección), también puede codificar este número de revisión como parte de la clave de caché. Alternativamente, también puede utilizar los encabezados HTTP "Última modificación" o "ETag" como algún tipo de número de revisión en su proxy web.
tux21b
en 29 jul. 2013
Sí, lo que dijo tux21b. (intencionalmente dejado fuera, al menos por ahora).
bradfitz
en 29 jul. 2013
¡Gracias @ tux21b por la sugerencia con respecto a las revisiones!
anacrolix
en 3 oct. 2013
Temas relacionados
AlexanderChen1989
·
6Comentarios
orcaman
·
9Comentarios
abennett
·
3Comentarios
cowboyrushforth
·
5Comentarios
ncw
·
11Comentarios
Comentario más útil
Hasta donde he entendido el diseño de groupcache, no se pueden invalidar o actualizar elementos almacenados en caché. Esta característica se ha omitido porque es extremadamente difícil en un sistema distribuido y requeriría costosos algoritmos de consenso (por ejemplo, paxos).
Sin embargo, puede generar una clave de caché única cada X minutos codificando la información de tiempo en la clave de caché. Por ejemplo, "foo-12: 30" podría describir de forma única el elemento "foo" en el momento de las 12:30. Luego, su aplicación puede acceder a este elemento hasta, digamos, 12:40. En este momento, se podría generar un nuevo elemento, "foo-12: 40" y el elemento antiguo ("foo-12: 30") finalmente caducará una vez que los clientes hayan dejado de acceder a él.
Si su aplicación distribuida puede actualizar y recuperar números de revisión de manera consistente (puede hacerlo, por ejemplo, con doozerd, zookeeper o la solución de base de datos de su elección), también puede codificar este número de revisión como parte de la clave de caché. Alternativamente, también puede utilizar los encabezados HTTP "Última modificación" o "ETag" como algún tipo de número de revisión en su proxy web.