La risposta di Donnie (sondaggio) è probabilmente la tua migliore opzione:semplice e funzionante. Coprirà quasi tutti i casi (è improbabile che una semplice ricerca PK danneggerebbe le prestazioni, anche su un sito molto popolare).
Per completezza e se si desidera evitare il polling, è possibile utilizzare un modello push . Ci sono vari modi descritti nell'articolo di Wikipedia. Se riesci a mantenere una cache write-through (ogni volta che aggiorni il record, aggiorni la cache), puoi eliminare quasi completamente il carico del database.
Tuttavia, non utilizzare una colonna timestamp "last_updated". Le modifiche entro lo stesso secondo non sono sconosciute. Potresti farla franca se aggiungi informazioni extra (server che ha eseguito l'aggiornamento, indirizzo remoto, porta, ecc.) Per assicurarti che, se due richieste arrivassero nello stesso secondo, allo stesso server, potresti rilevare la differenza. Se hai bisogno di tale precisione, tuttavia, potresti anche utilizzare un campo di revisione univoco (non deve essere necessariamente un numero intero incrementale, solo univoco all'interno della durata di quel record).
Qualcuno ha menzionato connessioni persistenti:ciò ridurrebbe il costo di installazione delle query di polling (ogni connessione consuma risorse sul database e sulla macchina host, naturalmente). Dovresti mantenere una singola connessione (o il minor numero possibile) sempre aperta (o il più a lungo possibile) e utilizzarla (in combinazione con memorizzazione nella cache e memorizzazione, se lo desideri).
Infine, ci sono istruzioni SQL che consentono di aggiungere una condizione su UPDATE o INSERT. Il mio SQl è davvero arrugginito, ma penso sia qualcosa come UPDATE ... WHERE ... . Per soddisfare questo livello di protezione, dovresti eseguire il tuo blocco di riga prima di inviare l'aggiornamento (e tutta la gestione degli errori e la pulizia che potrebbero comportare). È improbabile che tu abbia bisogno di questo; Lo cito solo per completezza.
Modifica:
La tua soluzione suona bene (timestamp della cache, richieste di polling proxy a un altro server). L'unica modifica che farei è aggiornare i timestamp memorizzati nella cache ad ogni salvataggio. Ciò manterrà la cache più fresca. Controllerei anche il timestamp direttamente dal db durante il salvataggio per evitare che un salvataggio si intrufoli a causa di dati della cache obsoleti.
Se usi APC per la memorizzazione nella cache, un secondo server HTTP non ha senso:dovresti eseguirlo sulla stessa macchina (APC utilizza la memoria condivisa). La stessa macchina fisica farebbe il lavoro, ma con il sovraccarico aggiuntivo di un secondo server HTTP. Se vuoi scaricare le richieste di polling su un secondo server (lighttpd, nel tuo caso), allora sarebbe meglio configurare lightttpd davanti ad Apache su una seconda macchina fisica e usare un server di cache condiviso (memcache) in modo che il Il server lighttpd può leggere i timestamp memorizzati nella cache e Apache può aggiornare i timestamp memorizzati nella cache. Il motivo per mettere lighttpd davanti ad Apache è, se la maggior parte delle richieste sono richieste di polling, evitare l'utilizzo più pesante del processo Apache.
Probabilmente non hai affatto bisogno di un secondo server, davvero. Apache dovrebbe essere in grado di gestire le richieste aggiuntive. In caso contrario, rivedrei la tua configurazione (in particolare le direttive che controllano quanti processi di lavoro esegui e quante richieste possono gestire prima di essere uccisi).
