A JBoss Cache egy vállalati szintű klaszterezési megoldás Java-alapú megoldások számára, ami magas rendelkezésreállást nyújt, valamint jelentős mértékben növeli a teljesítményt azáltal, hogy gyorstárazza a felhasználók által gyakran használt Java objektumokat. Az alábbiakban Manik Surtanival, a JBoss Cache projektvezetőjével készült interjút olvashatjuk.
Először is, megemlítenéd, hogy melyek a JBoss Cache leggyakoribb felhasználási módjai, és milyen előnyöket nyújt, különös tekintettel a magas rendelkezésreállásra?
Az adatok kiolvasása perzisztens tárhelyről, különösen adatbázisokból nagyon költséges. Emellett régi jellemzője az adatbázisoknak, hogy nem jól, legalábbis nem olcsón méretezhetőek, amikor a frontendek vagy a kliensek számának növekedéséről van szó. A másik oldalon a processzor magok és a memória egyre olcsóbbakká válnak, ami azt jelenti, hogy egyre többen engedhetik meg maguknak a magas rendelkezésreállású rendszerek létrehozását. „Az oldal karbantartás miatt nem elérhető” üzenet a múlté kell, hogy váljon.
Egy elosztott gyorstár, mint például a JBoss Cache, egy rétegként működhet az adatbázis és a front-endek között, amivel gyors memória hozzáférést nyújt a perzisztens állapothoz. A JBoss Cache lehetővé teszi a memóriában lévő állapot konziszenciáját, naprakészségét, és azt, hogy a memória ne lépje túl a JVM heap méreteit.
A JBoss Cache hogyan működik együtt más népszerű nyílt forráskódú projektekkel, mint például a Hibernate és a JBoss Seam?
Számos nyílt forráskódú projekt használ JBoss Cache-t. A Hibernate (és ennek eredményeképpen a JBoss Application Server EJB3 implementációja) a JBoss Cache-t az adatbázis-háttérrendszerből nyert adategységek tárolására használja, amivel csökken az adatbázis kapcsolódások száma, amikor a tárolt adategységekhez hozzáférünk. Ez persze csak egy rövid áttekintés, a Hibernate emellett sokkal részletesebb és kifinomultabb elosztott gyorstárazást alkalmaz.
A Seam is elosztott gyorstárat használ a generált JSF oldal-töredékek gyorstárazásához, amivel azon szájtok méretezhetőségét növeli, melyeken az oldaltöredékek vagy az egész oldal generálása lassú lehet.
Ezek mellett pedig sok más nyílt forráskódú projekt használja a JBoss Cache-t, köztük a Lucene, a Hibernate Search, a GridGain, és a JBoss alkalmazásszerver HTTP Session klaszterezése, valamint a klaszterezett SSO kódja.
A JBoss Cache két különböző formában jelenik meg: az alap gyorstár és a POJO gyorstár. Ismertetnéd a kettő közötti fő különbségeket?
Az alap gyorstár egyszerűen, egy fastruktúrához hasonló adatszerkezetben tárolja azt, amit belehelyezünk. A kulcs/érték-párok a facsomópontjaiban tárolódnak, és szerializálva vannak a replikáció és a perzisztencia számára.
A POJO Cache, ezzel szemben a felhasználói osztályok introspekciójának egy sokkal kifinomultabb mechanizmusát használja azáltal, hogy „bájtkód-összeszövést” (bytecode weaving) alkalmaz, azaz olyan figyelőket ad hozzá a mezőkhöz, amik értesítik a gyorstárat a mezők módosulásáról. Például egy nagy, összetett objektum tárolása a POJO Cache-ben azt eredményezi, hogy a POJO Cache elemzi az objektum bájtkódját, és csak a mező primitívjeit tárolja a fastruktúrában. És bármikor, amikor az objektum adott mezői megváltoznak, akkor csak ezeket a mezőket replikálják, ami lehetővé teszi számunkra, hogy nagyon hatékony, finomszemcsés replikációt érjünk el. Természetesen vannak még más különbségek is, de ezek a legfontosabbak.
A finomszemcsés replikáció jelentős hatással lehet a POJO és az alap gyorstár közötti teljesítmény különbségére. Vannak erre vonatkozóan becslések vagy összehasonlítások?
Az ilyen összehasonlítások nagymértékben rendszerfüggők, és általános összehasonlításként nem nagy jelentőséggel bírnak. A finomszemcsés replikáció nagy segítség lehet, ha nagy és összetett objektumok vannak a gyorstárunkban. Azonban ha csak karaktersorok tárolására használjuk, akkor nem sokat ér. Ehhez hasonlóan, az egyszerű, egyedi objektumok esetén, például egy „személy” osztály esetén, aminek csak két karaktersor mezője van, a POJO gyorstár inkább hátráltató tényező, mint előny (például a mezőkezelés miatt).
Ezért javaslom mindig, hogy az adott esethez kapcsolódó teljesítményi méréseket végezzenek. Kifejlesztettünk egy keretrendszert a különböző gyorstárak és konfigurációk teljesítményének összehasonlítására, főleg belső használatra a JBoss Cache különböző verzióinak összehasonlításához, de ez letölthető, és eléggé kiterjeszthető ahhoz, hogy egyedi teszteket írjanak hozzá, egyedi objektum-típusok és hozzáférési minták használatával.
Hogyan kezelhető a referenciális integritás, főleg a POJO gyorstár esetén?
Ha az objektumreferenciákra utalsz, akkor itt jön a bájtkód összeszövés a képbe. A POJO-khoz interceptorokat kapcsolunk, és a referenciával ellátott mezőket behelyezzük a gyorstár tartalma alapján.
Miért válasszunk egy helyi gyorstárat mondjuk egy HashMap helyett?
Sokan azt mondják, hogy a Mapek a gyorstárak kiindulópontjai (valójában ezt az érvet használja a JSR-107 JCACHE szakértői csoportjai is a Map kiterjesztéséhez, ami a java.cache.Cache-t eredményezi). Azonban míg a mapek nagyszerűek az egyszerű kulcs/érték-párok tárolására, más jellemzők terén elégtelennek bizonyulhatnak. Az ilyen jellemzők közé tartoznak azok, melyek a gyorstár esetén szükségesek lehetnek, mint például a memória menedzsment (evikció), passziválás és perzisztencia, és egy finomabb szemcsés zárolási modell. A HashMap, hogy csak egy dolgot említsek, nem többszálúsítható. A ConcurrentHashMapek nagyon durva szemcsés zárolást használnak, ami nem teszi lehetővé a nem blokkoló olvasásokat vagy több olvasást egyszerre). Emellett ott vannak egy „rendes” gyorstártól elvárt vállalati jellemzők, ide értve a JTA kompatibilitást, és a figyelők kapcsolódásának lehetőségét.
Tehát míg a Map egy jó kiindulópont, ha bárki úgy érzi, hogy a fent említett jellemzők közül bármelyiket is implementálnia vagy kezelnie kell, akkor egy gyorstárat, nem pedig egy Mapet célszerű használni.
Milyen zárolási sémákat alkalmazol? Ugyanazokat, amiket az adatbázisokban hagyományosan használnak?
A JBoss Cache hagyományosan egy pesszimista zárolási megközelítést alkalmazott: tagszerverenkénti egyetlen zárolás a fastruktúrában. Ezekhez a zárolásokhoz izolációs szinteket rendelünk – az adatbázis elvnek megfelelően– , amik lehetővé teszik többek között a konkurrens figyelők használatát.
Emellett egy optimista zárolási megközelítést is ajánlunk, ami magában foglalja az adatok verziókezelését és minden tranzakció esetén a másolatok fenntartását, a másolatok érvényességének ellenőrzését a fastruktúrához képest a tranzakció lezáráskor. Ez a megközelítés egy erősen konkurrens felállást eredményez egy főleg olvasásokra kihegyezett rendszerben, ahol az olvasásokat sosem blokkolják a konkurrens írások, és feloldottuk azon deadlockok problémáját is, melyek a pesszimistán zárolt rendszerek esetén jelentkeznek.
Most jelentetjük meg a Multi Versioned Concurrency Controlt (MVCC) a JBoss Cache 3.0.0 verziójával, ami jelenleg komoly fejlesztés alatt áll. Ez a zárolási megközelítés a legnépszerűbb az adatbázis rendszerek körében, és a legjobb optimista és pesszimista zárolást nyújtja. Emellett az implementációnk zárolás nélküli lesz az olvasások számára, ami jelentős mértékben meggyorsítja majd a korábbi zárolási sémákat. Ahogy az erre irányuló fejlesztés befejeződik, reméljük, hogy az MVCC-t a JBoss Cache alapértelmezett zárolási mechanizmusává tesszük.
Mesélj most egy kicsit a JGroups integrációról!
A JBoss Cache a JGroups-ot csoportos kommunikációs függvénykönyvtárként használja, hogy egy csoport tagjait detektálja és klasztereket hozzon létre. A JGroups-ot csatornaként is használjuk, amiben egy RPC mechanizmust implementáltunk, azért, hogy megvalósuljon a más csoportok gyorstáraival zajló kommunikáció. A JBoss Cache a JGroups rendkívüli rugalmasságának előnyeit élvezi, valamint a kiterjeszthetőségét a hálózati protokollokban és a finomhangolásban, amivel a gyorstár többek között rögtön használható LAN klasztereken, és áthatol tűzfalakon, illetve WAN klasztereket is létre lehet vele hozni.
Elérhető a gyorstár önmagában is a JBoss Application Server nélkül?
Természetesen. Ez egy nagy félreértés, hogy a JBoss Cache használata a JBoss alkalmazásszerverhez kötött. Ez nem így van. A JBoss Cache-t sokan használják különálló Java programokban, GUI frontendekben, és más alkalmazásszerverekkel. Ez csak egy plusz tényező, hogy a JBoss Application Serverrel is elérhető.
Az adatok replikációja egynél több tagszerverre nagy jelentőséggel bír a hibatűrő viselkedés szempontjából és számos stratégia létezik ennek implementálására. Milyen replikációs modelleket támogat a JBoss Cache?
Jelenleg két replikációs modellt támogatunk. Az egyik a teljes replikáció (TR), a második pedig a buddy replikáció (BR). A teljes replikáció az állapotot a csoport minden tagja számára lemásolja. Ugyan ez egy nagyszerű módja az állapot megosztásának, és így azt is tudjuk biztosítani, hogy failoverezhetünk a csoport bármely másik tagjára, ez azonban a méretezhetőséget gátolja. Ezzel szemben a buddy replikáció a csoport bizonyos tagjait választja csak ki backup célokra, és csak rájuk vonatkoztatva replikálja az állapotot. Ez azt jelenti, hogy a failover akkor a leghatékonyabb, amikor egy adott backup tagszerverre vonatkoztatjuk, persze más tagra vonatkoztatva is működik, mivel az állapotot migráljuk a kérést követően. A buddy replikációt session-ök esetén használhatjuk leginkább, mivel a migráció költséges lehet, és ezért minimalizálni kell arra az esetre, amikor failover esemény történik.
A tagszerver replikáció peer-to-peer modelljét bizonyos architektúrák esetén méretezhetőségi problémákkal kapcsolják össze. Vannak ilyen problémák a JBoss Cache esetén?
A válasz az, hogy nincsenek. A peer-to-peer hálózati munka és a csoportos kommunikáció rendkívül hatékonyak és méretezhetőek, amikor LAN-t és IP Multicastot használunk az adatforgalmazásban. A legmodernebb hálózati hardverek támogatják az IP Multicastot. Azonban a peer-to-peer adatreplikácót – mely során mindenki rendelkezik a rendszer összes állapotával – jellemezhetik méretezhetőségi problémák. Itt ugyanazt említeném meg, ami a teljes replikáció kapcsán már elhangzott, illetve session-ök esetén a buddy replikáció használatát javasoljuk.
A particionáláson is dolgozunk, ami majd abban segít, hogy valóban jól elosszuk az állapotot a teljes csoporton belül, egy valóban méretezhető módon, és ehhez nem lesz szükség session-affinitásra. Reméljük, hogy ez majd mind a buddy, mint a teljes replikációt leváltja.
Milyen trendek jelennek majd meg szerinted a közeljövőben a gyorstárazás és a klaszterezés területén? A JBoss Cache hogyan elégíti majd ki ezeket az új igényeket?
Az elosztott gyorstárazás egyre fontosabbá fog válni, ahogy a hardverek olcsóbbak lesznek, és a processzor gyártók a chipeket több maggal látják el. Ez azt jelenti majd, hogy nagyobb hangsúly helyeződik majd a virtuális gépekre, és nagyobb teher hárul majd az adatbázisokra, hogy ilyen mértékű egyidejűséget kezeljenek. Emellet az elosztott gyorstárazás az egyik legfontosabb megoldást jelenti majd a nagy adatmennyiség okozta szűk keresztmetszetre. Az adat gridek és a számítási felhők növekvő népszerűsége szintén hozzáadódik ehhez, mivel a felhők és a gridek minden tagszervere hozzá kell, hogy férjen az osztott adatokhoz.
A particionálás és az MVCC a JBoss Cache számára azt nyújtja majd, amire szüksége lesz az egy nagyságrenddel nagyobb klaszterek kiszolgálásához.