La réponse de Donnie (sondage) est probablement votre meilleure option - simple et efficace. Il couvrira presque tous les cas (il est peu probable qu'une simple recherche PK nuise aux performances, même sur un site très populaire).
Pour être complet, et si vous vouliez éviter l'interrogation, vous pouvez utiliser un modèle push . Il existe différentes manières décrites dans l'article de Wikipedia. Si vous pouvez conserver un cache en écriture immédiate (chaque fois que vous mettez à jour l'enregistrement, vous mettez à jour le cache), vous pouvez presque complètement éliminer la charge de la base de données.
Cependant, n'utilisez pas de colonne d'horodatage "last_updated". Les modifications dans la même seconde ne sont pas inconnues. Vous pouvez vous en tirer si vous ajoutez des informations supplémentaires (serveur qui a effectué la mise à jour, adresse distante, port, etc.) pour vous assurer que, si deux requêtes arrivent à la même seconde, sur le même serveur, vous pouvez détecter la différence. Si vous avez besoin de cette précision, vous pouvez tout aussi bien utiliser un champ de révision unique (il ne doit pas nécessairement s'agir d'un entier incrémentiel, mais unique dans la durée de vie de cet enregistrement).
Quelqu'un a mentionné des connexions persistantes - cela réduirait le coût de configuration des requêtes d'interrogation (chaque connexion consomme des ressources sur la base de données et la machine hôte, naturellement). Vous garderiez une seule connexion (ou aussi peu que possible) ouverte tout le temps (ou aussi longtemps que possible) et l'utiliseriez (en combinaison avec la mise en cache et la mémorisation, si vous le souhaitez).
Enfin, il existe des instructions SQL qui permettent d'ajouter une condition sur UPDATE ou INSERT. Mon SQl est vraiment rouillé, mais je pense que c'est quelque chose comme UPDATE ... WHERE ... . Pour correspondre à ce niveau de protection, vous devrez effectuer votre propre verrouillage de ligne avant d'envoyer la mise à jour (et toute la gestion des erreurs et le nettoyage que cela pourrait entraîner). Il est peu probable que vous en ayez besoin ; Je le mentionne juste pour être complet.
Modifier :
Votre solution semble correcte (horodatages du cache, requêtes d'interrogation proxy vers un autre serveur). Le seul changement que je ferais est de mettre à jour les horodatages mis en cache à chaque sauvegarde. Cela gardera le cache plus frais. Je vérifierais également l'horodatage directement à partir de la base de données lors de la sauvegarde pour éviter qu'une sauvegarde ne se faufile en raison de données de cache obsolètes.
Si vous utilisez APC pour la mise en cache, un deuxième serveur HTTP n'a pas de sens - vous devrez l'exécuter sur la même machine (APC utilise la mémoire partagée). La même machine physique ferait le travail, mais avec la charge supplémentaire d'un deuxième serveur HTTP. Si vous souhaitez décharger les requêtes d'interrogation sur un deuxième serveur (lighthttpd, dans votre cas), il serait préférable de configurer lightttpd devant Apache sur une deuxième machine physique et d'utiliser un serveur de mise en cache partagé (memcache) afin que le Le serveur lighttpd peut lire les horodatages mis en cache et Apache peut mettre à jour les horodatages mis en cache. La raison de placer lighttpd devant Apache est, si la plupart des requêtes sont des requêtes d'interrogation, d'éviter l'utilisation de processus Apache plus lourds.
Vous n'avez probablement pas du tout besoin d'un deuxième serveur, vraiment. Apache devrait être capable de gérer les requêtes supplémentaires. Si ce n'est pas le cas, je réexaminerai votre configuration (en particulier les directives qui contrôlent le nombre de processus de travail que vous exécutez et le nombre de requêtes qu'ils sont autorisés à gérer avant d'être tués).
