Við erum tækniþróunardeild verslunarnets. Einn daginn settu stjórnendur sér það verkefni að flýta útreikningum í stórum stíl með því að nota Apache Ignite í tengslum við MSSQL og sýndu vefsíðu með fallegum myndskreytingum og dæmum um Java kóða. Mér líkaði strax við síðuna , lýsingin á því lofar kraftaverkum: þú þarft ekki að dreifa Java eða Scala kóðanum þínum handvirkt á hvern hnút í ristinni og endursetja hann í hvert skipti sem hann breytist. Eftir því sem vinnan þróaðist kom í ljós að Zero Deployment hefur sérstaka notkun, eiginleikanum sem ég vil deila. Fyrir neðan klippuna eru hugsanir og útfærsluupplýsingar.
1. Yfirlýsing um vandamálið
Kjarni vandans er sem hér segir. Það er SalesPoint sölustaðaskrá og Sku (birgðahaldseining) vöruskrá. Sölustaðurinn er með eigind „Store type“ með gildin „small“ og „large“. Úrval (listi yfir vörur á sölustað) er tengt hverjum sölustað (hlaðinn úr DBMS) og veittar upplýsingar um að frá tilgreindum degi sé tilgreind vara
útilokað úr úrvalinu eða bætt við úrvalið.
Nauðsynlegt er að skipuleggja deilt skyndiminni sölustaða og geyma í því upplýsingar um tengdar vörur með mánaðar fyrirvara. Samhæfni við bardagakerfið krefst þess að Ignite biðlarahnúturinn hleður gögnum, reiknar samanlagður form (tegund verslunar, vörukóði, dagur, fjöldi_sölupunkta) og hleður því upp aftur í DBMS.
2. Bókmenntafræði
Ég hef enga reynslu ennþá, svo ég er farin að dansa frá eldavélinni. Það er að segja frá endurskoðun rita.
2016. gr inniheldur tengil á skjöl Apache Ignite verkefnisins og á sama tíma ámæli um óljósleika þessara gagna. Ég las það aftur nokkrum sinnum, skýrleiki kemur ekki. Ég vísa til opinberu námskeiðsins Hvaða
lofar bjartsýnn „Þú munt vera kominn í gang í fljótu bragði!“ Ég er að finna út stillingar umhverfisbreytu, horfa á tvö Apache Ignite Essentials myndbönd, en þau voru ekki mjög gagnleg fyrir mitt sérstaka verkefni. Ég ræsti Ignite með góðum árangri frá skipanalínunni með venjulegu skránni „example-ignite.xml“, smíðaði fyrsta forritið með Maven. Forritið virkar og notar Zero Deployment, þvílík fegurð!
Ég las lengra, og þar notar dæmið strax affinityKey (búið til fyrr í gegnum SQL fyrirspurn), og notar jafnvel hið dularfulla BinaryObject:
IgniteCache<BinaryObject, BinaryObject> people
= ignite.cache("Person").withKeepBinary(); Ég las það : tvöfalt snið - eitthvað eins og spegilmynd, aðgangur að sviðum hlutar með nafni. Getur lesið gildi reits án þess að deserialisera hlutinn algjörlega (sparað minni). En hvers vegna er BinaryObject notað í stað persónu, þar sem það er Zero Deployment? Hvers vegna IgniteCache flutt í IgniteCache ? Það er ekki ljóst ennþá.
Ég er að endurgera Compute forritið til að henta mínu tilviki. Aðallykill sölustaðaskrár í MSSQL er skilgreindur sem [id] [int] EKKI NULL, ég bý til skyndiminni á hliðstæðan hátt
IgniteCache<Integer, SalesPoint> salesPointCache=ignite.cache("spCache")Í xml stillingunni gefi ég til kynna að skyndiminni sé skipt
<bean class="org.apache.ignite.configuration.CacheConfiguration">
<property name="name" value="spCache"/>
<property name="cacheMode" value="PARTITIONED"/>
</bean>Skipting eftir sölustöðum gerir ráð fyrir að tilskilin heildarupphæð verði byggð á hverjum klasahnút fyrir salesPointCache færslurnar sem eru tiltækar þar, en eftir það mun biðlarahnúturinn framkvæma endanlega samantekt.
Ég er að lesa kennsluna , ég geri það með hliðstæðum hætti. Á hverjum klasahnút keyri ég IgniteRunnable(), eitthvað á þessa leið:
@Override
public void run() {
SalesPoint sp=salesPointCache.get(spId);
sp.calculateSalesPointCount();
..
}Ég bæti við samansafn og upphleðslurökfræði og keyri það á prófunargagnasetti. Allt virkar staðbundið á þróunarþjóninum.
Ég ræsi tvo CentOs prófunarþjóna, tilgreini IP vistföngin í default-config.xml, keyra á hverjum
./bin/ignite.sh config/default-config.xmlBáðir Ignite hnúðarnir eru í gangi og geta séð hvor annan. Ég tilgreini nauðsynleg heimilisföng í xml stillingum biðlaraforritsins, það byrjar, bætir þriðja hnút við staðfræðina og strax eru tveir hnútar aftur. Skráin sýnir „ClassNotFoundException: model.SalesPoint“ í línunni
SalesPoint sp=salesPointCache.get(spId);StackOverflow segir að ástæðan fyrir villunni sé sú að það er enginn sérsniðinn SalesPoint flokkur á CentOs netþjónum. Við erum komin. Hvað með „þú þarft ekki að dreifa Java kóðanum þínum handvirkt á hvern hnút“ og svo framvegis? Eða snýst „Java kóðann þinn“ ekki um SalesPoint?
Ég hef líklega misst af einhverju - ég byrja aftur að leita, lesa og leita aftur. Eftir smá stund fæ ég á tilfinninguna að ég hafi lesið allt um efnið, það er ekkert nýtt lengur. Á meðan ég var að leita fann ég áhugaverðar athugasemdir.
, aðalarkitekt hjá GridGain Systems, á StackOverflow, apríl 2016:
Model classes are not peer deployed, but you can use withKeepBinary() flag
on the cache and query BinaryObjects. This way you will avoid deserialization
on the server side and will not get ClassNotFoundException.Önnur opinber skoðun: , forstöðumaður vörustjórnunar, GridGain Systems.
Grein um Habré vísar í þrjár greinar eftir Denis Magda: , , 2016-2017. Í annarri greininni stingur Denis upp á því að hefja klasahnút í gegnum MaintenanceServiceNodeStartup.jar. Þú getur líka notað ræsingu með xml stillingum og skipanalínu, en þá þarftu að setja sérsniðna flokka handvirkt á hvern uppsettan klasahnút:
That's it. Start (..) node using MaintenanceServiceNodeStartup file or pass
maintenance-service-node-config.xml to Apache Ignite's ignite.sh/bat scripts.
If you prefer the latter then make sure to build a jar file that will contain
all the classes from java/app/common and java/services/maintenance directories.
The jar has to be added to the classpath of every node where the service
might be deployed.Reyndar, það er það. Hér kemur í ljós, hvers vegna, þetta dularfulla tvöfalda snið!
3.SingleJar
Denis náði fyrsta sæti í persónulegri einkunn minni, IMHO gagnlegasta kennsluefnið af öllu sem til er. Í hans Github inniheldur algjörlega tilbúið dæmi um að setja upp klasahnúta, sem safnar saman án frekari hústöku.
Ég geri það á sama hátt og fæ eina jar skrá sem ræsir „gagnahnút“ eða „viðskiptavinahnút“ eftir skipanalínuröksemdinni. Samkoman byrjar og virkar. Zero Deployment hefur verið sigrað.
Umskiptin frá megabæti af prófunargögnum yfir í tugi gígabæta af bardagagögnum sýndu að tvíundarsniðið er til af ástæðu. Nauðsynlegt var að hámarka minnisnotkun á hnútum og það er þar sem BinaryObject reyndist mjög gagnlegt.
4. Ályktanir
Fyrsta áminningin um óljósleika Apache Ignite verkefnisins reyndist sanngjörn; lítið hefur breyst síðan 2016. Það er ekki auðvelt fyrir byrjendur að setja saman virka frumgerð byggða á vefsíðu og/eða geymslu.
Miðað við niðurstöður vinnunnar var tilfinningin sú að Zero Deployment virkar, en aðeins á kerfisstigi. Eitthvað eins og þetta: BinaryObject er notað til að kenna ytri klasahnútum að vinna með sérsniðnum flokkum; Núll dreifing - innri vélbúnaður
Apache Ignite sjálft og dreifir kerfishlutum um þyrpinguna.
Ég vona að reynsla mín muni nýtast nýjum Apache Ignite notendum.
Heimild: www.habr.com