Tailsweep
Svenska UK

Meny

  • Hem
  • Tailsweep
  • Tailsweep Blog Search
  • Tailsweeps Blogg
  • Google group
  • AddThis Social Bookmark Button

Projekt

  • Mammatus
  • Parhely
  • Haloe
  • AbstractCache
  • Utils

Arkiv

  • juni 2008
  • maj 2008
  • mars 2008
  • februari 2008
  • januari 2008
  • december 2007

Sidor

  • Kontakt

Kategorier

    AJAX
    Backup
    BigTable
    Browser
    cache
    Geo
    haloe
    Hibernate
    Javascript
    Job
    Lucene
    Mail
    Monitor
    Monitoring
    MySQL
    optimization
    regex
    release
    SCM
    Server
    sharding
    Spatial
    Tools
    Allmänt

Prenumerera

RSS Senaste nytt som RSS

Asymmetrisk Cache

Den tidigare implementationen som jag skrivit om (SymmetricCache) garanterar att alla noder i ett kluster har samma data. Problemet med en sån lösning är att om datamängden blir stor så blir det mycket dyrt och svårt att skala ut. I det långa loppet så är det i princip omöjligt att alla noder i ett kluster ska ha samma tillstånd. Antingen tar minnet eller diskkapaciteten slut (detta gäller naturligtvis stora webapplikationer). För att kunna skala ut rejält så behövs en asymmetrisk modell. Detta är precis vad jag tagit fram och jag kallar den lite lamt “AsymmetricCache”.Nyckel/värdeparen sprids jämnt över klustret med lastbalansering och replikeras till X servrar. X bör vara 1 för minnescachar och 2 eller högre för diskcachar om en cachemiss är att betrakta som dataförlust. Detta är en klient/server lösning som fungerar ungefär som memcached.MemCached klienterna använder sig av en asymmetrisk modell när de väljer vilken server som ska få lagra vilket data. Den modellen baserar sig på en algoritm som kallas Consistent hash och är vanlig bland webcachar i allmänhet. Problemet med memcached är att det inte finns en mekanism som håller koll på vilken server vad är lagrat. Pga detta så kan man inte använda memcached för annat än transient data där en cachemiss trots att datat finns lagrat nånstans inte betraktas som dataförlust. Memcached största styrka är att den är så enkel att hantera både på klient och serversidan och är mycket testad och robust.En annan svaghet är att om man lägger till servrar så måste alla klienters konfiguration uppdateras och hela klustret omhashas, vilket betyder att klienterna tappar information om vart de lagrat tidigare data, vilket i sin tur kan ge en cachemiss trots att datat finns nånstans i klustret. Eftersom consistent hash används så måste dock inte hela klustrets info kastas.Features hos AsymetricCache:

  • JGroups för notifiering om medlemskap och datatransport i gruppen
  • Man kan lägga till en ny server utan att uppdatera klienterna
  • En för klienterna gemensam KeyAddressMap som håller koll på vilken server som vilket nyckel/värdepar finns.
  • Distribuerar varje nyckel/värdepar till “NumReplicas” servrar, vilket är lämpligt om denna cache är tänkt som lagringsyta.

Du hittar implementationen i Subversion där den heter AsymmetricJgroupsCacheEngine. Som vanligt hittar du exempel på hur den konfas i PlainCacheTest och i metoden testAsymmetricClient1()

asymmetricdisk.jpg
Etiketter:asymmetric, cache, consistent hash, distributed, memcached

11 months, 4 weeks ago , måndag, januari 14th, 2008
Postad i cache
Feed för det här inlägget
 Lämna svar
 trackback

Leave a Reply

*
To prove you're a person (not a spam script), type the security text shown in the picture. Click here to regenerate some new text.
Click to hear an audio file of the anti-spam word

Copyright © 2007 Tailsweep AB

Tailsweep development Blog is proudly powered by WordPress
Entries (RSS) and Comments (RSS).