Slav! Navê min Alexey Pyankov e, ez li pargîdaniya Sportmaster pêşdebir im. Di wê de Min got ka xebata li ser malpera Sportmaster di sala 2012-an de çawa dest pê kir, me çi înîsiyatîf kir ku "dehf bidin" û berevajî vê yekê, me çi rakêş berhev kir.
Îro ez dixwazim ramanên ku li dû mijarek din dişopînin parve bikim - hilbijartina pergalek caching ji bo paşiya java-yê di qada rêvebirê malperê de. Ev komplo ji bo min xwedî wateyek taybetî ye - her çend çîrok tenê 2 mehan derketiye holê jî, di van 60 rojan de em 12-16 saetan û bêyî rojek betlaneyê xebitîn. Min qet nefikiribû û ne jî xeyal dikir ku ew qas dijwar bixebite.
Ji ber vê yekê, min nivîsê kir 2 beş da ku bi tevahî neyê barkirin. Berevajî vê, beşa yekem dê pir sivik be - amadekarî, danasînê, hin nêrînên derbarê kaşkirinê çi ye. Ger hûn jixwe pêşdebirek xwedî ezmûn in an jî bi kaxezan re xebitiye, ji hêla teknîkî ve bi îhtîmalek mezin dê di vê gotarê de tiştek nû nebe. Lê ji bo ciwanek, vekolînek wusa piçûk dikare jê re bêje ku ger ew xwe li xaçerêyek wusa bibîne li kîjan alî binêre.
Dema ku guhertoya nû ya malpera Sportmaster hate hilberandin, data bi rengek ku, bi hûrgulî, ne pir rehet bû hate wergirtin. Bingeh tabloyên ku ji bo guhertoya berê ya malperê (Bitrix) hatine amade kirin, ku diviyabû di ETL de were kişandin, bi formek nû were birin û ji dehan pergalên din bi tiştên piçûk ên cihêreng were dewlemend kirin. Ji bo ku wêneyek an ravekek nû ya hilberek li ser malperê xuya bibe, pêdivî bû ku hûn li benda roja din bisekinin - nûvekirin tenê bi şev, rojê carekê.
Di destpêkê de, ji hefteyên yekem ên ketina hilberînê de ew qas fikar hebûn ku nerehetiyên weha ji bo rêvebirên naverokê piçûktir bûn. Lê, gava ku her tişt bi cih bû, pêşveçûna projeyê berdewam kir - çend meh şûnda, di destpêka sala 2015-an de, me dest bi çalakkirina panela rêveberiyê kir. Di 2015 û 2016-an de, her tişt baş dimeşe, em bi rêkûpêk berdidin, panela rêveberiyê her ku diçe zêdetir amadekariya daneyê vedigire, û em ji vê yekê re amade dikin ku di demek nêzîk de dê tîmê me bi tiştê herî girîng û tevlihev - hilber were spartin. circuit (amadekirina tevahî û domandina daneyên li ser hemî hilberan). Lê di havîna 2017-an de, hema berî destpêkirina çerxa kelûmêlê, proje dê xwe di rewşek pir dijwar de bibîne - tam ji ber pirsgirêkên cachkirinê. Ez dixwazim di beşa duyemîn a vê weşana ku ji du beşan pêk tê de qala vê beşê bikim.
Lê di vê postê de ez ê ji dûr ve dest pê bikim, ez ê hin ramanan pêşkêşî bikim - ramanên di derbarê cachkirinê de, ku dê gavek baş be ku meriv li ber projeyek mezin bigere.
Dema ku karekî caching pêk tê
Karê cachkirinê ne tenê xuya dike. Em pêşdebir in, hilberek nermalavê dinivîsin û dixwazin ku ew daxwaz be. Ger hilber daxwaz û serfiraz be, dê bikarhêner werin. Û bêtir û bêtir tê. Û paşê gelek bikarhêner hene û paşê hilber pir barkirî dibe.
Di qonaxên yekem de, em li ser xweşbînkirin û performansa kodê nafikirin. Ya sereke fonksiyonel e, bi lez pîlotek derdixe û hîpotezan dike. Û heke bar zêde bibe, em hesin pompe dikin. Em du sê qat, pênc qat, belkî 10 qat zêde dikin. Li cîhek li vir - darayî dê êdî destûrê nede. Hejmara bikarhêneran dê çend caran zêde bibe? Dê ne wek 2-5-10 be, lê ger biserkeve, dê ji 100-1000 heta 100 hezar carî be. Ango, zû an dereng, hûn ê neçar bibin ku xweşbîniyê bikin.
Ka em bibêjin ku hin beşek kodê (ka em vê beşê wekî fonksiyonek bi nav bikin) demek dirêj dirêj digire, û em dixwazin dema darvekirinê kêm bikin. Fonksiyonek dikare bigihîje databasek, an jî ew dikare bibe cîbicîkirina hin mantiqek tevlihev - ya sereke ev e ku ew demek dirêj digire ku were temam kirin. Hûn dikarin çiqas wextê darvekirinê kêm bikin? Di sînor de, hûn dikarin wê ji sifirê kêm bikin, ne bêtir. Çawa hûn dikarin dema darvekirinê kêm bikin sifir? Bersiv: îdamê bi tevahî ji holê rakin. Di şûna wê de, encam tavilê vegerînin. Çawa hûn dikarin encamê bibînin? Bersiv: yan hesab bike yan jî li cihekî bigere. Ji bo hesabkirin demek dirêj digire. Û sîxurkirin ev e, mînakî, bîranîna encama ku fonksiyona cara dawî dema ku bi heman pîvanan tê gazî kirin hilberand.
Yanî pêkanîna fonksiyonê ji bo me ne girîng e. Tenê bes e ku meriv zanibe ku encam bi kîjan pîvanan ve girêdayî ye. Dûv re, heke nirxên parametreyê di forma tiştek ku dikare wekî mifteyek di hin hilanînê de were bikar anîn têne destnîşan kirin, wê hingê encama hesabkirinê dikare were hilanîn û gava ku tê gihîştinê were xwendin. Ger ev nivîsandin û xwendina encamê ji pêkanîna fonksiyonê zûtir be, di warê lezê de qezenca me heye. Mîqdara qezencê dikare bigihîje 100, 1000, û 100 hezar carî (10 ^ 5 bêtir îstîsnayek e, lê di rewşa bingehek berbiçav de, ew pir gengaz e).
Pêdiviyên bingehîn ji bo pergalek caching
Yekem tiştê ku dibe ku bibe pêdivî ji bo pergalek caching leza xwendina bilez û, hinekî kêmtir, leza nivîsandinê ye. Ev rast e, lê tenê heya ku em pergalê berbi hilberînê vekin.
Werin em vê dozê bilîzin.
Ka em bibêjin ku me barkirina heyî bi hardware peyda kiriye û naha hêdî hêdî cachkirinê destnîşan dikin. Hejmara bikarhêneran piçekî mezin dibe, bargiraniyê mezin dibe - em piçek kelûpelan lê zêde dikin, wê li vir û li wir biqelînin. Ev ji bo demekê berdewam dike, û naha fonksiyonên giran bi pratîkî êdî nayên gotin - tevahiya barê sereke dikeve ser cache. Di vê demê de hejmara bikarhêneran N car zêde bûye.
Û ger dabînkirina destpêkê ya hardware 2-5 carî be, wê hingê bi alîkariya cache em dikarin performansê bi faktorek 10 an, di rewşek baş de, bi faktorek 100, li hin deveran belkî bi faktorek çêtir bikin. ji 1000. Ango, li ser heman hardware - em 100 caran zêdetir daxwazên pêvajoyê dikin. Baş e, hûn nanê zencîreyê heq dikin!
Lê naha, di demek xweş de, bi şensê, pergal têk çû û cache hilweşiya. Tiştek taybetî - her tiştî, cache li ser bingeha hewcedariya "leza xwendin û nivîsandina bilind, ya mayî ne girîng e" hate hilbijartin.
Li gorî barkirina destpêkê, rezerva meya hesin 2-5 carî bû, û bar di vê demê de 10-100 carî zêde bû. Bi karanîna cache, me bangên fonksiyonên giran rakirin û ji ber vê yekê her tişt xebitî. Û naha, bêyî cache, dê çend caran pergala me hêdî bibe? Wê çi were serê me? Sîstem wê têk biçe.
Her çend cache me têk neçe, lê tenê ji bo demekê were paqij kirin, ew ê hewce bike ku were germ kirin, û ev ê çend dem bigire. Û di vê demê de, barê sereke dê li ser fonksiyonê bikeve.
Encam: Projeyên hilberîna pir barkirî pêdivî bi pergalek caching heye ku ne tenê xwedî leza xwendin û nivîsandinê ya bilind be, lê di heman demê de ji bo ewlehiya daneyê û berxwedana li hember têkçûn jî peyda bike.
Onyşa hilbijartinê
Di projeyek bi panelek rêveberiyê de, bijartî bi vî rengî derbas bû: pêşî me Hazelcast saz kir, ji ber Em berê ji ezmûna malpera sereke bi vê hilberê nas bûn. Lê li vir ev bijare neserketî derket - di binê profîla barkirina me de, Hazelcast ne tenê hêdî ye, lê pir jî hêdî ye. Û di wê demê de me berê xwe ji bo roja berdanê îmze kiribû.
Spoiler: bi rastî şert û mercên çawa pêş ketine ku me bêriya karek wusa mezin kir û bi rewşek tûj û tansiyonî ve hat - ez ê di beşa duyemîn de ji we re vebêjim - û em çawa bi dawî bûn û em çawa derketin. Lê naha - ez ê tenê bibêjim ku ew pir stres bû, û "bifikirim - bi rengekî ez nikarim bifikirim, em şûşê dihejînin." "Hejandina şûşê" di heman demê de xirabiyek e, li ser wê paşê.
Me çi kir:
- Em navnîşek hemî pergalên ku Google û StackOverflow pêşniyar dikin çêbikin. Piçek zêdetirî 30
- Em ceribandinên bi barek tîpîk ji bo hilberînê dinivîsin. Ji bo vê yekê, me daneyên ku di nav pergalê de di hawîrdorek hilberandinê de derbas dibe tomar kir - celebek ji bo daneyên ne li ser torê, lê di hundurê pergalê de. Di testan de tam ev dane hatin bikaranîn.
- Bi tevahiya tîmê re, her kes pergala paşîn ji navnîşê hildibijêre, wê mîheng dike, û ceribandinan dimeşîne. Ew ceribandinê derbas nake, ew bar hilnagire - em wî davêjin û di rêzê de diçin yê din.
- Di pergala 17. de diyar bû ku her tişt bêhêvî ye. Dev ji hejandina şûşê berdin, dem hatiye ku meriv bi ciddî bifikire.
Lê ev vebijarkek e dema ku hûn hewce ne ku pergalek hilbijêrin ku dê di ceribandinên pêş-amadekirî de "bi lezê derbas bibe". Ger hîn ceribandinên weha tune ne û hûn dixwazin zû hilbijêrin?
Werin em vê vebijarkê model bikin (zehmet e ku meriv xeyal bike ku pêşdebirek + navîn di valahiyek de dijî, û di dema hilbijartinê de hîn tercîha xwe fermî nekiriye ka kîjan hilber pêşî biceribîne - ji ber vê yekê, ramanên din bêtir teorîsyenek / felsefe / ye. li ser ciwanek).
Piştî ku li ser daxwazan biryar da, em ê dest pê bikin ku çareseriyek ji qutiyê hilbijêrin. Çima çerxê ji nû ve îcad bikin: em ê herin û pergalek cachkirinê ya amade bistînin.
Ger hûn nû dest pê dikin û wê google bikin, wê hingê fermanê bidin an bistînin, lê bi gelemperî, rêwerz dê bi vî rengî bin. Berî her tiştî, hûn ê rastî Redisê werin, ew li her derê tê bihîstin. Wê hingê hûn ê fêr bibin ku EhCache pergala herî kevn û herî îsbatkirî ye. Dûv re em ê li ser Tarantool, pêşkeftinek navxweyî ya ku xwedan aliyek bêhempa ya çareseriyê ye, binivîsin. Û her weha Ignite, ji ber ku ew naha di nav populerbûnê de ye û ji piştgiriya SberTech kêfê digire. Di dawiyê de Hazelcast jî heye, ji ber ku di cîhana pargîdaniyê de ew pir caran di nav pargîdaniyên mezin de xuya dike.
Lîsteya ne temam e, bi dehan sîstem hene. Û em ê tenê yek tişt bişkînin. Ka em 5 pergalên hilbijartî ji bo "pêşbirka bedewiyê" bigirin û hilbijarkek bikin. Kî dê bibe serketî?
Redis
Em dixwînin ka ew li ser malpera fermî çi dinivîsin.
- projeya çavkaniya vekirî. Hilberîna daneya nav-bîrê, şiyana hilanîna li ser dîskê, dabeşkirina xweser, hebûna zêde û vegerandina ji qutbûna torê pêşkêşî dike.
Wusa dixuye ku her tişt baş e, hûn dikarin wê bigirin û pê bixin - her tiştê ku hûn hewce ne, ew dike. Lê tenê ji bo kêfê, em li berendamên din binêrin.
EhCache
- "cache ya herî berfireh ji bo Java-yê tê bikar anîn" (wergera dirûşmê ji malpera fermî). Jî çavkaniya vekirî. Dûv re em fêm dikin ku Redis ne ji bo java, lê gelemperî ye, û ji bo ku hûn pê re têkilî daynin hûn pêçekek hewce ne. Û EhCache dê hêsantir be. Sîstema din çi soz dide? Pêbawerî, îsbatkirî, fonksiyona tam. Welê, ew jî ya herî gelemperî ye. Û terabytes daneyan vedişêre.
Redis ji bîr kirin, ez amade me ku EhCache hilbijêrin.
Lê hestek welatparêziyê min dihêle ku bibînim ka Tarantool çi baş e.
Tarantool
- bi navnîşana "Platforma yekbûna daneya rast-dem" pêk tê. Ew pir tevlihev xuya dike, ji ber vê yekê em rûpelê bi hûrgulî dixwînin û gotinek dengdar dibînin: "100% daneyan di RAM-ê de vedişêre." Pêdivî ye ku ev pirsan derxe holê - her tiştî, dikare ji bîranînê pirtir dane hebin. Ravekirin ev e ku ev tê vê wateyê ku Tarantool serialîzasyonê naxebitîne da ku daneyan li ser dîskê ji bîranînê binivîse. Di şûna wê de, ew taybetmendiyên pergalê yên asta nizm bikar tîne, dema ku bîranîn bi hêsanî bi pergalek pelê bi performansa I/O ya pir baş ve tête nexşandin. Bi gelemperî, wan tiştek ecêb û xweş kir.
Ka em li pêkanînan binêrin: Rêya pargîdanî Mail.ru, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Ger hîn jî guman di derbarê Tarantool de hebin, wê hingê doza pêkanînê li Mastercard min xilas dike. Ez Tarantool digirim.
Lê bi her awayî…
Vêxistin
… hinekên din hene , wekî "platformek hesabkirinê ya di bîrê de...leza di bîrê de li ser petabytes daneyan" tê hesibandin. Li vir gelek avantaj jî hene: cache-ya-ya-yê belavkirî, hilanîn û cache-ya herî bilez a key-nirxê, pîvana horizontî, hebûna zêde, yekparebûna hişk. Bi gelemperî, derdikeve ku zûtirîn Ignite ye.
Pêkanînan: Sberbank, American Airlines, Yahoo! Japonya. Û dûv re ez fêr dibim ku Ignite ne tenê di Sberbank de tête bicîh kirin, lê tîmê SberTech mirovên xwe dişîne tîmê Ignite bixwe da ku hilberê paqij bike. Ev bi tevahî balkêş e û ez amade me ku Ignite bigirim.
Bi tevahî ne diyar e çima, ez li xala pêncemîn dinêrim.
hazelcast
Ez diçim malperê , xwendin. Û derket holê ku çareseriya zûtirîn ji bo cachkirina belavkirî Hazelcast e. Ew fermanên mezinahiyê ji hemî çareseriyên din zûtir e û bi gelemperî ew di warê tora daneyên bîranînê de pêşeng e. Li hember vê paşerojê, wergirtina tiştek din ne rêzgirtina ji xwe ye. Di heman demê de ew hilanîna daneya zêde ji bo xebata domdar a komê bêyî windabûna daneyê jî bikar tîne.
Ew e, ez amade me ku Hazelcast bigirim.
Comparison
Lê heke hûn lê binêrin, her pênc berendam bi vî rengî têne vegotin ku her yek ji wan çêtirîn e. Çawa hilbijêre? Em dikarin bibînin ka kîjan herî populer e, li berhevdanan bigerin, û serêş dê derkeve.
Em yekî bi vî rengî dibînin , 5 pergalên me hilbijêrin.
Li vir ew têne rêz kirin: Redis li jor e, Hazelcast di rêza duyemîn de ye, Tarantool û Ignite populerbûnê digirin, EhCache heman bûye û dimîne.
Lê em lê binêrin : Zencîreyên malperan, berjewendiya giştî ya pergalê, pêşniyarên kar - mezin! Ango gava pergala min têk biçe, ez ê bibêjim: “Na, pêbawer e! Gelek pêşniyarên kar hene. ”… Berawirdkirinek wusa hêsan dê nekeve.
Hemî van pergal ne tenê pergalên caching in. Di heman demê de gelek fonksiyonên wan jî hene, di nav de dema ku dane ji bo pêvajoyê ji xerîdar re nayê pompe kirin, lê berevajî: koda ku divê li ser daneyan were darve kirin berbi serverê ve diçe, li wir tê darve kirin, û encam vedigere. Û ew pir caran wekî pergalek veqetandî ji bo cachkirinê nayên hesibandin.
Baş e, em dev jê bernedin, bila rasterast danberhevek pergalan bibînin. Ka em du vebijarkên jorîn bigirin - Redis û Hazelcast. Em bi lezê re eleqedar in, û em ê wan li ser bingeha vê parametreyê bidin ber hev.
Hz vs Redis
Em vê yekê dibînin :
Şîn Redis e, sor Hazelcast e. Hazelcast li her derê bi ser dikeve, û ji bo vê yekê maqûliyek heye: ew pir-mijalek e, pir xweşbîn e, her mijar bi dabeşkirina xwe re dixebite, ji ber vê yekê astengî tune. Û Redis yek-têlek e; ew ji CPU-yên pir-bingehîn ên nûjen sûd wernagire. Hazelcast xwedan I/O asynchronous e, Redis-Jedis xwedan soketên astengkirinê ye. Beriya her tiştî, Hazelcast protokolek binary bikar tîne, û Redis-navend-nivîsar e, tê vê wateyê ku ew bêbandor e.
Tenê di rewşê de, em vegerin ser çavkaniyek din a berhevdanê. Ew ê çi nîşanî me bide?
Redis vs Hz
Yekî din :
Li vir, berevajî, sor Redis e. Ango, Redis di warê performansê de ji Hazelcastê derdikeve. Hazelcast berhevoka yekem qezenc kir, Redis ya duyemîn qezenc kir. pir rast rave kir ku çima Hazelcast berhevoka berê qezenc kir.
Derket holê ku encama ya yekem bi rastî hatî xera kirin: Redis di qutiya bingehîn de hate girtin, û Hazelcast ji bo dozek ceribandinê hate çêkirin. Dûv re derket holê: yekem, em nikarin ji kesî bawer bikin, û ya duyemîn jî, gava ku em di dawiyê de pergalek hilbijêrin, em hîn jî hewce ne ku wê rast mîheng bikin. Van mîhengan bi dehan, hema hema bi sedan parametre dihewîne.
Şûşê dihejand
Û ez dikarim tevahiya pêvajoya ku me niha kiriye bi metafora jêrîn rave bikim: "Şûşê hejandin." Ango, naha hûn ne hewce ne ku bername bikin, naha ya sereke ev e ku hûn karibin stackoverflow bixwînin. Û di tîmê min de kesek heye, pisporek, ku di demên krîtîk de bi vî rengî dixebite.
Ew çi dike? Tiştekî şikestî dibîne, şopek stekê dibîne, hin peyvan jê digire (ku di bernameyê de pisporiya wî ne), li Google digere, di nav bersivan de stackoverflow dibîne. Bê xwendin, bê fikirîn, di nav bersivên pirsê de, ew tiştek herî dişibihe hevoka "wiha û wî bike" hildibijêre (hilbijartina bersivek weha jêhatiya wî ye, ji ber ku her gav ne bersiv e ku herî zêde ecibandin). derbas dibe, xuya dike: heke tiştek guherî, wê hingê mezin e. Ger ew nehatibe guhertin, wê paşde bizivirînin. Û destpêkirin-kontrol-lêgerînê dubare bikin. Û bi vî awayê xwerû, ew piştrast dike ku kod piştî demekê dixebite. Nizane çima, nizane çi kiriye, nikare rave bike. Lebê! Ev enfeksiyonê dixebite. Û "agir tê vemirandin." Naha em fêhm bikin ku me çi kiriye. Dema ku bername dixebite, ew fermanek mezinahiyê hêsantir e. Û ew gelek dem xilas dike.
Ev rêbaz bi vê nimûneyê pir baş tê ravekirin.
Carekê pir populer bû ku keştiyek di şûşeyek de berhev bike. Di heman demê de, keştiya keştiyê mezin û zirav e, û stûyê şûşeyê jî pir teng e, ne gengaz e ku meriv wê bike hundur. Meriv çawa wê berhev bike?
Rêbazek weha heye, pir bi lez û pir bi bandor.
Keştî ji komek tiştên piçûk pêk tê: çîp, belengaz, keştî, benîşt. Em van hemûyan dixin şûşekê.
Em bi herdu destan şûşeyê digirin û dest bi hejandinê dikin. Em wê dihejînin û dihejînin. Û bi gelemperî ew zibilek bêkêmasî ye, bê guman. Lê carinan. Carinan dibe ku ew keştiyek e! Bi rastî, tiştek mîna keştiyek.
Em vê yekê nîşanî kesekî didin: "Seryoga, tu dibînî!" Û bi rastî, ji dûr ve ew mîna keştiyek xuya dike. Lê ev yek nikare berdewam bike.
Rêyek din heye. Ew ji hêla xortên pêşkeftî ve, wekî hackeran, têne bikar anîn.
Min peywirek da vî zilamî, her tişt kir û çû. Û hûn dinêrin - wusa dixuye ku ew hatî çêkirin. Û piştî demekê, dema ku kod pêdivî ye ku were qedandin, ev ji ber wî dest pê dike ... Baş e ku wî berê xwe da dûr bireve. Ev zilam in ku, mînaka şûşeyek bikar bînin, dê vê yekê bikin: hûn dibînin, binê ku derê ye, cam diqelişe. Û bi tevahî ne diyar e ka ew zelal e an na. Dûv re "hackers" vî binî qut dikin, keştiyek têxin wir, dûv re dîsa binî ve zeliqînin, û wusa dixuye ku ew wusa ye.
Ji xala danîna pirsgirêkê, her tişt rast xuya dike. Lê karanîna keştiyan wekî mînak: çima vê keştiyê bi tevahî çêdikin, kê jî jê re hewce dike? Ew ti fonksiyonek peyda nake. Bi gelemperî keştiyên weha diyarî ji mirovên pir payebilind re ne, yên ku ew li ser refikek li jorê wan, wekî celebek sembol, wekî nîşanek datînin. Û eger kesek weha, serokê karsaziyek mezin an karbidestek payebilind, wê çawa ala li ber hakek wusa ku stûyê wê hatî birîn bisekine? Ew ê çêtir be ku ew qet ji vê yekê nizane. Ji ber vê yekê, ew çawa diqedin van keştiyên ku dikarin bidin kesek girîng?
Yekane cîhê sereke ku hûn bi rastî nikarin tiştek li ser bikin laş e. Û qalikê keştiyê rastê di stûyê xwe de dikeve. Digel ku keştî li derveyî şûşeyê tê berhev kirin. Lê ew ne tenê komkirina keştiyek e, ew pîşesaziyek zêrînek rastîn e. Leverên taybetî li pêkhateyan têne zêdekirin, ku dûv re dihêle ku ew werin rakirin. Mînakî, keşt têne pêçan, bi baldarî têne hundur, û dûv re, bi alîkariya pilingan, ew pir rast, bi hûrgulî têne kişandin û bilind kirin. Encam karekî hunerî ye ku bi wijdanek paqij û serbilindî dikare were diyar kirin.
Û heke em dixwazin proje bi ser keve, divê di tîmê de bi kêmanî yek zêrker hebe. Kesê ku bala xwe dide kalîteya hilberê û hemî aliyan li ber çavan digire, bêyî ku tiştek qurban bike, tewra di demên stresê de, dema ku şert û merc hewce dike ku li ser hesabê tiştê girîng kirina lezgîniyê bike. Hemû projeyên serketî yên ku domdar in, ku di ceribandina demê de rawestiyane, li ser vê prensîbê têne avakirin. Tiştek pir rast û bêhempa li ser wan heye, tiştek ku ji hemî îmkanên berdest sûd werdigire. Di mînaka bi keştiya di şûşeyê de, rastiya ku qalikê keştiyê ji stûyê derbas dibe, tê lîstin.
Vegere ser karê hilbijartina servera meya caching, ev rêbaz çawa dikare were sepandin? Ez vê vebijarkê ya hilbijartina ji hemî pergalên ku hene pêşkêşî dikim - şûşê nehejînin, hilbijêrin, lê binihêrin ka di prensîbê de çi heye, dema hilbijartina pergalek li çi digerin.
Li ku derê li stûyê şûşê bigerin
Werin em hewl bidin ku şûşê nehejînin, her tiştê ku li wir heye yek bi yek derbas nekin, lê em bibînin ka dê çi pirsgirêk derkevin holê heke em ji nişka ve, ji bo peywira xwe, bi xwe pergalek wusa sêwirînin. Bê guman, em ê bisiklêtê kom nekin, lê em ê vê diagramê bikar bînin da ku ji me re bibe alîkar ku em zanibin ka em di danasînên hilberê de bala xwe bidin kîjan xalan. Werin em xêzek weha xêz bikin.
Ger pergal were belavkirin, wê hingê em ê çend serverên me hebin (6). Ka em bibêjin çar hene (rehet e ku meriv wan di wêneyê de bi cîh bike, lê, bê guman, dikare bi qasî ku hûn dixwazin hebin). Ger pêşkêşker li ser girêkên cihê ne, ev tê vê wateyê ku ew hemî kodek dimeşînin ku berpirsiyar e ku van girêkan komek çêbikin û, di bûyera qutbûnê de, hevûdu girêdin û nas bikin.
Di heman demê de em hewceyê mantiqa kodê (2) jî heye, ku bi rastî li ser cachkirinê ye. Xerîdar bi hin API-ê bi vê kodê re têkilî daynin. Koda xerîdar (1) dikare di nav heman JVM de be an jî bigihîje wê li ser torê. Mantiqa ku di hundurê de hatî bicîh kirin ev e ku meriv kîjan tiştan di kaşê de bihêle û kîjan bavêje derve. Em bîra (3) bikar tînin da ku cache hilînin, lê heke hewce be, em dikarin hin daneyan li ser dîskê (4) hilînin.
Ka em bibînin ka dê barkirin li kîjan beşan pêk were. Bi rastî, her tîr û her nodek dê were barkirin. Pêşîn, di navbera koda xerîdar û api de, heke ev pêwendiya torê be, hilweşîn dikare pir berbiçav be. Ya duyemîn jî, di çarçoveya api-ya xwe de - heke em bi mantiqa tevlihev zêde bikin, em dikarin bi CPU-yê re pirsgirêk derkevin. Û wê baş be ku mentiq wextê xwe li ser bîrê winda neke. Û pêwendiyek bi pergala pelê re dimîne - di guhertoya gelemperî de ev serialîzekirin / sererastkirin û nivîsandin / xwendin e.
Paşê pêwendiya bi komê re ye. Bi îhtîmaleke mezin, ew ê di heman pergalê de be, lê ew dikare ji hev cuda be. Li vir hûn jî hewce ne ku veguheztina daneyan li ser wê, leza serialîzasyona daneyê û danûstendinên di navbera komê de bigirin.
Naha, ji aliyek ve, em dikarin di pergala cache-ê de dema ku daxwazên koda me hildiweşînin de xeyal bikin "kîjan gear dê bizivirin", û ji hêla din ve, em dikarin texmîn bikin ka koda me dê çi û çend daxwazan ji vê pergalê re çêbike. Ev bes e ku meriv hilbijarkek kêm-zêde hişyar bike - ji bo doza karanîna me pergalê hilbijêrin.
hazelcast
Ka em bibînin ka meriv çawa vê hilweşandinê li navnîşa xwe bicîh tîne. Mînakî, Hazelcast.
Ji bo ku daneyan ji Hazelcastê bixin / bigirin, koda xerîdar digihîje (1) api. Hz destûrê dide te ku hûn serverê wekî pêvekirî bimeşînin, û di vê rewşê de, gihîştina api bangek rêbazek di hundurê JVM de ye, ku dikare belaş were hesibandin.
Ji bo ku mantiqa di (2) de bixebite, Hz xwe dispêre hash-a array byte ya mifteya serialîzekirî - ango kilît dê di her rewşê de serialîze bibe. Ev ji bo Hz.
Stratejiyên derxistinê baş têne bicîh kirin, lê ji bo rewşên taybetî hûn dikarin yên xwe zêde bikin. Ne hewce ye ku hûn li ser vê beşê xemgîn bibin.
Storage (4) dikare were girêdan. Ecêb. Têkiliya (5) ji bo vegirtinê dikare tavilê were hesibandin. Danûstandina daneyan di navbera girêkên di komê de (6) - erê, ew heye. Ev veberhênanek di tolerasyona xeletiyê de li ser lêçûna bileziyê ye. Taybetmendiya Hz Near-cache dihêle hûn bihayê kêm bikin - daneyên ku ji girêkên din ên di komê de hatine wergirtin dê werin cache kirin.
Di şert û mercên wiha de ji bo zêdekirina lezê çi dikare were kirin?
Mînakî, ji bo ku di (2)-ê de serialîzekirina mifteyê dûr bixin - ji bo daneya herî germ, kaşek din li ser Hazelcast ve girêdin. Sportmaster ji bo vê armancê Caffeine hilbijart.
Ji bo zivirîna di asta (6) de, Hz du celeb hilanînê pêşkêşî dike: IMap û ReplicatedMap.
Hêjayî gotinê ye ku Hazelcast çawa ket nav stoka teknolojiya Sportmaster.
Di sala 2012-an de, dema ku me li ser pîlota yekem a malpera pêşerojê dixebitî, ew Hazelcast bû ku bû yekem girêdana ku motora lêgerînê vedigere. Nasîn "cara yekem" dest pê kir - em ji vê yekê dîl bûn ku tenê du demjimêr şûnda, gava ku me Hz xist nav pergalê, ew xebitî. Û ew baş xebitî. Di dawiya rojê de me gelek ceribandin temam kirin û kêfxweş bûn. Û ev rezerva hêzê bes bû ku ew surprîzên ku Hz bi demê re avêtibûn bi ser keve. Naha tîmê Sportmaster ti sedem tune ku dev ji Hazelcast berde.
Lê argumanên wekî "girêdana yekem di motora lêgerînê de" û "HelloWorld zû hate berhev kirin", bê guman, îstîsnayek û taybetmendiyek dema ku hilbijartin pêk hat. Testên rastîn ên ji bo pergala bijartî bi berdana hilberandinê dest pê dikin, û di vê qonaxê de ye ku divê hûn gava ku her pergalê hilbijêrin, tevî cache, bala xwe bidin. Bi rastî, di rewşa me de em dikarin bibêjin ku me Hazelcast bi tesadufî hilbijart, lê piştre derket ku me rast hilbijart.
Ji bo hilberînê, pir girîngtir: çavdêrîkirin, hilanîna têkçûnên li ser girêkên kesane, dubarekirina daneyan, lêçûna pîvandinê. Ango, hêja ye ku meriv bala xwe bide peywirên ku dê di dema domandina pergalê de derkevin holê - gava ku bar bi dehan carî ji plansaziyê mezintir e, gava ku em bi xeletî tiştek li cîhê xelet bar dikin, dema ku em hewce ne ku guhertoyek nû derxînin ya kodê, daneyan biguhezînin û wê ji bo xerîdaran bêhemdî bikin.
Ji bo van hemî hewcedariyên, Hazelcast bê guman li bendê ye.
Ez bêtir ji te hez dikim
Lê Hazelcast ne dermanek e. Di sala 2017-an de, me Hazelcast ji bo cache-a rêveberiyê hilbijart, bi tenê li ser bingehê bandorên baş ên ji ezmûna paşîn. Ev yek di pêkenokeke pir hovane de roleke sereke lîst, ji ber wê em xwe di nav rewşeke dijwar de dîtin û 60 rojan bi "qehremanî" jê derketin. Lê bêtir li ser wê di beşa pêş de.
Di vê navberê de... Koda Nû pîroz be!
Source: www.habr.com