Cette question concerne les meilleures pratiques en architecture.
Notre architecture actuelle
J'ai une classe PHP qui accède à MySQL pour les informations utilisateur. Appelons ça User
. User
est accessible plusieurs fois, nous avons donc implémenté des couches de mise en cache pour réduire la charge.
La première couche est ce que nous appelons le cache "par demande". Une fois les données récupérées de MySQL, nous stockons les données dans une propriété privée de User
. Toute demande ultérieure de données renvoie la propriété au lieu de demander à nouveau les données à MySQL.
Étant donné que la demande Web vit et meurt sur une base par demande, ce cache empêche uniquement l'application d'accéder à MySQL plus d'une fois dans une seule demande.
Notre deuxième couche est Memcached. Lorsque la propriété privée est vide, nous vérifions d'abord Memcached pour les données. Si Memcached est vide, nous interrogeons MySQL pour les données, mettons à jour Memcached et mettons à jour la propriété privée de User
.
La question
Notre application est un jeu, et il est parfois impératif que certaines données soient aussi à jour que possible. En l'espace d'environ cinq minutes, une demande de lecture des données utilisateur peut se produire 10 ou 11 fois; alors une mise à jour peut se produire. Les demandes de lecture suivantes doivent être à jour ou les mécanismes de jeu échouent.
Donc, ce que nous avons fait, c'est implémenter un morceau de code qui est exécuté lorsqu'une mise à jour de la base de données se produit. Ce code définit la clé dans Memcached avec les données mises à jour, de sorte que toutes les demandes ultérieures à Memcached sont à jour.
Est-ce optimal? Y a-t-il des problèmes de performances ou d'autres "accrochages" dont nous devrions être conscients lorsque nous essayons de maintenir une sorte de "cache vivant" comme celui-ci?