Cache partagé - Meilleures pratiques d'invalidation

Je voudrais savoir quelle serait une meilleure approche pour invalider / mettre à jour des objets de cache.

Conditions préalables

• Avoir un serveur memcached distant (servant de cache pour plusieurs applications)
• Tous les serveurs sont hébergés par azure (régions d'affinité, mêmes centres de données)
• La taille des objets de cache varie de 200 octets à 50 kilo-octets

Approche 1 (stocker dans le cache dès que possible)

1. L'objet A est créé -> stocker dans la base de données et stocker dans le cache
2. Objet A demandé par le client -> vérifier l'existence du cache, sinon extraire de la base de données et stocker dans le cache
3. L'objet A est mis à jour -> stocker dans la base de données, stocker dans le cache

L'approche 1 semble être plus simple. Si quelque chose est créé, mettez-le dans le cache dès que possible. Indépendamment de quelqu'un en aura besoin.

Approche 2 (magasin de cache paresseux)

1. L'objet A est créé -> stocker dans la base de données
2. Objet A demandé par le client -> vérifier l'existence du cache, sinon extraire de la base de données et stocker dans le cache
3. L'objet A est mis à jour -> stocker dans la base de données, supprimer la clé dans le cache

L'approche 2 semble être plus sensible à la mémoire. Dans cette approche, seuls les éléments demandés sont mis en cache.

Question 1: Dans l'esprit de la performance, quelle serait une meilleure approche? La mémoire ni le CPU ne comptent pas encore.

Question 2: Mes pensées sont-elles une sorte d'optimisation prématurée?

Question 3: D' autres réflexions? D'autres approches?

1. Est sans réponse, sauf pour dire que cela dépend. De nombreux facteurs détermineront quelle approche sera la meilleure dans votre cas, par exemple: est-il normal que les objets créés soient récupérés peu de temps après leur création? Quel est le rapport des mises à jour aux accès?
2. Ré. décider que vous avez besoin d'un cache: si vous optimisez sans données, alors oui, c'est une optimisation techniquement prématurée. Je dis techniquement, car l'expérience / la sagesse conventionnelle peuvent vous dire que vous allez avoir besoin d'une sorte de cache. Ré. décider comment le cache fonctionnera le mieux: oui, c'est définitivement une optimisation prématurée.
3. • L'optimisation ne consiste souvent pas à trouver la solution la meilleure / la plus optimale. Il devrait se dérouler comme suit:
     1. Trouvez les goulots d'étranglement dans le système.
     2. Trouvez où vous pouvez faire la plus grande différence avec le moins de travail.
     3. Faites le moins de travail!
     4. Est-ce encore assez rapide? Sinon, passez à # 1.
     5. Terminé!
   • Honnêtement, aucune des approches que vous décrivez ne semble compliquée. Pourquoi ne pas implémenter les deux et voir lequel fonctionne le mieux?
   • L'étape 3 de l'approche n ° 2 pourrait être remplacée par "L'objet A est mis à jour -> stocker dans la base de données, mettre à jour l'entrée dans le cache".

memcached gère les objets avec sa propre stratégie, laquelle objet mis en cache expirera si personne n'y accède ou si memcached manque de mémoire. Par conséquent, votre première approche n'est pas une bonne idée car votre objet dans memcached continuerait à être invalidé en raison d'une mémoire insuffisante lorsque vous créez des objets.

Q1. L'approche 2 serait meilleure en termes de performances car elle n'envoie pas d'objet à memcached, bien que l'amélioration des performances soit très faible.

Q2. C'est dur à dire. Supposons que vous connaissiez le goulot d'étranglement et rédigez les approches, ce ne serait pas prématuré.

Q3. Il existe d'autres approches telles que le cache dans memcached uniquement.