Donnie's antwoord (peiling) is waarschijnlijk de beste optie - eenvoudig en werkt. Het dekt bijna alle gevallen (het is onwaarschijnlijk dat een eenvoudige PK-lookup de prestaties zou schaden, zelfs op een zeer populaire site).
Voor de volledigheid, en als je polling wilt vermijden, kun je een push-model . Er zijn verschillende manieren beschreven in het Wikipedia-artikel. Als u een doorschrijfcache kunt onderhouden (elke keer dat u het record bijwerkt, werkt u de cache bij), dan kunt u de databasebelasting bijna volledig elimineren.
Gebruik echter geen tijdstempel "last_updated" kolom. Bewerkingen binnen dezelfde seconde zijn niet ongehoord. Je zou ermee weg kunnen komen als je extra informatie toevoegt (server die de update heeft uitgevoerd, extern adres, poort, enz.) om ervoor te zorgen dat, als twee verzoeken op dezelfde seconde binnenkomen, bij dezelfde server, je het verschil kunt detecteren. Als je die precisie echter nodig hebt, kun je net zo goed een uniek revisieveld gebruiken (het hoeft niet per se een oplopend geheel getal te zijn, het hoeft alleen uniek te zijn binnen de levensduur van dat record).
Iemand noemde permanente verbindingen - dit zou de installatiekosten van de polling-query's verlagen (elke verbinding verbruikt natuurlijk bronnen op de database en de hostmachine). Je zou een enkele verbinding (of zo min mogelijk) altijd (of zo lang mogelijk) open houden en die gebruiken (in combinatie met caching en memoization, indien gewenst).
Ten slotte zijn er SQL-instructies waarmee u een voorwaarde kunt toevoegen aan UPDATE of INSERT. Mijn SQL is echt aan het roesten, maar ik denk dat het zoiets is als UPDATE ... WHERE ... . Om dit niveau van bescherming te evenaren, zou u uw eigen rijvergrendeling moeten doen voordat u de update verzendt (en alle foutafhandeling en opschoning die mogelijk met zich meebrengt). Het is onwaarschijnlijk dat je dit nodig hebt; Ik vermeld het alleen voor de volledigheid.
Bewerken:
Uw oplossing klinkt goed (cache-tijdstempels, proxy-pollingverzoeken naar een andere server). De enige wijziging die ik zou aanbrengen is om de in de cache opgeslagen tijdstempels bij elke opslag bij te werken. Hierdoor blijft de cache verser. Ik zou ook de tijdstempel rechtstreeks vanuit de db controleren bij het opslaan om te voorkomen dat een opslag binnensluipt vanwege verouderde cachegegevens.
Als u APC gebruikt voor caching, heeft een tweede HTTP-server geen zin - u zou deze op dezelfde machine moeten uitvoeren (APC gebruikt gedeeld geheugen). Dezelfde fysieke machine zou het werk doen, maar met de extra overhead van een tweede HTTP-server. Als je de polling-verzoeken naar een tweede server wilt verplaatsen (in jouw geval lighttpd), dan is het beter om lightttpd voor Apache in te stellen op een tweede fysieke machine en een gedeelde caching-server (memcache) te gebruiken zodat de lighttpd-server kan de in de cache opgeslagen tijdstempels lezen en Apache kan de in de cache opgeslagen tijdstempels bijwerken. De reden om lighttpd voor Apache te plaatsen is, als de meeste verzoeken pollingverzoeken zijn, om het zwaardere Apache-procesgebruik te vermijden.
Je hebt waarschijnlijk helemaal geen tweede server nodig. Apache zou de aanvullende verzoeken moeten kunnen afhandelen. Als dit niet het geval is, zou ik uw configuratie opnieuw bekijken (met name de richtlijnen die bepalen hoeveel werkprocessen u uitvoert en hoeveel verzoeken ze mogen verwerken voordat ze worden gedood).