Kaixo! Nire izena Alexey Pyankov da, Sportmaster konpainiako garatzailea naiz. Horretan 2012an Sportmaster webguneko lanak nola hasi ziren kontatu nion, zein ekimen “bultzatzea” lortu genuen eta alderantziz, zein arrasto bildu genuen.
Gaur beste gai bati jarraitzen dioten pentsamenduak partekatu nahi ditut: java backend-erako cache-sistema bat aukeratzea guneko administrazio-eremuan. Trama honek esanahi berezia du niretzat - istorioa 2 hilabetez bakarrik zabaldu zen arren, 60 egun horietan 12-16 orduz lan egin genuen eta egun bakar bat ere gabe. Inoiz ez nuen pentsatu edo imajinatu hain gogor lan egitea posible zenik.
Horregatik, testua 2 zatitan banatu dut guztiz ez kargatzeko. Aitzitik, lehen zatia oso arina izango da: prestaketa, sarrera, cachea zer den buruzko gogoeta batzuk. Dagoeneko esperientziadun garatzaile bat bazara edo cacheekin lan egin baduzu, alde teknikotik ziurrenik ez da ezer berririk izango artikulu honetan. Baina junior batentzat, hain berrikuspen txiki batek esan diezaioke zein norabidetan begiratu behar duen bidegurutze batean aurkitzen bada.
Sportmaster webgunearen bertsio berria ekoizten hasi zenean, datuak ez ziren oso erosoak izan ziren moduan jaso ziren. Oinarria webgunearen aurreko bertsiorako (Bitrix) prestatutako taulak ziren, ETLra eraman behar izan zutenak, forma berri batera ekarri eta dozena bat sistema gehiagotako hainbat gauza txikirekin aberastu. Irudi edo produktuaren deskribapen berri bat webgunean agertzeko, hurrengo egunera arte itxaron behar izan duzu - eguneratzeak gauez bakarrik, egunean behin.
Hasieran, produkzioan sartu zeneko lehen asteetatik hainbeste kezka zeuden, edukien kudeatzaileentzako horrelako eragozpenak huskeria bat zirela. Baina, dena konpondu bezain laster, proiektuaren garapenak jarraitu zuen - hilabete batzuk geroago, 2015aren hasieran, administrazio panela aktiboki garatzen hasi ginen. 2015ean eta 2016an, dena ondo doa, aldizka kaleratzen dugu, administrazio-panelak gero eta datu gehiago prestatzen ditu, eta laster gure taldeari gauzarik garrantzitsuena eta konplexuena - produktua emateko prestatzen ari gara. zirkuitua (produktu guztien datuen prestaketa eta mantentze osoa). Baina 2017ko udan, salgaien zirkuitua abian jarri baino lehen, proiektua oso egoera zailean aurkituko du, katxeatzeko arazoak direla eta. Bi zatiko argitalpen honen bigarren zatian pasarte honi buruz hitz egin nahi dut.
Baina argitalpen honetan urrunetik hasiko naiz, pentsamendu batzuk aurkeztuko ditut: cacheari buruzko ideiak, proiektu handi baten aurretik korritzeko urrats ona izango litzateke.
Cache-lan bat gertatzen denean
Cachearen ataza ez da bakarrik agertzen. Garatzaileak gara, software produktu bat idazten dugu eta eskaria izatea nahi dugu. Produktua eskaria eta arrakastatsua bada, erabiltzaileak etorriko dira. Eta gero eta gehiago datoz. Eta gero erabiltzaile asko daude eta gero produktua oso kargatu egiten da.
Lehen faseetan, ez dugu optimizazioan eta kodearen errendimenduan pentsatzen. Gauza nagusia funtzionaltasuna da, pilotu bat azkar zabaltzea eta hipotesiak probatzea. Eta karga handitzen bada, burdina ponpatzen dugu. Bi edo hiru aldiz handitzen dugu, bost aldiz, agian 10 aldiz. Nonbait hemen - finantzak ez dute gehiago baimenduko. Zenbat aldiz igoko da erabiltzaile kopurua? Ez da 2-5-10 bezalakoa izango, baina arrakasta izanez gero, 100-1000-100 mila aldiz izango da. Hau da, lehenago edo beranduago, optimizazioa egin beharko duzu.
Demagun kodearen zatiren batek (dei diezaiogun zati honi funtzioa) denbora luzea behar duela eta exekuzio denbora murriztu nahi dugula. Funtzio bat datu-base baterako sarbidea izan daiteke edo logika konplexu baten exekuzioa izan daiteke - gauza nagusia da denbora luzea behar dela osatzeko. Zenbat murriztu dezakezu exekuzio denbora? Mugan, zerora murriztu dezakezu, ez gehiago. Nola murriztu dezakezu exekuzio denbora zerora? Erantzuna: ezabatu exekuzioa guztiz. Horren ordez, itzuli emaitza berehala. Nola jakin dezakezu emaitza? Erantzuna: kalkulatu edo begiratu nonbait. Denbora asko behar da kalkulatzeko. Eta espiatzea da, adibidez, parametro berdinekin deitzean funtzioak azken aldiz eman zuen emaitza gogoratzea.
Hau da, funtzioaren ezarpena ez da garrantzitsua guretzat. Nahikoa da emaitza zein parametrotan dagoen jakitea. Ondoren, parametroen balioak biltegiratze batzuetan gako gisa erabil daitekeen objektu baten moduan irudikatzen badira, orduan kalkuluaren emaitza gorde eta irakur daiteke hurrengoan sartzen den aldian. Emaitzaren idazketa eta irakurketa hau funtzioa exekutatzen baino azkarragoa bada, irabazia dugu abiadurari dagokionez. Mozkinaren zenbatekoa 100, 1000 eta 100 mila aldiz irits daiteke (10^5 salbuespena da, baina nahiko atzeratutako oinarri baten kasuan, nahiko posible da).
Cache-sistema baten oinarrizko baldintzak
Cache-sistema baterako eskakizun bihur daitekeen lehen gauza irakurketa-abiadura azkarra eta, neurri apur bat txikiagoan, idazketa-abiadura da. Hau egia da, baina sistema ekoizpenera zabaldu arte.
Joka dezagun kasu honetan.
Demagun uneko karga hardwarearekin hornitu dugula eta pixkanaka cachea sartzen ari garela. Erabiltzaile kopurua apur bat hazten da, karga hazi egiten da - cache apur bat gehitzen dugu, izorratzen dugu han eta hemen. Horrek denbora pixka bat jarraitzen du, eta orain funtzio astunak ia ez dira deitzen jada - karga nagusi osoa cachean erortzen da. Denbora horretan erabiltzaile kopurua N aldiz handitu da.
Eta hardwarearen hasierako hornidura 2-5 aldiz izan zitekeen, orduan cachearen laguntzaz errendimendua hobetu genezake 10eko faktore batean edo, kasu on batean, 100eko faktore batean, leku batzuetan agian faktore batean. 1000. Hau da, hardware berean - 100 aldiz eskaera gehiago prozesatzen ditugu. Bikaina, jengibrea merezi duzu!
Baina orain, momentu eder batean, kasualitatez, sistema huts egin eta cachea erori egin zen. Ez dago ezer berezirik - azken finean, cachea "irakurtzeko eta idazteko abiadura handia, gainerakoak ez du axola" baldintzaren arabera aukeratu zen.
Hasierako kargari dagokionez, gure burdina erreserba 2-5 aldiz izan zen, eta denbora horretan karga 10-100 aldiz handitu zen. Cachea erabiliz, funtzio astunetarako deiak ezabatu genituen eta, beraz, dena funtzionatu zuen. Eta orain, cacherik gabe, zenbat aldiz motelduko da gure sistema? Zer gertatuko zaigu? Sistema erori egingo da.
Gure cachea huts egin ez bada ere, pixka bat garbitu bada ere, berotu egin beharko da, eta denbora pixka bat beharko du. Eta denbora horretan, zama nagusia funtzionalitatean izango da.
Ondorioa: oso kargatutako produkzio-proiektuek cache-sistema bat behar dute irakurtzeko eta idazteko abiadura handiak izateko ez ezik, datuen segurtasuna eta hutsegiteekiko erresistentzia bermatzeko ere.
Aukeraren agonia
Admin panel bat duen proiektu batean, hautua honela geratu zen: lehenik Hazelcast instalatu genuen, zeren Dagoeneko ezagutzen genuen produktu hau gune nagusiaren esperientziatik. Baina hemen aukera hau ez da arrakastatsua izan - gure karga-profilaren arabera, Hazelcast ez da motela bakarrik, oso motela baizik. Eta garai hartan jada izena emana genuen kaleratze datarako.
Spoiler: nola garatu ziren hain gauza handi bat galdu genuen eta egoera larria eta tentsiotsua izan genuela –bigarren zatian kontatuko dizuet– eta nola bukatu genuen eta nola atera ginen. Baina orain - estres handia izan zela esango dut, eta "pentsatzeko - nolabait ezin dut pentsatu, botila astintzen ari gara". "Shaking the bottle" ere spoiler bat da, geroago gehiago.
Zer egin genuen:
- Googlek eta StackOverflow-ek iradokitzen dituzten sistema guztien zerrenda egiten dugu. 30 pasatxo
- Ekoizpenerako ohiko karga duten probak idazten ditugu. Horretarako, ekoizpen-ingurunean sistematik pasatzen diren datuak erregistratu ditugu - sarean ez, sistema barruan baizik eta datuen sniffer moduko bat. Zehazki datu hori erabili da probetan.
- Talde osoarekin, denek zerrendako hurrengo sistema hautatzen dute, konfiguratzen dute eta probak egiten dituzte. Ez du proba gainditzen, ez du kargarik eramaten - botatzen dugu eta ilaran hurrengora pasatzen gara.
- 17. sisteman argi geratu zen dena itxaropenik gabe zegoela. Utzi botila astintzeari, serio pentsatzeko garaia da.
Baina hau aukera bat da aurrez prestatutako probetan "abiadura gaindituko duen" sistema bat aukeratu behar duzunean. Zer gertatzen da oraindik horrelako probarik ez badago eta azkar aukeratu nahi baduzu?
Eredu dezagun aukera hau (zaila da imajinatzea erdiko+ garatzaile bat hutsean bizi dela, eta hautaketaren unean oraindik ez duela formalizatu zein produktu lehen probatzeko lehentasuna; beraz, arrazoiketa gehiago teorikoa/filosofia/) bat da. junior bati buruz).
Baldintzak erabakita, has gaitezen irtenbide bat aukeratzen. Zergatik berrasmatu gurpila: joango gara prest egindako caching sistema bat hartuko dugu.
Hasi berria bazara eta Googlen bilatzen baduzu, eman edo hartu eskaera, baina, oro har, jarraibideak honelakoak izango dira. Lehenik eta behin, Redis topatuko duzu, nonahi entzuten da. Orduan jakingo duzu EhCache sistemarik zaharrena eta frogatuena dela. Jarraian, Tarantool-i buruz idatziko dugu, irtenbidearen alderdi berezia duen etxeko garapen bati buruz. Eta Ignite ere, gaur egun ospea handitzen ari delako eta SberTech-en laguntzaz gozatzen duelako. Amaieran Hazelcast ere badago, enpresa munduan enpresa handien artean askotan agertzen delako.
Zerrenda ez da zehatza; dozenaka sistema daude. Eta gauza bakarra izorratuko dugu. Har ditzagun hautatutako 5 sistemak "edertasun lehiaketarako" eta egin ditzagun aukeraketa. Nor izango da irabazlea?
Birbanaketa
Idazten dutena webgune ofizialean irakurtzen dugu.
- Kode irekiko proiektua. Memorian datuak biltegiratzea, diskoan gordetzeko gaitasuna, partizio automatikoa, erabilgarritasun handia eta sareko etenetatik berreskuratzeko aukera eskaintzen du.
Badirudi dena ondo dagoela, hartu eta izorratu dezakezu - behar duzun guztia, egiten du. Baina ondo pasatzeko, ikus ditzagun beste hautagaiak.
EhCache
- “Javarako gehien erabiltzen den cachea” (webgune ofizialetik leloaren itzulpena). Baita kode irekia ere. Eta orduan ulertzen dugu Redis ez dela javarako, orokorra baizik, eta harekin elkarreragiteko wrapper bat behar duzula. Eta EhCache erosoagoa izango da. Zer gehiago agintzen du sistemak? Fidagarritasuna, frogatua, funtzionaltasun osoa. Tira, ohikoena ere bada. Eta terabyte-ko datuak gordetzen ditu.
Redis ahaztuta dago, prest nago EhCache aukeratzeko.
Baina abertzaletasun zentzuak Tarantoolek zer den ona ikustera bultzatzen nau.
Tarantool
- "Datuen integrazio-plataforma denbora errealean" izendapena betetzen du. Oso konplikatua dirudi, beraz, orria zehatz-mehatz irakurri eta adierazpen ozen bat aurkitzen dugu: "Datuen % 100 RAM-en gordetzen du". Horrek galderak sortu beharko lituzke; azken finean, memoria baino askoz datu gehiago egon daitezke. Azalpena da esan nahi duela Tarantool-ek ez duela serializazioa exekutatzen datuak diskoan memoriatik idazteko. Horren ordez, sistemaren behe-mailako ezaugarriak erabiltzen ditu, memoria I/O errendimendu oso ona duen fitxategi-sistema batera mapatzen denean. Oro har, zerbait zoragarria eta polita egin zuten.
Ikus ditzagun ezarpenak: Mail.ru autopista korporatiboa, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Tarantool-i buruz oraindik zalantzaren bat bazegoen, Mastercard-en ezarpen kasuak amaitzen nau. Tarantool hartzen dut.
Baina dena den…
Su
… ba al dago gehiago , "memoriako informatika-plataforma... memoriako abiadura datu petabyteetan" gisa fakturatzen da. Hemen ere abantaila asko daude: memorian banatutako cachea, gako-balioen biltegiratze eta cacherik azkarrena, eskalatze horizontala, erabilgarritasun handia, osotasun zorrotza. Oro har, azkarrena Ignite dela ematen du.
Inplementazioak: Sberbank, American Airlines, Yahoo! Japonia. Eta orduan jakin dut Ignite ez dela Sberbank-en soilik inplementatu, baizik eta SberTech taldeak bere jendea Ignite taldera bidaltzen duela produktua fintzeko. Hau guztiz liluragarria da eta Ignite hartzeko prest nago.
Ez dago guztiz argi zergatik, bosgarren puntuari begira nago.
Hazelcast
gunera joaten naiz , irakurtzen. Eta bihurtzen da banatutako cachea egiteko irtenbiderik azkarrena Hazelcast dela. Beste soluzio guztiak baino magnitude ordenak azkarragoak dira eta, oro har, liderra da memoria barneko datu-sarearen arloan. Aurrekari honen aurrean, beste zerbait hartzea ez da zure burua errespetatzea. Datu-biltegiratze erredundantea ere erabiltzen du klusterraren etengabeko funtzionamendurako, datuak galdu gabe.
Hori da, prest nago Hazelcast hartzeko.
konparazio
Baina begiratuz gero, bost hautagaiak deskribatzen dira, horietako bakoitza onena den moduan. Nola aukeratu? Ikus dezakegu zein den ezagunena, konparazioak bilatu eta buruko mina desagertuko da.
Horrelako bat aurkitzen dugu , aukeratu gure 5 sistemak.
Hemen daude ordenatuta: Redis goian dago, Hazelcast bigarren postuan, Tarantool eta Ignite ospea lortzen ari dira, EhCache berdina izan da eta jarraitzen du.
Baina ikus dezagun : webguneetarako estekak, sistemaren interes orokorra, lan eskaintzak - bikaina! Hau da, nire sistemak huts egiten duenean, esango dut: “Ez, fidagarria da! Lan eskaintza asko daude..." Halako konparaketa sinple batek ez du balioko.
Sistema hauek guztiak ez dira cachean gordetzeko sistemak soilik. Gainera, funtzionalitate asko dituzte, besteak beste, datuak bezeroari prozesatzeko ponpatzen ez direnean, baina alderantziz: datuetan exekutatu behar den kodea zerbitzarira mugitzen da, bertan exekutatzen da eta emaitza itzultzen da. Eta ez dira hainbestetan hartzen cachean gordetzeko sistema bereizi gisa.
Ados, ez dezagun amore eman, aurki dezagun sistemen konparazio zuzena. Har ditzagun goiko bi aukerak: Redis eta Hazelcast. Abiadura interesatzen zaigu, eta parametro horren arabera alderatuko ditugu.
Hz vs Redis
Hau aurkitzen dugu :
Urdina Redis da, gorria Hazelcast. Hazelcast-ek nonahi irabazten du, eta horretarako arrazoi bat dago: hari anitzekoa da, oso optimizatua, hari bakoitzak bere partizioarekin funtzionatzen du, beraz, ez dago blokeorik. Eta Redis hari bakarrekoa da; ez die onurarik ateratzen nukleo anitzeko CPU modernoei. Hazelcast-ek I/O asinkronoak ditu, Redis-Jedis-ek blokeo-socketak ditu. Azken finean, Hazelcast-ek protokolo bitar bat erabiltzen du, eta Redis testuan oinarritzen da, hau da, eraginkorra ez da.
Badaezpada, jo dezagun beste konparazio iturri batera. Zer erakutsiko digu?
Redis vs Hz
Beste bat :
Hemen, aitzitik, gorria Redis da. Hau da, Redisek Hazelcast gainditzen du errendimenduari dagokionez. Hazelcastek irabazi zuen lehen konparazioa, Redisek bigarrena. oso zehatz azaldu zuen Hazelcastek aurreko konparazioa zergatik irabazi zuen.
Ematen du lehenengoaren emaitza benetan trukatua izan zela: Redis oinarrizko kutxan hartu zuten, eta Hazelcast proba kasu baterako egokitu zuten. Orduan gertatzen da: lehenik eta behin, ezin gara inorekin fidatu, eta, bigarrenik, sistema bat aukeratzen dugunean, behar bezala konfiguratu behar dugu oraindik. Ezarpen hauek dozenaka, ia ehunka parametro barne hartzen dituzte.
Botila astinduz
Eta orain egin dugun prozesu osoa honako metafora honekin azal dezaket: “Botila astinduz”. Hau da, orain ez duzu programatu beharrik, orain nagusia stackoverflow irakurri ahal izatea da. Eta nire taldean pertsona bat daukat, profesional bat, momentu kritikoetan horrela lan egiten duena.
Zertan ari da? Hautsitako gauza bat ikusten du, pila-arrasto bat ikusten du, bertatik hitz batzuk hartzen ditu (programan bere espezializazioa zein den), Googlen bilatzen du, erantzunen artean stackoverflow aurkitzen du. Irakurri gabe, pentsatu gabe, galderaren erantzunen artean, “egin hau eta beste” esaldiaren antzekoena den zerbait aukeratzen du (halako erantzuna aukeratzea bere talentua da, ez baita beti gustuko gehien jaso duen erantzuna), aplikatzen du, itxura: zerbait aldatu bada, bikaina. Aldatu ez bada, itzuli atzera. Eta errepikatu abiarazte-check-bilaketa. Eta modu intuitibo honetan, denbora pixka bat igaro ondoren kodea funtzionatzen duela ziurtatzen du. Ez daki zergatik, ez daki zer egin zuen, ezin du azaldu. Baina! Infekzio honek funtzionatzen du. Eta "sua itzali da". Orain asma dezagun zer egin dugun. Programak funtzionatzen duenean, tamaina-ordena errazagoa da. Eta denbora asko aurrezten du.
Metodo hau oso ondo azaltzen da adibide honekin.
Garai batean oso ezaguna zen belaontzi bat botila batean biltzea. Aldi berean, belaontzia handia eta hauskorra da, eta botilaren lepoa oso estua da, ezinezkoa da barrura bultzatzea. Nola muntatu?
Badago halako metodo bat, oso azkarra eta oso eraginkorra.
Ontzia gauza txiki mordo batez osatuta dago: makilak, sokak, belak, kola. Hau guztia botila batean sartu dugu.
Bi eskuekin botila hartu eta dardarka hasten gara. Astindu eta astindu egiten dugu. Eta normalean erabateko zabor bihurtzen da, noski. Baina batzuetan. Batzuetan itsasontzi bat izaten da! Zehatzago esanda, itsasontzi baten antzeko zerbait.
Norbaiti zerbait erakusten diogu: "Seryoga, ikusten al duzu!?" Eta hain zuzen ere, urrutitik itsasontzia dirudi. Baina hori ezin da jarraitu.
Bada beste modu bat. Mutil aurreratuagoek erabiltzen dituzte, hala nola hackerrek.
Tipo honi zeregin bat eman nion, dena egin zuen eta alde egin zuen. Eta ikusten duzu, eginda dagoela dirudi. Eta pixka bat igaro ondoren, kodea amaitu behar denean, hau beragatik hasten da... Ongi dago jadanik urrun ihes egitea lortu duela. Hauek dira, botila baten adibidea erabiliz, hau egingo duten mutilak: ikusten duzu, hondoa non dagoen, kristala okertzen da. Eta ez dago guztiz argi gardena den ala ez. Orduan, "hacker-ek" hondo hori moztu, bertan itsasontzi bat sartu, gero berriro behea itsatsi, eta horrela izan behar lukeen bezala da.
Arazoa ezartzearen ikuspuntutik, dena zuzena dela dirudi. Baina ontziak adibide gisa erabiliz: zergatik egin itsasontzi hau, nork behar du hala ere? Ez du funtzionalitaterik eskaintzen. Normalean, horrelako ontziak opariak izaten dira maila oso altuko pertsonei, hauen gaineko apal batean jartzen dituztenak, nolabaiteko ikur gisa, seinale gisa. Eta halako pertsona bat, enpresa handi bateko burua edo goi-kargudun bat baldin bada, nola egongo da bandera hori lepoa moztuta dagoen halako hack bat? Hobe litzateke inoiz horren berri ez balu. Orduan, nola lortzen dute pertsona garrantzitsu bati eman dakizkiokeen ontzi hauek egiten?
Benetan ezer egin ezin duzun leku gako bakarra gorputza da. Eta ontziaren kroskoa lepoan sartzen da. Itsasontzia, berriz, botilatik kanpo muntatzen da. Baina ez da itsasontzi bat muntatzea bakarrik, benetako bitxi-artisautza bat da. Osagaiei palanka bereziak gehitzen zaizkie, gero altxatzeko aukera ematen dutenak. Esaterako, belak tolesten dira, kontu handiz barrura sartu, eta gero, pintzen laguntzaz, oso zehatz tiratu eta altxatzen dira, zehaztasunez. Emaitza kontzientzia garbi eta harrotasunez oparitu daitekeen artelana da.
Eta proiektuak arrakasta izan dezan nahi badugu, gutxienez bitxigile bat egon behar du taldean. Produktuaren kalitateaz arduratzen den eta alderdi guztiak kontuan hartzen dituena, ezer uko egin gabe, estres uneetan ere, egoerak premiazkotasuna garrantzitsuaren kontura egitea eskatzen duenean. Iraunkorrak diren proiektu arrakastatsu guztiak, denboraren proba jasan dutenak, printzipio horren arabera eraikitzen dira. Haiek badute zerbait oso zehatza eta berezia, dauden aukera guztiak aprobetxatzen dituena. Ontzia botilan duen adibidean, ontziaren kroskoa lepotik igarotzea antzezten da.
Gure caching zerbitzaria aukeratzeko zereginera itzuliz, nola aplikatu liteke metodo hau? Dauden sistema guztien artean aukeratzeko aukera hau eskaintzen dut - ez astindu botila, ez aukeratu, baina begiratu zer duten printzipioz, zer bilatu sistema bat aukeratzerakoan.
Non bilatu botila-lepoa
Saia gaitezen botila ez astintzen, banan-banan dagoen guztia ez pasatzen, baina ea zer arazo sortuko diren bat-batean, gure zereginerako, guk geuk diseinatzen badugu halako sistema bat. Noski, ez dugu bizikleta muntatuko, baina diagrama hau erabiliko dugu produktuen deskribapenetan zer punturi erreparatu behar diogun asmatzen laguntzeko. Zirriborratu dezagun halako diagrama bat.
Sistema banatuta badago, orduan hainbat zerbitzari izango ditugu (6). Demagun lau daudela (irudian jartzea komeni da, baina, noski, nahi adina egon daitezke). Zerbitzariak nodo desberdinetan badaude, esan nahi du guztiek exekutatzen dutela koderen bat, nodo horiek kluster bat osatzeaz arduratzen dena eta, eten bat gertatuz gero, elkar konektatu eta ezagutzen dutela.
Kode-logika ere behar dugu (2), hau da, benetan cachean aritzea. Bezeroek kode honekin elkarreragiten dute API batzuen bidez. Bezero-kodea (1) JVM berean egon daiteke edo sarearen bidez sar daiteke. Barruan ezartzen den logika cachean zein objektu utzi eta zein bota erabakitzen du. Memoria (3) erabiltzen dugu cachea gordetzeko, baina behar izanez gero, datu batzuk diskoan gorde ditzakegu (4).
Ikus dezagun zein zatitan gertatuko den karga. Egia esan, gezi eta nodo bakoitza kargatuko da. Lehenik eta behin, bezeroaren kodearen eta apiaren artean, sareko komunikazioa bada, hondoratzea nahiko nabaria izan daiteke. Bigarrenik, api beraren esparruan - logika konplexuarekin gainditzen badugu, CPUarekin arazoak izan ditzakegu. Eta ondo legoke logikak memorian denbora galduko ez balu. Eta fitxategi-sistemarekin elkarrekintza geratzen da - ohiko bertsioan hau serializatzea / leheneratzea eta idaztea / irakurtzea da.
Hurrengoa klusterrekiko interakzioa da. Seguruenik, sistema berean egongo da, baina bereizita egon daiteke. Hemen ere kontuan hartu behar dituzu datuen transferentzia, datuen serializazio abiadura eta klusterraren arteko elkarrekintzak.
Orain, alde batetik, cache sisteman “zer engranaje biratuko duten” imajina dezakegu gure kodearen eskaerak prozesatzen direnean, eta, bestetik, gure kodeak sistema honetara zer eta zenbat eskaera sortuko dituen kalkula dezakegu. Hau nahikoa da aukera gehiago edo gutxiago bat egiteko - gure erabilera kasurako sistema bat aukeratzeko.
Hazelcast
Ikus dezagun nola aplikatu deskonposizio hau gure zerrendari. Adibidez, Hazelcast.
Hazelcast-en datuak jartzeko/hartzeko, bezero-kodeak (1) APIan sartzen du. Hz-k zerbitzaria kapsulatutako moduan exekutatzeko aukera ematen du, eta kasu honetan, api-ra sartzea JVM barneko metodo-dei bat da, doakotzat jo daitekeena.
(2)-ko logikak funtziona dezan, Hz serializatutako gakoaren byte-matrizearen hashean oinarritzen da, hau da, gakoa serializatuko da edozein kasutan. Hau saihestezina da Hz-en gainkostua.
Desalojo estrategiak ondo ezartzen dira, baina kasu berezietarako zurea gehi dezakezu. Ez duzu zati honi buruz kezkatu behar.
Biltegiratzea (4) konekta daiteke. Bikaina. Interakzioa (5) txertaturako berehalakotzat har daiteke. Klusterreko nodoen arteko datu-trukea (6) - bai, badago. Hau akatsen tolerantzian inbertsioa da abiaduraren kaltetan. Hz funtzioak Near-cache-k prezioa murrizteko aukera ematen du - klusterreko beste nodoetatik jasotako datuak cachean gordeko dira.
Zer egin daiteke halako baldintzetan abiadura handitzeko?
Adibidez, (2) gakoaren serializazioa saihesteko - erantsi beste cache bat Hazelcast-en gainean, datu beroenak lortzeko. Sportmaster-ek Kafeina aukeratu zuen horretarako.
(6) mailan bihurritzeko, Hz-ek bi biltegiratze mota eskaintzen ditu: IMap eta ReplicatedMap.
Aipatzekoa da Hazelcast nola sartu zen Sportmaster teknologia pilara.
2012an, etorkizuneko gunearen lehenengo pilotuan lanean ari ginela, Hazelcast izan zen bilatzaileak itzuli zuen lehen esteka izan zena. Ezaguna "lehen aldiz" hasi zen - liluratu gintuen bi ordu geroago, Hz sisteman izorratu genuenean, funtzionatu zuela. Eta ondo funtzionatu zuen. Egunaren amaieran proba ugari egin genituen eta pozik geunden. Eta indar erreserba hori nahikoa izan zen Hz-ek denboran zehar botatako ezustekoak gainditzeko. Orain Sportmaster taldeak ez du Hazelcast uzteko arrazoirik.
Baina "bilatzaileko lehen esteka" eta "HelloWorld azkar muntatu zen" bezalako argudioak, jakina, aukeraketa egin zen unearen salbuespena eta ezaugarri bat dira. Aukeratutako sistemaren benetako probak produkziora ateratzean hasten dira, eta fase honetan arreta jarri behar duzu edozein sistema aukeratzerakoan, cachea barne. Egia esan, gure kasuan Hazelcast ustekabean aukeratu genuela esan dezakegu, baina gero ondo aukeratu genuela.
Ekoizpenerako, askoz ere garrantzitsuagoa: monitorizazioa, banakako nodoen hutsegiteen kudeaketa, datuen erreplikazioa, eskalatzearen kostua. Hau da, merezi du arreta jartzea sistemaren mantentze-lanetan sortuko diren zereginei - karga aurreikusitakoa baino hamar aldiz handiagoa denean, nahi gabe zerbait leku okerrean kargatzen dugunean, bertsio berri bat zabaldu behar dugunean. kodearen, datuak ordezkatu eta bezeroei oharkabean egin.
Baldintza guzti horietarako, Hazelcast-ek, zalantzarik gabe, faktura egokitzen du.
Jarraituko du
Baina Hazelcast ez da panazea. 2017an, Hazelcast aukeratu genuen administratzailearen cacherako, iraganeko esperientziaren inpresio onetan oinarrituta. Honek protagonismo handia izan zuen oso txantxa krudel batean, eta horregatik egoera zailean aurkitzen ginen eta 60 egunez "heroikoki" atera ginen. Baina horretaz gehiago hurrengo zatian.
Bitartean... Kode Berri zoriontsua!
Iturria: www.habr.com