Mi a kiskereskedelmi hálózat technológiai fejlesztő csapata vagyunk. Egyszer a vezetőség feladatot adott, hogy gyorsítsuk meg a volumetrikus számításokat az Apache Ignite és MSSQL kombinációjának felhasználásával, és megmutattak egy weboldalt gyönyörű illusztrációkkal és Java-kód példákkal. Azonnal tetszett a honlap. , amelynek leírása csodákat ígér: nem kell manuálisan telepítenie Java vagy Scala kódját a rács minden egyes csomópontján, és újra telepítenie, amikor a kód megváltozik. A munka során kiderült, hogy a Zero Deployment használata sajátos, és erről szeretnék megosztani néhány dolgot. A cikk alatt megosztom a gondolataimat és a megvalósítás részleteit.
1. A feladat megfogalmazása
A feladat lényege a következő: van egy értékesítési pontokon alapuló tároló (SalesPoint) és egy termékek (Sku) alapú tároló. Az értékesítési pontnak van egy „boltTipe” attribútuma, amely „kis” és „nagy” értékeket vehet fel. Minden értékesítési ponthoz csatlakozik (betöltődik az adatbázisból) a termékkínálat (a bolt termékeinek listája), és információt adunk arról, hogy a megadott dátumtól kezdve az adott termék
kizárásra kerül a kínálatból, vagy hozzáadódik a kínálathoz.
Szükséges egy partícionált gyorsítótár létrehozása az értékesítési pontokról, amely egy hónapra előre tárolja az összes csatlakoztatott termék információját. A működő rendszerrel való kompatibilitás megköveteli, hogy az Ignite ügyfélcsomópont betöltse az adatokat, kiszámítsa az aggregátumot (boltTipe, termékKód, nap, értékesítési_pontok_száma) és visszatöltse az adatbázisba.
2. Irodalom tanulmányozása
Eddig nincs tapasztalatom, így a legalapvetőbb dolgokkal kezdek. Vagyis a publikációk áttekintésével.
A 2016-os cikk hivatkozik az Apache Ignite projekt dokumentációjára, és egyúttal bírálja az elnagyoltságát. Többször is újraolvastam, de a világosság nem érkezik el. Fordulok a hivatalos útmutatóhoz, , ami
optimistán ígéri: «I’ll be up and running in a jiffy!». Megpróbálom beállítani a környezeti változókat, megnézek két Apache Ignite Essentials videót, de a számomra konkrét feladathoz nem voltak túl hasznosak. Sikeresen elindítom az Ignite-ot a parancssorból a standard «example-ignite.xml» fájl segítségével és létrehozom az első alkalmazást, a Maven segítségével. Az alkalmazás működik és használja a Zero Deployment, milyen gyönyörű!
Tovább olvasok, és ott egy példa azonnal használja az affinityKey-t (amelyet korábban SQL-lel kérdeztek le), és még a rejtélyes BinaryObject is alkalmazásra kerül:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); Olvastam róla : bináris formátum — valami hasonló a reflexióhoz, a mezők név szerinti eléréséhez az objektumban. Képes olvasni egy mező értékét anélkül, hogy teljesen deszerializálná az objektumot (memória megtakarítás). De miért használunk BinaryObject-et a Person helyett, amikor ott a Zero Deployment? Miért fordul az IgniteCache<Key,Person> IgniteCache<BinaryObject, BinaryObject>-ra? Még nem világos.
Átdolgozom a Compute Application-t a saját esetemhez. A MSSQL-ben a kiskereskedelmi pontok referencia-azonosítója [id] [int] NOT NULL-ként van meghatározva, cache-t hozok létre hasonlóan.
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")Az xml-konfigban megadom, hogy a cache partícionált.
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
<\/bean>A kiskereskedelmi pontok szerinti partíciózás azt feltételezi, hogy a szükséges aggregátum minden klasztercsomóponton felépül a meglévő salesPointCache rekordok alapján, majd a klienscsomópont elvégzi a végső összesítést.
Olvasom a tutorialt. , hasonlóan járok el. Minden klasztercsomóponton elindítom az IgniteRunnable()-t, körülbelül így:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Hozzáadom az aggregációs és exportálási logikát, és tesztadatokkal indítom. Helyben a fejlesztői szerveren minden működik.
Két tesztszervert indítok CentOs alatt, megadom az ip-címeket a default-config.xml-ben, mindkettőn végrehajtom:
.\/bin\/ignite.sh config\/default-config.xmlMindkét Ignite node elindul és látja egymást. A kliensalkalmazás xml-configjában megadom a szükséges címeket, elindul, hozzáad egy harmadik node-ot a topológiához, majd azonnal ismét kettő lesz. A naplóban a következő szerepel: „ClassNotFoundException: model.SalesPoint” a sorban.
SalesPoint sp=salesPointCache.get(spId);A StackOverflow szerint a hiba oka, hogy a CentOs szervereken nincs a SalesPoint felhasználói osztály. Eltűntünk. Hogyan is van az „you don’t have to manually deploy your Java code on each node” és így tovább? Vagy a „your Java code” — nem a SalesPoint-ra vonatkozik?
Valószínűleg valamit elkerültem — újra kezdem keresni, olvasni és keresni. Egy idő után olyan érzésem van, hogy mindent elolvastam a témában, nincs már új információ. Miközben kerestem, néhány érdekes megjegyzést találtam.
, a GridGain Systems vezető építésze, a StackOverflow-on, 2016 áprilisában:
A Model osztályok nem párhuzamosan települnek, de használhatod a withKeepBinary() flag-et
a cache-n és kérhetsz BinaryObject-okat. Így elkerülheted a deszerializálást
a szerver oldalán, és nem fogsz ClassNotFoundException-t kapni.Még egy tekintélyes vélemény: , a GridGain Systems termékmenedzsere.
Cikk a Habr-on hivatkozik három cikkre Denis Magda: , , 2016-2017 között. A második cikkben Denis javasolja, hogy indítson el egy klasztert a MaintenanceServiceNodeStartup.jar segítségével. Az XML-konfigurációval és a parancssorral történő indítást is lehet használni, de ebben az esetben manuálisan kell elhelyezni a felhasználói osztályokat minden egyes telepített klaszternódra:
Ennyi. Indítsa el (..) a nodet a MaintenanceServiceNodeStartup fájl segítségével, vagy adja át a maintenance-service-node-config.xml-t az Apache Ignite ignite.sh/bat scriptjeinek.
Ha az utóbbit választja, győződjön meg róla, hogy készít egy jar fájlt, amely tartalmazza
az összes osztályt a java/app/common és java/services/maintenance könyvtárakból.
A jar-t hozzá kell adni minden nód classpath-jéhez, ahol a szolgáltatás
telepítve lehet.Valóban, ennyi. Íme, kiderült, hogy miért létezik ez a titokzatos bináris formátum!
3. SingleJar
Denis az én személyes rangsoromban az első helyet foglalja el, szerintem ez a legjobb útmutató az összes elérhető közül. Az ő a GitHubon teljesen kész példát tartalmaz a klaszternódok beállításáról, amelyet különösebb nehézségek nélkül lehet fordítani.
Mintát és hasonlatot követve egyetlen jar fájlt kapok, amely elindítja a „data node”-ot vagy a „client node”-ot a parancssor argumentumától függően. A build elindul és működik. A Zero Deployment legyőzve.
A megabájtos tesztadatok átállása a több tíz gigabájtos éles adatokra megmutatta, hogy a bináris formátum nem vezetett hiábavalósághoz. Szükség volt a memóriafelhasználás optimalizálására a nodokon, és itt a BinaryObject nagyon hasznosnak bizonyult.
4. Következtetések
Az első felrótt kritikája az Apache Ignite projekt dokumentációjának homályosságával kapcsolatban jogosnak bizonyult, 2016 óta nem sokat változott. A kezdőknek nem könnyű működő prototípust összeállítani a weboldal vagy a repository alapján.
A végzett munka alapján az a benyomásom alakult ki, hogy a Zero Deployment működik, de csak rendszer szinten. Körülbelül így: a BinaryObject használatos, hogy a távoli klaszternódok megtanuljanak dolgozni a felhasználói osztályokkal; a Zero Deployment — az Apache Ignite belső mechanizmusa, amely a klaszteren át terjeszti a rendszer objektumokat.
Remélem, hogy a tapasztalataim hasznosak lesznek az új Apache Ignite felhasználók számára.
Mi a technológiai fejlesztési osztály vagyunk.
Forrás: habr.com
