Odpowiedź Donnie (odpytywanie) jest prawdopodobnie najlepszą opcją - prosta i działa. Obejmuje prawie każdy przypadek (jest mało prawdopodobne, aby proste wyszukiwanie PK wpłynęło negatywnie na wydajność, nawet w bardzo popularnej witrynie).
Aby uzyskać kompletność i jeśli chcesz uniknąć odpytywania, możesz użyć modelu push . W artykule w Wikipedii opisano różne sposoby. Jeśli możesz utrzymać pamięć podręczną z zapisem (za każdym razem, gdy aktualizujesz rekord, aktualizujesz pamięć podręczną), możesz prawie całkowicie wyeliminować obciążenie bazy danych.
Nie używaj jednak kolumny sygnatury czasowej „last_updated”. Zmiany w tej samej sekundzie nie są niespotykane. Możesz to ujść na sucho, jeśli dodasz dodatkowe informacje (serwer, który wykonał aktualizację, adres zdalny, port itp.), aby zapewnić, że jeśli dwa żądania nadejdą w tej samej sekundzie, do tego samego serwera, możesz wykryć różnicę. Jeśli jednak potrzebujesz takiej precyzji, równie dobrze możesz użyć unikalnego pola wersji (niekoniecznie musi to być rosnąca liczba całkowita, po prostu unikatowe w okresie życia tego rekordu).
Ktoś wspomniał o stałych połączeniach - obniżyłoby to koszt konfiguracji zapytań odpytujących (oczywiście każde połączenie zużywa zasoby bazy danych i hosta). Utrzymywałbyś jedno połączenie (lub jak najmniej) otwarte przez cały czas (lub tak długo, jak to możliwe) i używaj go (w połączeniu z buforowaniem i zapamiętywaniem, jeśli chcesz).
Na koniec istnieją instrukcje SQL, które umożliwiają dodanie warunku przy UPDATE lub INSERT. Mój SQL naprawdę rdzewieje, ale myślę, że to coś w stylu UPDATE ... WHERE ... . Aby osiągnąć ten poziom ochrony, musisz wykonać własne blokowanie wierszy przed wysłaniem aktualizacji (i całą obsługę błędów i czyszczenie, które mogą się z tym wiązać). Jest mało prawdopodobne, żebyś tego potrzebował; Wspominam o tym tylko dla kompletności.
Edytuj:
Twoje rozwiązanie brzmi dobrze (sygnatury czasowe pamięci podręcznej, żądania sondowania proxy do innego serwera). Jedyną zmianą, jaką bym wprowadził, jest aktualizacja zapisanych w pamięci podręcznej znaczników czasu przy każdym zapisie. Dzięki temu pamięć podręczna będzie świeższa. Podczas zapisywania sprawdzałbym również znacznik czasu bezpośrednio z bazy danych, aby zapobiec wkradaniu się zapisu z powodu nieaktualnych danych z pamięci podręcznej.
Jeśli używasz APC do buforowania, to drugi serwer HTTP nie ma sensu - musiałbyś go uruchomić na tej samej maszynie (APC używa pamięci współdzielonej). Pracę wykonywałaby ta sama fizyczna maszyna, ale z dodatkowym obciążeniem drugiego serwera HTTP. Jeśli chcesz przenieść żądania odpytywania na drugi serwer (w twoim przypadku lighttpd), lepiej byłoby ustawić lightttpd przed Apache na drugiej maszynie fizycznej i użyć współdzielonego serwera buforowania (memcache), aby Serwer lighttpd może odczytywać buforowane znaczniki czasu, a Apache może aktualizować buforowane znaczniki czasu. Uzasadnieniem umieszczenia lighttpd przed Apache jest, jeśli większość żądań to żądania odpytywania, aby uniknąć cięższego użycia procesu Apache.
Prawdopodobnie w ogóle nie potrzebujesz drugiego serwera. Apache powinien być w stanie obsłużyć dodatkowe żądania. Jeśli nie, to ponownie przyjrzę się twojej konfiguracji (w szczególności dyrektywom, które kontrolują liczbę uruchamianych procesów roboczych i liczbę żądań, które mogą obsłużyć, zanim zostaną zabite).
