A memcache belülről

Szinte mindenki ismeri a memcache-t, aki komolyabban foglalkozott már webes alkalmazásfejlesztéssel. A memcache sokunkat megmentett már a lassú oldalak poklától és az évek alatt a cachelés de-facto szabányos eszközévé vált, legalábbis open-source környezetben.

Elgondolkodtunk már valaha azon hogy mitől ilyen gyors a memcache? Mi teszi képessé arra hogy több Gb-nyi adatot ilyen gyorsan írni és olvasni tudjunk? Ez a cikk lecsavarozza a doboz tetejét és segít belenézni.

A cikk itt található: http://blog.kodfejtok.hu/a-memcache-belulrol

Hozzászólások

Igazabol a normalis replikalasi lehetoseg hianya nagy hatrany.

+1 1MB meretkorlat

Attol hogy a cacherol letre tudsz hozni 1(!!!) darab replikat nem leszel sokkal elorebb. Olyan megoldas lenne kezenfekvo legalabbis szamomra, mint mysql eseten, ahol megepitek egy clustert masterekbol es arra felhuzok akar 4-500 gepen is local slaveket es mukodik. Igy az 1 masteres megoldas ekkora halozatban durva merteku adatforgalmat general halal foloslegesen es pl egy session cache borulasnal siman kinullaz tobb100k-s forgalmat.

Amugy ilyen esetben redis +1 esetleg cassandra.

Ebben ugye volatile adatokat szoktuk tarolni. Persze vannak alternativ megoldasok; pl sql cache a belef..ott objektumrol. Igy cca. 5 sec alatt ujja lehet epiteni az instance-t, amit 1-2 min alatt fel is lehet tolteni.
A teheleselosztott/hibaturo mukodes hianya azonban tenyleg erdekes problemat vet fel.
A redis tudja amugy ezt?

Szerintem ti memcached-re gondoltatok.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

Sok meglepetést nem hozott: 20 éve arcitektura tudomány első szemeszter első előadás... De hasznos dolog ismételni a végtelenségig.
---
http://youtu.be/wzEahz7pa7k