Donnies svar (omröstning) är förmodligen ditt bästa alternativ - enkelt och fungerar. Det kommer att täcka nästan alla fall (det är osannolikt att en enkel PK-sökning skulle skada prestandan, även på en mycket populär webbplats).
För fullständighetens skull, och om du vill undvika omröstning, kan du använda en push-modell . Det finns olika sätt som beskrivs i Wikipedia-artikeln. Om du kan upprätthålla en genomskrivningscache (varje gång du uppdaterar posten uppdaterar du cachen), så kan du nästan helt eliminera databasbelastningen.
Använd dock inte en tidsstämpel "last_updated"-kolumn. Redigeringar inom samma sekund är inte ovanliga. Du kan komma undan med det om du lägger till extra information (server som gjorde uppdateringen, fjärradress, port, etc) för att säkerställa att du, om två förfrågningar kom in på samma sekund, till samma server, kunde upptäcka skillnaden. Men om du behöver den precisionen kan du lika gärna använda ett unikt revisionsfält (det behöver inte nödvändigtvis vara ett inkrementerande heltal, bara unikt inom den postens livslängd).
Någon nämnde beständiga anslutningar - detta skulle minska installationskostnaden för pollingfrågor (varje anslutning förbrukar resurser på databasen och värddatorn, naturligtvis). Du skulle hålla en enda anslutning (eller så få som möjligt) öppen hela tiden (eller så länge som möjligt) och använda den (i kombination med cachning och memoisering, om så önskas).
Slutligen finns det SQL-satser som låter dig lägga till ett villkor på UPDATE eller INSERT. Min SQL rostar verkligen, men jag tror att det är ungefär som UPDATE ... WHERE ... . För att matcha denna skyddsnivå måste du göra din egen radlåsning innan du skickar uppdateringen (och all felhantering och rensning som kan medföra). Det är osannolikt att du skulle behöva detta; Jag nämner det bara för fullständighetens skull.
Redigera:
Din lösning låter bra (cachetidsstämplar, proxypolling-förfrågningar till en annan server). Den enda ändring jag skulle göra är att uppdatera de cachade tidsstämplarna vid varje lagring. Detta kommer att hålla cachen fräschare. Jag skulle också kontrollera tidsstämpeln direkt från db:n när jag sparade för att förhindra att en lagring smyger sig in på grund av inaktuell cachedata.
Om du använder APC för cachelagring är en andra HTTP-server inte vettig - du måste köra den på samma maskin (APC använder delat minne). Samma fysiska maskin skulle göra jobbet, men med extra overhead från en andra HTTP-server. Om du vill avlasta pollingförfrågningarna till en andra server (lighttpd, i ditt fall), så skulle det vara bättre att ställa in lightttpd framför Apache på en andra fysisk maskin och använda en delad cachningsserver (memcache) så att lighttpd-servern kan läsa de cachade tidsstämplarna och Apache kan uppdatera de cachade tidsstämplarna. Skälet för att sätta lighttpd framför Apache är, om de flesta förfrågningar är pollingförfrågningar, att undvika den tyngre Apache-processen.
Du behöver förmodligen inte en andra server alls, egentligen. Apache bör kunna hantera de ytterligare förfrågningarna. Om det inte går, skulle jag gå igenom din konfiguration igen (särskilt direktiven som styr hur många arbetsprocesser du kör och hur många förfrågningar de får hantera innan de dödas).