Hallo! My naam is Alexey Pyankov, ek is 'n ontwikkelaar by die Sportmaster-maatskappy. Daarin Ek het vertel hoe werk op die Sportmaster-webwerf in 2012 begin het, watter inisiatiewe ons daarin geslaag het om te “deurdruk” en omgekeerd, watter hark ons ingesamel het.
Vandag wil ek gedagtes deel wat op 'n ander onderwerp volg - die keuse van 'n kasstelsel vir die java-agterkant in die werfadministrasiepaneel. Hierdie intrige het vir my 'n besondere betekenis - hoewel die storie net vir 2 maande afgespeel het, het ons gedurende hierdie 60 dae 12-16 uur gewerk en sonder 'n enkele dag af. Ek het nooit gedink of voorgestel dat dit moontlik is om so hard te werk nie.
Daarom verdeel ek die teks in 2 dele om dit nie heeltemal te laai nie. Inteendeel, die eerste deel sal baie lig wees - voorbereiding, inleiding, 'n paar oorwegings oor wat caching is. As jy reeds 'n ervare ontwikkelaar is of met kas gewerk het, sal daar van die tegniese kant heel waarskynlik niks nuuts in hierdie artikel wees nie. Maar vir 'n junior kan so 'n klein resensie vir hom sê in watter rigting hy moet kyk as hy hom by so 'n kruispad bevind.
Toe die nuwe weergawe van die Sportmaster-webwerf in produksie gestel is, is die data ontvang op 'n manier wat, om dit sagkens te stel, nie baie gerieflik was nie. Die basis was tabelle wat voorberei is vir die vorige weergawe van die webwerf (Bitrix), wat in ETL ingetrek moes word, na 'n nuwe vorm gebring en verryk is met verskeie klein dingetjies uit 'n dosyn meer stelsels. Om 'n nuwe prentjie of produkbeskrywing op die webwerf te laat verskyn, moes jy wag tot die volgende dag - opdaterings net snags, een keer per dag.
Aanvanklik was daar soveel bekommernisse vanaf die eerste weke van produksie dat sulke ongerief vir inhoudbestuurders 'n kleinigheid was. Maar sodra alles vasgeval het, het die ontwikkeling van die projek voortgegaan - 'n paar maande later, aan die begin van 2015, het ons die administrasiepaneel aktief begin ontwikkel. In 2015 en 2016 gaan alles goed, ons stel gereeld vry, die adminpaneel dek meer en meer van die datavoorbereiding, en ons berei voor dat ons span binnekort met die belangrikste en mees komplekse ding toevertrou sal word - die produk kring (volledige voorbereiding en instandhouding van data oor alle produkte). Maar in die somer van 2017, net voor die bekendstelling van die kommoditeitkring, sal die projek hom in 'n baie moeilike situasie bevind - juis weens probleme met kas. Ek wil in die tweede deel van hierdie tweedelige publikasie oor hierdie episode praat.
Maar in hierdie pos sal ek van ver af begin, ek sal 'n paar gedagtes aanbied - idees oor kas, wat 'n goeie stap sal wees om deur te blaai voor 'n groot projek.
Wanneer 'n kastaak plaasvind
Die kas-taak verskyn nie net nie. Ons is ontwikkelaars, skryf 'n sagtewareproduk en wil hê dit moet in aanvraag wees. As die produk in aanvraag en suksesvol is, sal gebruikers kom. En meer en meer kom. En dan is daar baie gebruikers en dan word die produk hoog gelaai.
In die eerste stadiums dink ons nie aan optimalisering en kodeprestasie nie. Die belangrikste ding is funksionaliteit, die vinnige uitrol van 'n vlieënier en die toets van hipoteses. En as die las toeneem, pomp ons die yster op. Ons verhoog dit twee of drie keer, vyf keer, miskien 10 keer. Iewers hier - finansies sal dit nie meer toelaat nie. Hoeveel keer sal die aantal gebruikers toeneem? Dit sal nie soos 2-5-10 wees nie, maar as dit suksesvol is, sal dit van 100-1000 tot 100 duisend keer wees. Dit wil sê, vroeër of later sal jy optimalisering moet doen.
Kom ons sê dat 'n deel van die kode (kom ons noem hierdie deel 'n funksie) 'n onwelvoeglike lang tyd neem, en ons wil die uitvoeringstyd verminder. 'n Funksie kan toegang tot 'n databasis wees, of dit kan die uitvoering van 'n komplekse logika wees - die belangrikste ding is dat dit 'n lang tyd neem om te voltooi. Hoeveel kan jy die uitvoeringstyd verminder? In die limiet kan jy dit tot nul verminder, nie verder nie. Hoe kan jy die uitvoeringstyd tot nul verminder? Antwoord: skakel uitvoering heeltemal uit. Gee eerder die resultaat dadelik terug. Hoe kan jy die resultaat uitvind? Antwoord: óf bereken dit óf kyk iewers. Dit neem lank om te bereken. En om te spioeneer, is byvoorbeeld om die resultaat te onthou wat die funksie die laaste keer opgelewer het toe dit met dieselfde parameters geroep is.
Dit wil sê, die implementering van die funksie is nie vir ons belangrik nie. Dit is genoeg om net te weet van watter parameters die resultaat afhang. Dan, as die parameterwaardes voorgestel word in die vorm van 'n voorwerp wat as 'n sleutel in een of ander berging gebruik kan word, kan die resultaat van die berekening gestoor word en uitgelees word die volgende keer dat dit toegang verkry word. As hierdie skryf en lees van die resultaat vinniger is as om die funksie uit te voer, het ons 'n wins in terme van spoed. Die hoeveelheid wins kan 100, 1000 en 100 duisend keer bereik (10^5 is eerder 'n uitsondering, maar in die geval van 'n taamlik sloerende basis, is dit heel moontlik).
Basiese vereistes vir 'n kasstelsel
Die eerste ding wat 'n vereiste vir 'n kasstelsel kan word, is vinnige leesspoed en, in 'n effens mindere mate, skryfspoed. Dit is waar, maar net totdat ons die stelsel na produksie uitrol.
Kom ons speel hierdie saak.
Kom ons sê ons het die huidige vrag van hardeware voorsien en stel nou kasgeheue geleidelik bekend. Die aantal gebruikers groei 'n bietjie, die vrag groei - ons voeg 'n bietjie caches by, skroef dit hier en daar in. Dit duur 'n geruime tyd voort, en nou word swaar funksies feitlik nie meer genoem nie - die hele hooflading val op die kas. Die aantal gebruikers gedurende hierdie tyd het N keer toegeneem.
En as die aanvanklike toevoer van hardeware 2-5 keer kan wees, kan ons met behulp van die kas werkverrigting met 'n faktor van 10 verbeter of, in 'n goeie geval, met 'n faktor van 100, op sommige plekke miskien met 'n faktor van 1000. Dit wil sê op dieselfde hardeware – ons verwerk 100 keer meer versoeke. Groot, jy verdien die gemmerkoek!
Maar nou, op 'n mooi oomblik, toevallig, het die stelsel neergestort en die kas het ineengestort. Niks besonders nie - die kas is immers gekies op grond van die vereiste "hoë lees- en skryfspoed, die res maak nie saak nie."
Relatief tot die beginlading was ons ysterreserwe 2-5 keer, en die vrag gedurende hierdie tyd het 10-100 keer toegeneem. Deur die kas te gebruik, het ons oproepe vir swaar funksies uitgeskakel en daarom het alles gewerk. En nou, sonder 'n kas, hoeveel keer sal ons stelsel stadiger word? Wat gaan met ons gebeur? Die stelsel sal val.
Selfs as ons kas nie neergestort het nie, maar net vir 'n rukkie skoongemaak is, sal dit opgewarm moet word, en dit sal 'n rukkie neem. En gedurende hierdie tyd sal die hooflas op funksionaliteit val.
Gevolgtrekking: hoogs gelaaide produksieprojekte vereis 'n kasstelsel om nie net hoë lees- en skryfspoed te hê nie, maar ook om dataveiligheid en weerstand teen mislukkings te verseker.
Meel van keuse
In 'n projek met 'n administrasiepaneel het die keuse so verloop: ons het eers Hazelcast geïnstalleer, want Ons was reeds vertroud met hierdie produk uit die ervaring van die hoof webwerf. Maar hier was hierdie keuse onsuksesvol – onder ons lasprofiel is Hazelcast nie net stadig nie, maar verskriklik stadig. En op daardie tydstip het ons reeds ingeskryf vir die vrystellingsdatum.
Bederf: hoe presies die omstandighede ontwikkel het dat ons so 'n groot ding gemis het en met 'n akute en gespanne situasie beland het - ek sal jou in die tweede deel vertel - en hoe ons beland het en hoe ons uitgekom het. Maar nou - ek sal net sê dat dit baie stres was, en "om te dink - op een of ander manier kan ek nie dink nie, ons skud die bottel." “Shaking the bottle” is ook ’n bederf, later meer daaroor.
Wat ons gedoen het:
- Ons maak 'n lys van al die stelsels wat Google en StackOverflow voorstel. Bietjie meer as 30
- Ons skryf toetse met 'n las tipies vir produksie. Om dit te doen, het ons data aangeteken wat in 'n produksie-omgewing deur die stelsel gaan - 'n soort snuffel vir data nie op die netwerk nie, maar binne die stelsel. Presies hierdie data is in die toetse gebruik.
- Met die hele span kies almal die volgende stelsel uit die lys, stel dit op en voer toetse uit. Dit slaag nie die toets nie, dit dra nie die vrag nie - ons gooi dit weg en beweeg aan na die volgende een in die ry.
- Op die 17de stelsel het dit duidelik geword dat alles hopeloos was. Hou op om die bottel te skud, dis tyd om ernstig te dink.
Maar dit is 'n opsie wanneer jy 'n stelsel moet kies wat "deur die spoed" sal kom in vooraf voorbereide toetse. Wat as daar nog nie sulke toetse is nie en jy wil vinnig kies?
Kom ons modelleer hierdie opsie (dit is moeilik om te dink dat 'n middel+ ontwikkelaar in 'n vakuum leef, en ten tyde van seleksie nog nie sy voorkeur geformaliseer het oor watter produk om eerste te probeer nie - daarom is verdere redenasie meer 'n teoretikus/filosofie/ omtrent 'n junior).
Nadat ons op die vereistes besluit het, sal ons begin om 'n oplossing uit die boks te kies. Hoekom die wiel weer uitvind: ons gaan 'n klaargemaakte kasstelsel neem.
As jy net begin en dit google, gee of neem dan die bestelling, maar oor die algemeen sal die riglyne so wees. Eerstens sal jy Redis raakloop, dit word oral gehoor. Dan sal jy uitvind dat EhCache die oudste en mees bewese stelsel is. Volgende sal ons skryf oor Tarantool, 'n huishoudelike ontwikkeling wat 'n unieke aspek van die oplossing het. En ook Ignite, want dit is nou aan die toeneem in gewildheid en geniet die ondersteuning van SberTech. Aan die einde is daar ook Hazelcast, want in die ondernemingswêreld verskyn dit dikwels onder groot maatskappye.
Die lys is nie volledig nie; daar is dosyne stelsels. En ons sal net een ding moer. Kom ons neem die geselekteerde 5 stelsels vir die "skoonheidskompetisie" en maak 'n keuse. Wie sal die wenner wees?
Redis
Ons lees wat hulle op die amptelike webwerf skryf.
- oopbronprojek. Bied in-geheue databerging, die vermoë om op skyf te stoor, outo-partisionering, hoë beskikbaarheid en herstel van netwerkonderbrekings.
Dit blyk dat alles in orde is, jy kan dit vat en vasdraai - alles wat jy nodig het, doen dit. Maar net vir die pret, kom ons kyk na die ander kandidate.
EhCache
- "die mees gebruikte kas vir Java" (vertaling van die slagspreuk vanaf die amptelike webwerf). Ook opensource. En dan verstaan ons dat Redis nie vir java is nie, maar algemeen, en om daarmee te kommunikeer, het jy 'n omhulsel nodig. En EhCache sal geriefliker wees. Wat anders beloof die stelsel? Betroubaarheid, bewese, volle funksionaliteit. Wel, dit is ook die algemeenste. En kas teragrepe data.
Redis is vergete, ek is gereed om EhCache te kies.
Maar 'n gevoel van patriotisme dryf my om te sien wat goed is aan Tarantool.
Tarantool
- voldoen aan die benaming "Intydse data-integrasieplatform". Dit klink baie ingewikkeld, so ons lees die bladsy in detail en vind 'n harde stelling: "Kas 100% van die data in RAM." Dit behoort vrae te laat ontstaan – daar kan immers baie meer data as geheue wees. Die verduideliking is dat dit beteken dat Tarantool nie serialisering uitvoer om data vanaf die geheue na skyf te skryf nie. In plaas daarvan gebruik dit laevlakkenmerke van die stelsel, wanneer geheue eenvoudig gekarteer word na 'n lêerstelsel met baie goeie I/O-werkverrigting. Oor die algemeen het hulle iets wonderlik en cool gedoen.
Kom ons kyk na die implementerings: Mail.ru korporatiewe snelweg, Avito, Beeline, Megafon, Alfa-Bank, Gazprom ...
As daar nog twyfel oor Tarantool was, dan maak die implementeringsaak by Mastercard my klaar. Ek neem Tarantool.
Maar in elk geval…
Aansteek
… is daar nog iets , word gefaktureer as 'n "in-geheue rekenaarplatform ... in-geheue spoed op petagrepe van data." Daar is ook baie voordele hier: verspreide in-geheue-kas, die vinnigste sleutelwaarde-berging en -kas, horisontale skaal, hoë beskikbaarheid, streng integriteit. Oor die algemeen blyk dit dat die vinnigste Ignite is.
Implementerings: Sberbank, American Airlines, Yahoo! Japan. En dan vind ek uit dat Ignite nie net in Sberbank geïmplementeer word nie, maar die SberTech-span stuur sy mense na die Ignite-span self om die produk te verfyn. Dit is heeltemal boeiend en ek is gereed om Ignite te neem.
Dit is heeltemal onduidelik hoekom, ek kyk na die vyfde punt.
haselgiet
Ek gaan na die webwerf , lees. En dit blyk dat die vinnigste oplossing vir verspreide kas Hazelcast is. Dit is ordes van grootte vinniger as alle ander oplossings en in die algemeen is dit 'n leier op die gebied van in-geheue data rooster. Teen hierdie agtergrond, om iets anders te neem, is nie om jouself te respekteer nie. Dit gebruik ook oortollige databerging vir deurlopende werking van die groep sonder dataverlies.
Dit is dit, ek is gereed om Hazelcast te neem.
vergelyking
Maar as jy kyk, word al vyf kandidate so beskryf dat elkeen van hulle die beste is. Hoe om te kies? Ons kan sien watter een die gewildste is, kyk vir vergelykings, en die hoofpyn sal verdwyn.
Ons vind so een , kies ons 5 stelsels.
Hier is hulle gesorteer: Redis is bo, Hazelcast is in die tweede plek, Tarantool en Ignite wen gewildheid, EhCache was en bly dieselfde.
Maar kom ons kyk na : skakels na webwerwe, algemene belangstelling in die stelsel, werkaanbiedinge - wonderlik! Dit wil sê, wanneer my stelsel misluk, sal ek sê: “Nee, dit is betroubaar! Daar is baie werkaanbiedinge..." So 'n eenvoudige vergelyking sal nie deug nie.
Al hierdie stelsels is nie net kasstelsels nie. Hulle het ook baie funksionaliteit, insluitend wanneer data nie na die kliënt gepomp word vir verwerking nie, maar omgekeerd: die kode wat op die data uitgevoer moet word, skuif na die bediener, word daar uitgevoer en die resultaat word teruggestuur. En hulle word nie so dikwels as 'n aparte stelsel vir kas beskou nie.
Goed, laat ons nie opgee nie, kom ons vind 'n direkte vergelyking van die stelsels. Kom ons neem die top twee opsies - Redis en Hazelcast. Ons is geïnteresseerd in spoed, en ons sal dit vergelyk op grond van hierdie parameter.
Hz vs Redis
Ons vind dit :
Blou is Redis, rooi is Hazelcast. Hazelcast wen oral, en daar is 'n rede hiervoor: dit is multi-draad, hoogs geoptimaliseer, elke draad werk met sy eie partisie, so daar is geen blokkering nie. En Redis is enkeldraad; dit trek nie voordeel uit moderne multi-kern SVE's nie. Hazelcast het asinchroniese I/O, Redis-Jedis het blokkerende voetstukke. Hazelcast gebruik immers 'n binêre protokol, en Redis is teksgesentreerd, wat beteken dat dit ondoeltreffend is.
Net vir ingeval, kom ons gaan na 'n ander bron van vergelyking. Wat sal hy vir ons wys?
Redis vs Hz
Nog een :
Hier, inteendeel, rooi is Redis. Dit wil sê, Redis vaar beter as Hazelcast in terme van prestasie. Hazelcast het die eerste vergelyking gewen, Redis het die tweede gewen. het baie presies verduidelik hoekom Hazelcast die vorige vergelyking gewen het.
Dit blyk dat die resultaat van die eerste een eintlik gemanipuleer is: Redis is in die basiskas geneem, en Hazelcast is aangepas vir 'n toetsgeval. Dan blyk dit: eerstens kan ons niemand vertrou nie, en tweedens, wanneer ons uiteindelik 'n stelsel kies, moet ons dit steeds korrek konfigureer. Hierdie instellings sluit dosyne, byna honderde parameters in.
Skud die bottel
En ek kan die hele proses wat ons nou gedoen het verduidelik met die volgende metafoor: “Skud die bottel.” Dit wil sê, nou hoef jy nie te programmeer nie, nou is die belangrikste ding om stapeloorvloei te kan lees. En ek het 'n persoon in my span, 'n professionele persoon, wat presies so op kritieke oomblikke werk.
Wat doen hy? Hy sien 'n stukkende ding, sien 'n stapelspoor, neem 'n paar woorde daaruit (watter een is sy kundigheid in die program), soek op Google, vind stapeloorvloei tussen die antwoorde. Sonder om te lees, sonder om te dink, onder die antwoorde op die vraag, kies hy iets wat die meeste soortgelyk is aan die sin "doen dit en dat" (om so 'n antwoord te kies is sy talent, want dit is nie altyd die antwoord wat die meeste hou nie), geld , lyk: as iets verander het, dan wonderlik. As dit nie verander het nie, rol dit terug. En herhaal launch-check-search. En op hierdie intuïtiewe manier verseker hy dat die kode na 'n rukkie werk. Hy weet nie hoekom nie, hy weet nie wat hy gedoen het nie, hy kan nie verduidelik nie. Maar! Hierdie infeksie werk. En "die vuur is geblus." Kom ons kyk nou uit wat ons gedoen het. Wanneer die program werk, is dit 'n orde van grootte makliker. En dit spaar baie tyd.
Hierdie metode word baie goed verduidelik met hierdie voorbeeld.
Dit was eens baie gewild om 'n seilboot in 'n bottel te versamel. Terselfdertyd is die seilboot groot en broos, en die nek van die bottel is baie smal, dit is onmoontlik om dit binne te druk. Hoe om dit te monteer?
Daar is so 'n metode, baie vinnig en baie effektief.
Die skip bestaan uit 'n klomp klein goedjies: stokke, toue, seile, gom. Ons sit dit alles in 'n bottel.
Ons vat die bottel met albei hande en begin skud. Ons skud en skud haar. En gewoonlik blyk dit volledige rommel te wees, natuurlik. Maar soms. Soms blyk dit 'n skip te wees! Meer presies, iets soortgelyk aan 'n skip.
Ons wys hierdie iets vir iemand: "Seryoga, sien jy!?" En sowaar, van ver af lyk dit soos 'n skip. Maar dit kan nie toegelaat word om voort te gaan nie.
Daar is 'n ander manier. Hulle word gebruik deur meer gevorderde ouens, soos kuberkrakers.
Ek het hierdie ou 'n taak gegee, hy het alles gedoen en vertrek. En jy kyk - dit lyk of dit klaar is. En na 'n rukkie, wanneer die kode gefinaliseer moet word, begin dit as gevolg van hom ... Dit is goed dat hy reeds daarin geslaag het om ver weg te hardloop. Dit is die ouens wat, met die voorbeeld van 'n bottel, dit sal doen: jy sien, waar die bodem is, buig die glas. En dit is nie heeltemal duidelik of dit deursigtig is of nie. Dan sny die "hackers" hierdie bodem af, steek 'n skip daar in, plak dan die bodem weer vas, en dit is asof dit is hoe dit veronderstel is om te wees.
Vanuit die oogpunt van die opstel van die probleem, blyk alles korrek te wees. Maar deur skepe as voorbeeld te gebruik: hoekom enigsins hierdie skip maak, wie het dit in elk geval nodig? Dit bied geen funksionaliteit nie. Gewoonlik is sulke skepe geskenke aan baie hooggeplaastes, wat dit op 'n rak bo hulle plaas, as 'n soort simbool, as 'n teken. En as so iemand, die hoof van 'n groot besigheid of 'n hooggeplaaste amptenaar, hoe sal die vlag staan vir so 'n hack waarvan die nek afgesny is? Dit sou beter wees as hy nooit daarvan geweet het nie. So, hoe maak hulle uiteindelik hierdie skepe wat aan 'n belangrike persoon gegee kan word?
Die enigste sleutelplek waaraan jy regtig niks kan doen nie, is die liggaam. En die skip se romp pas reg in die nek. Terwyl die skip buite die bottel saamgestel word. Maar dit is nie net die samestelling van 'n skip nie, dit is 'n regte juweliersware-kuns. Spesiale hefbome word by die komponente gevoeg, wat dit dan toelaat om opgelig te word. Die seile word byvoorbeeld gevou, versigtig binne gebring, en dan, met behulp van pincet, word dit baie presies getrek en opgelig, met presisie. Die resultaat is 'n kunswerk wat met 'n skoon gewete en trots geskenk kan word.
En as ons wil hê die projek moet suksesvol wees, moet daar ten minste een juwelier in die span wees. Iemand wat omgee vir die kwaliteit van die produk en alle aspekte in ag neem, sonder om iets op te offer, selfs in oomblikke van stres, wanneer omstandighede vereis dat die dringende gedoen word ten koste van die belangrike. Alle suksesvolle projekte wat volhoubaar is, wat die toets van die tyd deurstaan het, is op hierdie beginsel gebou. Daar is iets baie presies en uniek aan hulle, iets wat alle beskikbare moontlikhede benut. In die voorbeeld met die skip in die bottel word die feit dat die romp van die skip deur die nek gaan, uitgespeel.
Om terug te keer na die taak om ons kasbediener te kies, hoe kan hierdie metode toegepas word? Ek bied hierdie opsie om te kies uit al die stelsels wat bestaan - moenie die bottel skud nie, moenie kies nie, maar kyk wat hulle in beginsel het, waarna om te kyk wanneer jy 'n stelsel kies.
Waar om te soek na bottelnek
Kom ons probeer om nie die bottel te skud nie, om nie een vir een deur alles te gaan wat daar is nie, maar kom ons kyk watter probleme sal opduik as ons skielik, vir ons taak, self so 'n stelsel ontwerp. Natuurlik sal ons nie die fiets bymekaarmaak nie, maar ons sal hierdie diagram gebruik om ons te help uitvind watter punte om aandag te gee in produkbeskrywings. Kom ons skets so 'n diagram.
As die stelsel versprei word, sal ons verskeie bedieners hê (6). Kom ons sê daar is vier (dit is gerieflik om hulle in die prentjie te plaas, maar daar kan natuurlik soveel van hulle wees as wat jy wil). As die bedieners op verskillende nodusse is, beteken dit dat hulle almal een of ander kode gebruik wat verantwoordelik is om te verseker dat hierdie nodusse 'n groep vorm en, in die geval van 'n breek, mekaar verbind en herken.
Ons benodig ook kodelogika (2), wat eintlik oor caching gaan. Kliënte interaksie met hierdie kode via een of ander API. Kliëntkode (1) kan óf binne dieselfde JVM wees óf toegang daartoe oor die netwerk hê. Die logika wat binne geïmplementeer word, is die besluit van watter voorwerpe om in die kas te laat en watter om uit te gooi. Ons gebruik geheue (3) om die kas te stoor, maar indien nodig, kan ons sommige van die data op skyf (4) stoor.
Kom ons kyk in watter dele die las sal plaasvind. Eintlik sal elke pyl en elke nodus gelaai word. Eerstens, tussen die kliëntkode en die api, as dit netwerkkommunikasie is, kan die insakking redelik opvallend wees. Tweedens, binne die raamwerk van die api self - as ons dit oordoen met komplekse logika, kan ons probleme ondervind met die SVE. En dit sal lekker wees as logika nie tyd op geheue mors nie. En daar bly interaksie met die lêerstelsel - in die gewone weergawe is dit serialiseer / herstel en skryf / lees.
Volgende is interaksie met die groep. Dit sal waarskynlik in dieselfde stelsel wees, maar dit kan afsonderlik wees. Hier moet jy ook die oordrag van data daarheen, die spoed van data-serialisering en interaksies tussen die groepering in ag neem.
Nou, aan die een kant, kan ons ons voorstel "watter ratte sal draai" in die kasstelsel wanneer ons versoeke van ons kode verwerk, en aan die ander kant kan ons skat watter en hoeveel versoeke ons kode na hierdie stelsel sal genereer. Dit is genoeg om 'n min of meer nugter keuse te maak - om 'n stelsel vir ons gebruiksgeval te kies.
haselgiet
Kom ons kyk hoe om hierdie ontbinding op ons lys toe te pas. Byvoorbeeld, Hazelcast.
Om data van Hazelcast te plaas/neem, kry die kliëntkode toegang tot (1) die api. Hz laat jou toe om die bediener soos ingebed te laat loop, en in hierdie geval is toegang tot die API 'n metode-oproep binne die JVM, wat as gratis beskou kan word.
Om die logika in (2) te laat werk, maak Hz staat op die hash van die byte-skikking van die geserialiseerde sleutel - dit wil sê, die sleutel sal in elk geval geserialiseer word. Dit is onvermydelike bokoste vir Hz.
Uitsettingstrategieë word goed geïmplementeer, maar vir spesiale gevalle kan jy jou eie byvoeg. Jy hoef nie bekommerd te wees oor hierdie deel nie.
Berging (4) kan gekoppel word. Groot. Interaksie (5) vir ingebed kan as onmiddellik beskou word. Data-uitruiling tussen nodusse in die groep (6) - ja, dit bestaan. Dit is 'n belegging in foutverdraagsaamheid ten koste van spoed. Die Hz-kenmerk Near-cache laat jou toe om die prys te verminder - data wat van ander nodusse in die cluster ontvang word, sal gekas word.
Wat kan in sulke toestande gedoen word om spoed te verhoog?
Byvoorbeeld, om serialisering van die sleutel in (2) te vermy - heg nog 'n kas bo-op Hazelcast aan vir die warmste data. Sportmaster het Kafeïen vir hierdie doel gekies.
Vir draai op vlak (6), bied Hz twee tipes berging: IMap en ReplicatedMap.
Dit is die moeite werd om te noem hoe Hazelcast in die Sportmaster-tegnologiestapel beland het.
In 2012, toe ons aan die heel eerste loods van die toekomstige webwerf gewerk het, was dit Hazelcast wat die eerste skakel was wat die soekenjin teruggestuur het. Die kennismaking het "die eerste keer" begin - ons was geboei deur die feit dat dit net twee uur later, toe ons Hz in die stelsel vasgeskroef het, gewerk het. En dit het goed gewerk. Teen die einde van die dag het ons 'n aantal toetse voltooi en was gelukkig. En hierdie reserwe van krag was genoeg om die verrassings wat Hz mettertyd opgegooi het te oorkom. Nou het die Sportmaster-span geen rede om Hazelcast te laat vaar nie.
Maar sulke argumente soos "die eerste skakel in die soekenjin" en "HelloWorld is vinnig saamgestel" is natuurlik 'n uitsondering en 'n kenmerk van die oomblik waarop die keuse plaasgevind het. Die werklike toetse vir die gekose stelsel begin met die vrystelling in produksie, en dit is op hierdie stadium dat u aandag moet gee wanneer u enige stelsel kies, insluitend kas. Eintlik kan ons in ons geval sê dat ons per ongeluk Hazelcast gekies het, maar toe blyk dit dat ons reg gekies het.
Vir produksie, baie belangriker: monitering, hantering van foute op individuele nodusse, data replikasie, koste van skaal. Dit wil sê, dit is die moeite werd om aandag te gee aan die take wat tydens die instandhouding van die stelsel sal opduik - wanneer die vrag tientalle keer hoër is as wat beplan is, wanneer ons per ongeluk iets op die verkeerde plek oplaai, wanneer ons 'n nuwe weergawe moet uitrol van die kode, vervang data en doen dit ongemerk vir kliënte.
Vir al hierdie vereistes, pas Hazelcast beslis die rekening.
Vervolg
Maar Hazelcast is nie 'n wondermiddel nie. In 2017 het ons Hazelcast vir die admin-kas gekies, bloot gebaseer op goeie indrukke uit vorige ervaring. Dit het 'n sleutelrol gespeel in 'n baie wrede grap, waardeur ons onsself in 'n moeilike situasie bevind het en "heldhaftig" vir 60 dae daaruit gekom het. Maar meer daaroor in die volgende deel.
Intussen... Gelukkige nuwe kode!
Bron: will.com