Caché compartida: mejor práctica de invalidación

Me gustaría saber cuál sería un mejor enfoque para invalidar / actualizar objetos de caché.

Prerrequisitos

• Tener un servidor memcached remoto (que sirve como caché para múltiples aplicaciones)
• Todos los servidores están alojados por azure (regiones de afinidad, mismos centros de datos)
• El tamaño del objeto de caché varía de 200 bytes a 50 kilobytes

Enfoque 1 (almacenar en caché lo antes posible)

1. Se crea el objeto A -> almacenar en base de datos y almacenar en caché
2. Objeto A solicitado por el cliente -> verificar la existencia de la memoria caché, de lo contrario, buscar de la base de datos y almacenar en la memoria caché
3. El objeto A se actualiza -> almacenar en la base de datos, almacenar en caché

El enfoque 1 parece ser más directo. Si se crea algo, colóquelo en la memoria caché lo antes posible. Independientemente de que alguien lo necesite.

Enfoque 2 (almacén de caché perezoso)

1. Se crea el objeto A -> almacenar en la base de datos
2. Objeto A solicitado por el cliente -> verificar la existencia de la memoria caché, de lo contrario, buscar de la base de datos y almacenar en la memoria caché
3. El objeto A se actualiza -> almacenar en la base de datos, eliminar clave en caché

El enfoque 2 parece ser más consciente de la memoria. En este enfoque, solo los elementos solicitados van a la memoria caché.

Pregunta 1: Teniendo en cuenta el rendimiento, ¿cuál sería un mejor enfoque? La memoria ni la CPU aún no cuentan.

Pregunta 2: ¿Son mis pensamientos una especie de optimización prematura?

Pregunta 3: ¿ Alguna otra idea? Otros enfoques?

1. No tiene respuesta, excepto para decir que depende. Hay muchos factores que determinarán qué enfoque será el mejor en su caso, por ejemplo: ¿Es normal que los objetos creados se recuperen poco después de su creación? ¿Cuál es la proporción de actualizaciones a accesos?
2. Re. decidir que necesita un caché: si está optimizando sin datos, entonces sí, es una optimización técnicamente prematura. Lo digo técnicamente, ya que la experiencia / sabiduría convencional puede decirle que necesitará algún tipo de caché. Re. decidir cómo funcionará mejor el caché: sí, definitivamente es una optimización prematura.
3. • La optimización a menudo no se trata de encontrar la mejor / más óptima solución. Debe ir de la siguiente manera:
     1. Encuentra los cuellos de botella en el sistema.
     2. Encuentre dónde puede hacer la mayor diferencia con la menor cantidad de trabajo.
     3. ¡Haz la menor cantidad de trabajo!
     4. ¿Ya es lo suficientemente rápido? Si no, ve al # 1.
     5. ¡Hecho!
   • Honestamente, ninguno de los enfoques que describe suena complicado. ¿Por qué no implementar ambos y ver cuál funciona mejor?
   • El paso 3 en el enfoque # 2 podría cambiarse a "El objeto A se actualiza -> almacenar en la base de datos, actualizar la entrada en la memoria caché".

memcached gestiona objetos con su propia política, cuyo objeto en caché caducaría si nadie accede a él o si memcached se queda sin memoria. Por lo tanto, su primer enfoque no es una buena idea ya que su objeto en memcached seguiría siendo invalidado debido a la falta de memoria cuando está creando objetos.

Q1. El enfoque 2 sería mejor en términos de rendimiento porque no envía objetos a memcached, aunque la mejora del rendimiento es muy pequeña.

Q2 Es difícil de decir. Suponga que conoce el cuello de botella y redacte los enfoques, no sería prematuro.

Q3. Hay otro enfoque, como la memoria caché solo en memcached.