Bonjour, bienvenue pour l’épisode 2, sur le cache.
Commençons par un adage connu de Phil Karlton :
“Il n’y a que deux choses compliquées en informatique : invalider le cache et nommer les choses.”
Bien utiliser le cache est complexe, mais le concept est simple.
Un carnet d’adresses
Dans le dernier (et premier) épisode sur les listes chaînées, pour retrouver mon ami Dave, je devais appeler Alice puis Bob puis Carol. Beaucoup de gens dérangés pour pas grand-chose.
On peut apporter une solution très simple : garder un carnet d’adresses. Je note le numéro de Dave, et peut-être même celui de Bob et Carol.
À chaque fois que je voudrai appeler Dave, je l’aurai directement en ligne sans déranger personne : je viens d’inventer le cache !
Le cache est mort, vive le cache !
Le problème bien sûr, c’est quand Dave change de numéro : plus moyen de le joindre !
On peut voir trois problèmes immédiats : le premier, c’est quand le numéro n’est pas attribué. Pas de Dave, fin de l’histoire. Si je n’ai pas d’autre moyen de le contacter, c’est fichu.
Mauvais destinataire
Le deuxième est peut-être pire : le numéro a été réattribué entre temps. En fonction de votre phrase d’accroche, les conséquences sont variables.
Si je commence par des familiarités, c’est embarrassant mais pas bien dangereux. Si j’envoie le numéro de ma carte bleue ou autre donnée sensible, c’est dramatique.
Imaginons maintenant que j’envoie un SMS à ce numéro, “OK pour ce soir”. Je supposais que Dave allait réserver des places de cinéma et venir à 20h, personne. Dommage.
Parenthèse : chez le mauvais destinataire
Petite digression : imaginons maintenant que la personne d’en face, disons Bernard, était elle aussi en train d’attendre un SMS de confirmation, et dans sa précipitation n’a pas vérifié la source du message, et répond “OK”.
Non seulement j’ai maintenant une grande confiance que Dave sera au cinéma, et c’est toujours aussi faux, mais en plus Bernard aura fait quelque chose, disons réserver deux autres places pour un autre film, en pensant que cela venait d’un autre ami.
Au moins nous serons deux à avoir l’air bête, mais c’est une piètre consolation.
La morale de l’histoire, c’est qu’il faut être clair quand on communique : si les humains peuvent se faire avoir, les ordinateurs qui sont très bêtes ne risquent pas de faire mieux.
La chaîne est rompue
Le troisième problème du cache, c’est que la chaîne est rompue.
Je faisais bien confiance à Alice pour me passer Dave, peut-être que quelqu’un me demandait à moi le numéro de Dave. Je ne l’appelle pas à chaque fois que je passe son numéro pour vérifier que c’est encore le bon : mon cache est corrompu.
Expiration du cache
La solution serait que Dave prévienne quand il change de numéro de téléphone. Celui qui sait que la donnée a changé, ici Dave, devrait prévenir ceux qui gardent ses données en cache, ici moi… encore faut-il que Dave sache qui cache.
Quitte à ne pas savoir, il pourrait demander à ses amis les plus proches de répandre la nouvelle. C’est peut-être faisable, peut-être pas, compliqué certainement, mais en tout cas dans l’intervalle il y a des gens qui ont l’ancien numéro.
Parenthèse : redirect
Dans la vraie vie, vous pourriez imaginer des parades subtiles : Dave a un deuxième téléphone qu’il garde sur lui et pendant un temps, Dave répond aux deux numéros, et rappelle à chacun qu’il faut utiliser le nouveau numéro, ou met en place un répondeur automatique, voire plus simplement un renvoi d’appel.
Voilà, ça n’avait rien à voir avec le cache, mais vous venez de comprendre les redirections :)
Du cache partout
Vous voyez que la recette est simple, l’idée vient facilement à n’importe qui. On a du cache partout dans notre vie, et dans nos logiciels.
Dans le cas qui m’intéresse, une appli Web Ruby on Rails, on a du cache à tous les niveaux :
- votre base de données met des requêtes et donnés en cache
- Rails a plusieurs systèmes de cache (sur ses vues et partials etc)
- votre serveur applicatif ou serveur web également (a minima sur les fichiers)
- toute configuration que vous mettez en bonus, par exemple un reverse-proxy comme Varnish dont c’est exactement le job
- parfois le proxy de votre connexion Internet peut le faire aussi. Imaginons un réseau d’entreprise où tout le monde va sur la page d’un site d’actu : il peut le mettre en cache si c’est le même (en HTTPS il ne le saura pas ; chacun connecté sur son compte, le cache serait abusif aussi ; mais bon vous avez l’idée)
- et on vous a probablement déjà demandé de “vider le cache de votre navigateur” qui applique lui aussi ce genre de techniques pour ne pas tout re-télécharger à chaque fois !
Voilà, dans un domaine particulier, j’ai pu citer six endroits où l’on met habituellement un cache.
Le problème est que tous ces caches sont appelés… “le cache”.
Cache de noeuds
C’est pourquoi je recommande de “désambiguiser” : utiliser le même nom pour des choses différentes ? Non merci, faites-vous préciser et précisez-le.
(À l’opposé, des noms différents pour la même chose, c’est moins dangereux mais ça peut souvent être un signe d’ambiguïté à lever. Essayez, le pire qui puisse vous arriver c’est d’apprendre des choses dans l’intervalle !)
Et voilà !
Vous venez de comprendre pourquoi l’invalidation du cache, c’est difficile !
J’accepte les critiques sur cet épisode et les idées pour les suivants sur twitter : @zen_m4
Merci et à bientôt !