Отговорът на Дони (анкета) е може би най-добрият ви вариант - прост и работи. Ще обхване почти всеки случай (малко вероятно е простото търсене на PK да навреди на производителността, дори на много популярен сайт).
За пълнота и ако искате да избегнете допитване, можете да използвате push-модел . Има различни начини, описани в статията на Wikipedia. Ако можете да поддържате кеша чрез запис (всеки път, когато актуализирате записа, актуализирате кеша), тогава можете почти напълно да елиминирате натоварването на базата данни.
Въпреки това не използвайте колона за времеви клеймо "last_updated". Редактирането в рамките на една и съща секунда не е нещо нечувано. Можете да се разминете, ако добавите допълнителна информация (сървър, който е извършил актуализацията, отдалечен адрес, порт и т.н.), за да сте сигурни, че ако две заявки постъпят в една и съща секунда, към същия сървър, можете да откриете разликата. Ако имате нужда от тази прецизност обаче, можете също да използвате уникално поле за ревизия (не е задължително то да е нарастващо цяло число, просто уникално в рамките на живота на този запис).
Някой спомена постоянни връзки - това би намалило разходите за настройка на заявките за анкета (естествено всяка връзка консумира ресурси на базата данни и хост машината). Бихте поддържали една връзка (или възможно най-малко) отворена през цялото време (или колкото е възможно по-дълго) и ще я използвате (в комбинация с кеширане и запаметяване, ако желаете).
И накрая, има SQL изрази, които ви позволяват да добавите условие за UPDATE или INSERT. Моят SQl наистина ръждясва, но мисля, че е нещо като UPDATE ... WHERE ... . За да съответствате на това ниво на защита, ще трябва да направите собствено заключване на редове, преди да изпратите актуализацията (и цялата обработка на грешки и почистване, което може да доведе). Малко вероятно е да имате нужда от това; Споменавам го само за пълнота.
Редактиране:
Вашето решение звучи добре (кеш времеви марки, заявки за запитване на прокси към друг сървър). Единствената промяна, която бих направил, е да актуализирам кешираните времеви марки при всяко записване. Това ще запази кеша по-свеж. Също така бих проверил клеймото за време директно от db при записване, за да предотвратя промъкване на запис поради остарели данни в кеша.
Ако използвате APC за кеширане, тогава втори HTTP сървър няма смисъл - ще трябва да го стартирате на същата машина (APC използва споделена памет). Същата физическа машина ще върши работата, но с допълнителни разходи за втори HTTP сървър. Ако искате да заредите заявките за запитване на втори сървър (lighthttpd, във вашия случай), тогава би било по-добре да настроите lightttpd пред Apache на втора физическа машина и да използвате споделен сървър за кеширане (memcache), така че lighttpd сървърът може да чете кешираните времеви печати, а Apache може да актуализира кешираните времеви печати. Обосновката за поставянето на lighttpd пред Apache е, ако повечето заявки са заявки за анкета, да се избегне използването на по-тежкия процес на Apache.
Вероятно изобщо нямате нужда от втори сървър. Apache трябва да може да се справи с допълнителните заявки. Ако не може, ще прегледам отново конфигурацията ви (по-конкретно директивите, които контролират колко работни процеси изпълнявате и колко заявки им е разрешено да обработват, преди да бъдат убити).
