updejt cache-a i kako spreciti efekat lavine?

[ivanhoe]

Krenuo sam da radim na jednom sistemu koji ce (bar se nadamo) da ima heavy load, i koristicu agresivno kesiranje gde god mogu. Jedna stvar koja me brine oko te arhitekture je situacija kad kesirani podatak postane nevalidan (expire-uje) i treba ga osveziti. Kod vecine cache sistema koje sam gledao (memcache, APC) ne postoji nikakav sistem zastite da spreci da svi klijenti krenu da istovremeno updejtuju cache, sto (teoretski) moze da stvori strasan peak na bazi (pogotovo ako se osvezavaju i podaci u bazi pa dodje do lockovanja), sto opet za posledicu ima da se sve uspori, pa jos klijenata naleti koji isto krenu da salju upite bazi i onda sve pukne najstrasnije...

koje su tehnike da se to spreci?

Jedna fora koju znam je da se cache ne updejtuje iz klijenta, nego periodicno iz cron procesa, ali to mi nije zgodno bas uvek (jer onda serviram zastarele podatke, sve dok cron ne odradi posao). Druga stvar koja mi je pala na pamet je da se doda neka vrsta semafora, pa kad prvi proces krene da updejtuje, on stavi lock, tako da drugi ne pokusavaju updejt, ali to bas nije trivijalno da se uradi u php-u.
Any other idea?

[zira]

Pitanje je sta kesiras i koliko je dopustljivo da neko dobije sadrzaj koji nije 100% svjez...
Ukoliko ima jako malo insert/update u odnosu na select, mozes brigu o kešu prebrinuti u trenutku kada se desi insert/update - tada osvjeziti keš. Sto znaci da klijenti uvijek citaju samo iz keša, tj keš nema vrijeme isticanja sam po sebi.

To sa semaforima... pa moze ti posluziti obican fajl na disku, prvi proces koji krene da radi update ga setuje i svi ostali samo provjere da je update u toku i "iskuliraju". Mozda nesto propustam, sutra idem na odmor