Kā mēs Sportmaster izvēlējāmies keÅ”atmiņas sistēmu. 1. daļa

Sveiki! Mani sauc Aleksejs Pjankovs, es esmu izstrādātājs uzņēmumā Sportmaster. Tajā pastu StāstÄ«ju, kā 2012. gadā sākās darbs Sportmaster mājaslapā, kādas iniciatÄ«vas izdevās ā€œizstumt cauriā€ un otrādi, kādu grābekli savācām.

Å odien vēlos padalÄ«ties pārdomās, kas seko citai tēmai ā€“ java aizmugursistēmas keÅ”atmiņas sistēmas izvēle vietnes admin panelÄ«. Å im sižetam man ir Ä«paÅ”a nozÄ«me - lai gan stāsts risinājās tikai 2 mēneÅ”us, Å”ajās 60 dienās mēs strādājām 12-16 stundas un bez nevienas brÄ«vas dienas. Nekad nebiju domājusi vai iedomājusies, ka var tik smagi strādāt.

Tāpēc es tekstu sadalÄ«ju 2 daļās, lai neielādētos pilnÄ«bā. TieÅ”i otrādi, pirmā daļa bÅ«s ļoti viegla ā€“ sagatavoÅ”ana, ievads, daži apsvērumi par to, kas ir caching. Ja esat jau pieredzējis izstrādātājs vai strādājis ar keÅ”atmiņām, no tehniskās puses, visticamāk, Å”ajā rakstā nekas jauns nebÅ«s. Bet junioram tik mazs apskats var pateikt, kurā virzienā jāskatās, ja viņŔ nonāk Ŕādā krustcelēs.

Kā mēs Sportmaster izvēlējāmies keÅ”atmiņas sistēmu. 1. daļa

Kad Sportmaster mājaslapas jaunā versija tika nodota ražoÅ”anā, dati tika saņemti tā, kā, maigi izsakoties, ne pārāk ērti. Par pamatu tika ņemtas vietnes iepriekŔējai versijai (Bitrix) sagatavotas tabulas, kuras bija jāievelk ETL, jāpārnes jaunā formā un jāpapildina ar dažādiem sÄ«kumiem no vēl duci sistēmu. Lai vietnē parādÄ«tos jauna bilde vai preces apraksts, bija jāgaida lÄ«dz nākamajai dienai - atjauninājumi tikai naktÄ«, reizi dienā.

Sākumā jau no pirmajām ražoÅ”anas nedēļām bija tik daudz raižu, ka Ŕādas neērtÄ«bas satura pārvaldniekiem bija sÄ«kums. Bet, tiklÄ«dz viss sakārtojās, projekta attÄ«stÄ«ba turpinājās ā€“ dažus mēneÅ”us vēlāk, 2015. gada sākumā, sākām aktÄ«vi attÄ«stÄ«t admin paneli. 2015. un 2016. gadā viss norit labi, izlaižam regulāri, admin panelis aptver arvien vairāk datu sagatavoÅ”anas un gatavojamies tam, ka drÄ«zumā mÅ«su komandai tiks uzticēts pats svarÄ«gākais un sarežģītākais - produkts ķēde (pilnÄ«ga datu sagatavoÅ”ana un uzturÄ“Å”ana par visiem produktiem). Taču 2017. gada vasarā, tieÅ”i pirms preču ķēdes palaiÅ”anas, projekts nonāks ļoti sarežģītā situācijā ā€“ tieÅ”i keÅ”atmiņas problēmu dēļ. Par Å”o epizodi vēlos runāt Ŕīs divdaļīgās publikācijas otrajā daļā.

Bet Ŕajā ierakstā sākŔu no tālienes, izklāstīŔu dažas pārdomas - idejas par caching, kas būtu labs solis, lai ritinātu pirms liela projekta.

Kad notiek keÅ”atmiņas uzdevums

KeÅ”atmiņas uzdevums ne tikai parādās. Mēs esam izstrādātāji, rakstām programmatÅ«ras produktu un vēlamies, lai tas bÅ«tu pieprasÄ«ts. Ja produkts ir pieprasÄ«ts un veiksmÄ«gs, lietotāji nāks. Un nāk arvien vairāk. Un tad ir daudz lietotāju, un tad produkts kļūst ļoti noslogots.

Pirmajos posmos mēs nedomājam par optimizāciju un koda veiktspēju. Galvenais ir funkcionalitāte, ātra pilota izvērÅ”ana un hipotēžu pārbaude. Un, ja slodze palielinās, mēs sÅ«knējam dzelzi. Mēs to palielinām divas vai trÄ«s reizes, piecas reizes, varbÅ«t 10 reizes. Kaut kur Å”eit ā€“ finanses vairs neļaus. Cik reizes palielināsies lietotāju skaits? Tas nebÅ«s kā 2-5-10, bet veiksmes gadÄ«jumā tas bÅ«s no 100-1000 lÄ«dz 100 tÅ«kstoÅ”iem reižu. Tas ir, agrāk vai vēlāk jums bÅ«s jāveic optimizācija.

Pieņemsim, ka kāda koda daļa (sauksim Å”o daļu par funkciju) aizņem nepieklājÄ«gi ilgu laiku, un mēs vēlamies samazināt izpildes laiku. Funkcija var bÅ«t piekļuve datu bāzei vai arÄ« kādas sarežģītas loÄ£ikas izpilde ā€“ galvenais, lai tās izpilde prasa ilgu laiku. Cik daudz jÅ«s varat samazināt izpildes laiku? Ierobežojumā varat to samazināt lÄ«dz nullei, ne tālāk. Kā jÅ«s varat samazināt izpildes laiku lÄ«dz nullei? Atbilde: pilnÄ«bā likvidēt izpildi. Tā vietā nekavējoties atgrieziet rezultātu. Kā jÅ«s varat uzzināt rezultātu? Atbilde: vai nu parēķiniet, vai kaut kur paskatieties. Lai aprēķinātu, ir nepiecieÅ”ams ilgs laiks. Un izspiegot nozÄ«mē, piemēram, atcerēties rezultātu, ko funkcija radÄ«ja pēdējo reizi, kad tā tika izsaukta ar tādiem paÅ”iem parametriem.

Tas ir, funkcijas Ä«stenoÅ”ana mums nav svarÄ«ga. Pietiek tikai zināt, no kādiem parametriem atkarÄ«gs rezultāts. Pēc tam, ja parametru vērtÄ«bas ir attēlotas objekta veidā, ko var izmantot kā atslēgu kādā krātuvē, tad aprēķina rezultātu var saglabāt un nolasÄ«t nākamreiz, kad tam piekļūst. Ja Ŕī rezultāta rakstÄ«Å”ana un nolasÄ«Å”ana ir ātrāka nekā funkcijas izpilde, mums ir peļņa ātruma ziņā. Peļņas apjoms var sasniegt 100, 1000 un 100 tÅ«kstoÅ”us reižu (10^5 drÄ«zāk ir izņēmums, bet diezgan atpaliekoÅ”as bāzes gadÄ«jumā tas ir pilnÄ«gi iespējams).

PamatprasÄ«bas keÅ”atmiņas sistēmai

Pirmā lieta, kas var kļūt par prasÄ«bu keÅ”atmiņas sistēmai, ir ātrs lasÄ«Å”anas ātrums un, nedaudz mazākā mērā, rakstÄ«Å”anas ātrums. Tā ir taisnÄ«ba, bet tikai lÄ«dz brÄ«dim, kad sistēma tiks ieviesta ražoÅ”anā.

Izspēlēsim Å”o lietu.

Pieņemsim, ka esam nodroÅ”inājuÅ”i paÅ”reizējo slodzi ar aparatÅ«ru un tagad pakāpeniski ievieÅ”am keÅ”atmiņu. Lietotāju skaits nedaudz aug, slodze aug - pievienojam nedaudz keÅ”atmiņas, ieskrÅ«vējam Å”ur tur. Tas turpinās kādu laiku, un tagad smagās funkcijas praktiski vairs netiek izsauktas - visa galvenā slodze krÄ«t uz keÅ”atmiņu. Lietotāju skaits Å”ajā laikā ir pieaudzis N reizes.

Un, ja sākotnējā aparatÅ«ras piegāde varētu bÅ«t 2-5 reizes, tad ar keÅ”atmiņas palÄ«dzÄ«bu mēs varētu uzlabot veiktspēju 10 vai, labā gadÄ«jumā, 100, dažviet varbÅ«t arÄ« koeficientu. no 1000. Tas ir, uz vienas aparatÅ«ras ā€” mēs apstrādājam 100 reizes vairāk pieprasÄ«jumu. Lieliski, jÅ«s esat pelnÄ«juÅ”i piparkÅ«kas!

Bet tagad vienā jaukā brÄ«dÄ« nejauÅ”i sistēma avarēja un keÅ”atmiņa sabruka. Nekas Ä«paÅ”s - galu galā keÅ”atmiņa tika izvēlēta, pamatojoties uz prasÄ«bu ā€œliels lasÄ«Å”anas un rakstÄ«Å”anas ātrums, pārējam nav nozÄ«mesā€.

SalÄ«dzinot ar starta slodzi, mÅ«su dzelzs rezerves bija 2-5 reizes, un slodze Å”ajā laikā palielinājās 10-100 reizes. Izmantojot keÅ”atmiņu, mēs novērsām smagas funkcijas, un tāpēc viss darbojās. Un tagad, bez keÅ”atmiņas, cik reizes mÅ«su sistēma palēnināsies? Kas ar mums notiks? Sistēma kritÄ«s.

Pat ja mÅ«su keÅ”atmiņa neavarēja, bet tika notÄ«rÄ«ta tikai uz brÄ«di, tā bÅ«s jāiesilda, un tas prasÄ«s kādu laiku. Un Å”ajā laikā galvenais slogs gulsies uz funkcionalitāti.

Secinājums: ļoti noslogotiem ražoÅ”anas projektiem ir nepiecieÅ”ama keÅ”atmiņas sistēma ne tikai ar augstu lasÄ«Å”anas un rakstÄ«Å”anas ātrumu, bet arÄ« lai nodroÅ”inātu datu droŔību un izturÄ«bu pret kļūmēm.

Izvēlētie milti

Projektā ar admin paneli izvēle notika Ŕādi: vispirms uzstādÄ«jām Hazelcast, jo Mēs jau bijām pazÄ«stami ar Å”o produktu no galvenās vietnes pieredzes. Bet Å”eit Ŕī izvēle izrādÄ«jās neveiksmÄ«ga - zem mÅ«su slodzes profila Hazelcast ir ne tikai lēns, bet gan Å”ausmÄ«gi lēns. Un tajā laikā mēs jau bijām pierakstÄ«juÅ”ies uz izlaiÅ”anas datumu.

Spoileris: kā tieÅ”i attÄ«stÄ«jās apstākļi, ka mēs palaidām garām tik lielu darÄ«jumu un nonācām pie akÅ«tu un saspringtu situāciju - pastāstÄ«Å”u otrajā daļā - un kā mēs nonācām un kā tikām ārā. Bet tagad - es tikai teikÅ”u, ka tas bija liels stress, un "domāt - es kaut kā nevaru domāt, mēs kratām pudeli." ā€œPudeles kratÄ«Å”anaā€ ir arÄ« spoileris, vairāk par to vēlāk.

Ko mēs darījām:

  1. Mēs izveidojam visu Google un StackOverflow ieteikto sistēmu sarakstu. Nedaudz virs 30
  2. Rakstām testus ar ražoÅ”anai raksturÄ«gu slodzi. Lai to izdarÄ«tu, mēs ierakstÄ«jām datus, kas iet cauri sistēmai ražoÅ”anas vidē - sava veida sniffer par datiem nevis tÄ«klā, bet gan sistēmas iekÅ”ienē. TieÅ”i Å”ie dati tika izmantoti testos.
  3. Ar visu komandu katrs no saraksta izvēlas nākamo sistēmu, konfigurē to un veic testus. Tas neiztur pārbaudi, nenes slodzi - mēs to izmetam un pārejam pie nākamās rindā.
  4. 17. sistēmā kļuva skaidrs, ka viss ir bezcerīgi. Beidz kratīt pudeli, laiks nopietni padomāt.

Bet Ŕī ir iespēja, ja jums ir jāizvēlas sistēma, kas "pārvarēs" iepriekÅ” sagatavotos testos. Ko darÄ«t, ja Ŕādu testu vēl nav un vēlaties ātri izvēlēties?

Modelēsim Å”o variantu (grÅ«ti iedomāties, ka vidējais+ izstrādātājs dzÄ«vo vakuumā un atlases brÄ«dÄ« vēl nav formalizējis savu izvēli par to, kuru produktu izmēģināt vispirms - tāpēc tālākā sprieÅ”ana ir vairāk teorētiÄ·is/filozofija/ par junioru).

IzlēmuÅ”i par prasÄ«bām, mēs sāksim izvēlēties risinājumu. Kāpēc no jauna izgudrot riteni: mēs iesim un paņemsim gatavu keÅ”atmiņas sistēmu.

Ja vēl tikai iesāc un googlē, tad dod vai pieņem pasÅ«tÄ«jumu, bet kopumā vadlÄ«nijas bÅ«s Ŕādas. Pirmkārt, jÅ«s sastapsiet ar Redisu, tas ir dzirdams visur. Tad jÅ«s uzzināsit, ka EhCache ir vecākā un pārbaudÄ«tākā sistēma. Tālāk mēs rakstÄ«sim par Tarantool ā€” vietējo izstrādi, kurai ir unikāls risinājuma aspekts. Un arÄ« Ignite, jo tas tagad ir populārs un bauda SberTech atbalstu. Beigās ir arÄ« Hazelcast, jo uzņēmumu pasaulē tas bieži parādās lielo uzņēmumu vidÅ«.

Saraksts nav pilnÄ«gs, ir vairāki desmiti sistēmu. Un mēs izjauksim tikai vienu lietu. Ņemsim ā€œskaistuma konkursamā€ atlasÄ«tās 5 sistēmas un veiksim atlasi. KurÅ” bÅ«s uzvarētājs?

Redis

Mēs lasām, ko viņi raksta oficiālajā vietnē.
Redis - atvērtā koda projekts. Piedāvā datu glabāŔanu atmiņā, iespēju saglabāt datus diskā, automātisko sadalÄ«Å”anu, augstu pieejamÄ«bu un atkopÅ”anu pēc tÄ«kla pārtraukumiem.

Šķiet, ka viss ir kārtībā, var ņemt un pieskrūvēt - visu, ko vajag, dara. Bet prieka pēc apskatīsim citus kandidātus.

EhCache

EhCache - ā€œVisplaŔāk izmantotā Java keÅ”atmiņaā€ (saukļa tulkojums no oficiālās vietnes). ArÄ« atvērtā koda. Un tad mēs saprotam, ka Redis nav paredzēts java, bet gan vispārējs, un, lai ar to mijiedarbotos, ir nepiecieÅ”ams iesaiņojums. Un EhCache bÅ«s ērtāk. Ko vēl sistēma sola? UzticamÄ«ba, pārbaudÄ«ta, pilna funkcionalitāte. Nu, tas ir arÄ« visizplatÄ«tākais. Un keÅ”atmiņā saglabā terabaitus datu.

Redis ir aizmirsts, esmu gatavs izvēlēties EhCache.

Bet patriotisma izjūta liek man redzēt, kas ir labs Tarantoolā.

Tarantool

Tarantool - atbilst apzÄ«mējumam ā€œReāllaika datu integrācijas platformaā€. Tas izklausās ļoti sarežģīti, tāpēc mēs detalizēti izlasām lapu un atrodam skaļu paziņojumu: "KeÅ”atmiņā tiek saglabāti 100% RAM." Tam vajadzētu radÄ«t jautājumus - galu galā datu var bÅ«t daudz vairāk nekā atmiņas. Izskaidrojums ir tāds, ka tas nozÄ«mē, ka Tarantool neveic serializāciju, lai ierakstÄ«tu datus diskā no atmiņas. Tā vietā tiek izmantotas zema lÄ«meņa sistēmas funkcijas, kad atmiņa ir vienkārÅ”i kartēta uz failu sistēmu ar ļoti labu I/O veiktspēju. Kopumā viņi izdarÄ«ja kaut ko brÄ«niŔķīgu un forÅ”u.

Apskatīsim ievieŔanas veidus: Mail.ru korporatīvā Ŕoseja, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...

Ja joprojām bija kādas Ŕaubas par Tarantool, tad Mastercard ievieŔanas gadījums mani piebeidz. Es lietoju Tarantool.

Bet vienalgaā€¦

Aizdedzināt

ā€¦ vai ir vēl daži Aizdedzināt, tiek maksāts kā "atmiņā esoÅ”a skaitļoÅ”anas platforma... atmiņas ātrums uz datu petabaitiem". Å eit ir arÄ« daudz priekÅ”rocÄ«bu: sadalÄ«ta keÅ”atmiņa atmiņā, ātrākā atslēgu vērtÄ«bu krātuve un keÅ”atmiņa, horizontālā mērogoÅ”ana, augsta pieejamÄ«ba, stingra integritāte. Kopumā sanāk, ka ātrākais ir Ignite.

ÄŖstenojumi: Sberbank, American Airlines, Yahoo! Japāna. Un tad es uzzinu, ka Ignite nav tikai ieviests Sberbankā, bet SberTech komanda sÅ«ta savus cilvēkus uz Ignite komandu, lai uzlabotu produktu. Tas ir pilnÄ«bā valdzinoÅ”s, un es esmu gatavs uzņemties Ignite.

Pilnīgi nav skaidrs, kāpēc, es skatos uz piekto punktu.

lazdu lējums

Es dodos uz vietni lazdu lējums, lasÄ«Å”ana. Un izrādās, ka ātrākais risinājums izplatÄ«tajai keÅ”atmiņai ir Hazelcast. Tas ir vairākas reizes ātrāks par visiem citiem risinājumiem, un kopumā tas ir lÄ«deris atmiņas datu režģa jomā. Uz Ŕī fona ņemt kaut ko citu nozÄ«mē necienÄ«t sevi. Tas izmanto arÄ« lieku datu krātuvi nepārtrauktai klastera darbÄ«bai bez datu zuduma.

Tas ir viss, esmu gatavs uzņemt Hazelcast.

Salīdzinājums

Bet, ja paskatās, visi pieci kandidāti ir aprakstÄ«ti tā, ka katrs no viņiem ir labākais. Kā izvēlēties? Mēs varam redzēt, kurÅ” no tiem ir populārākais, meklēt salÄ«dzinājumus, un galvassāpes pāries.

Mēs atrodam vienu Ŕādu pārskats, izvēlieties mÅ«su 5 sistēmas.

Kā mēs Sportmaster izvēlējāmies keÅ”atmiņas sistēmu. 1. daļa

Å eit tie ir sakārtoti: Redis ir augÅ”pusē, Hazelcast ir otrajā vietā, Tarantool un Ignite gÅ«st popularitāti, EhCache ir bijis un paliek nemainÄ«gs.

Bet paskatÄ«simies aprēķina metode: saites uz tÄ«mekļa vietnēm, vispārēja interese par sistēmu, darba piedāvājumi - lieliski! Tas ir, kad mana sistēma neizdodas, es teikÅ”u: ā€œNē, tā ir uzticama! Ir daudz darba piedāvājumu..." Tik vienkārÅ”s salÄ«dzinājums nederēs.

Visas Ŕīs sistēmas nav tikai keÅ”atmiņas sistēmas. Tiem ir arÄ« daudz funkcionalitātes, tostarp, ja dati netiek sÅ«knēti klientam apstrādei, bet otrādi: kods, kas jāizpilda uz datiem, pārvietojas uz serveri, tiek izpildÄ«ts tur, un rezultāts tiek atgriezts. Un tos tik bieži neuzskata par atseviŔķu keÅ”atmiņas sistēmu.

Labi, nepadosimies, atradÄ«sim tieÅ”u sistēmu salÄ«dzinājumu. Ņemsim divas galvenās iespējas - Redis un Hazelcast. MÅ«s interesē ātrums, un mēs tos salÄ«dzināsim, pamatojoties uz Å”o parametru.

Hz vs Redis

Mēs atrodam Å”o salÄ«dzinājums:
Kā mēs Sportmaster izvēlējāmies keÅ”atmiņas sistēmu. 1. daļa

Zils ir Redis, sarkans ir Hazelcast. Hazelcast uzvar visur, un tam ir pamatojums: tas ir daudzpavedienu, ļoti optimizēts, katrs pavediens darbojas ar savu nodalÄ«jumu, tāpēc nav bloÄ·Ä“Å”anas. Un Redis ir viena vÄ«tne; tas negÅ«st labumu no mÅ«sdienu daudzkodolu centrālajiem procesoriem. Hazelcast ir asinhronā I/O, Redis-Jedis ir bloÄ·Ä“Å”anas ligzdas. Galu galā Hazelcast izmanto bināro protokolu, un Redis ir orientēts uz tekstu, kas nozÄ«mē, ka tas ir neefektÄ«vs.

Katram gadÄ«jumam pievērsÄ«simies citam salÄ«dzināŔanas avotam. Ko viņŔ mums parādÄ«s?

Redis pret Hz

Vēl vienu salīdzinājums:
Kā mēs Sportmaster izvēlējāmies keÅ”atmiņas sistēmu. 1. daļa

Å eit, gluži pretēji, sarkans ir Redis. Tas nozÄ«mē, ka Redis veiktspējas ziņā pārspēj Hazelcast. Pirmajā salÄ«dzināŔanā uzvarēja Hezelkass, otrajā ā€“ Redis. TieÅ”i Å”eit ļoti precÄ«zi paskaidroja, kāpēc Hazelcast uzvarēja iepriekŔējā salÄ«dzinājumā.

Izrādās, ka pirmā rezultāts faktiski tika viltots: Redis tika uzņemts bāzes kastē, un Hazelcast tika pielāgots testa gadījumam. Tad izrādās: pirmkārt, mēs nevaram nevienam uzticēties, un, otrkārt, beidzot izvēloties sistēmu, mums tā joprojām ir pareizi jākonfigurē. Šie iestatījumi ietver desmitiem, gandrīz simtiem parametru.

Kratot pudeli

Un es varu izskaidrot visu procesu, ko mēs tagad esam paveikuÅ”i, izmantojot Ŕādu metaforu: ā€œPudeles kratÄ«Å”anaā€. Tas ir, tagad jums nav jāprogrammē, tagad galvenais ir prast nolasÄ«t stackoverflow. Un manā komandā ir cilvēks, profesionālis, kurÅ” kritiskos brīžos strādā tieÅ”i Ŕādi.

Ko viņŔ dara? ViņŔ redz saplÄ«suÅ”u lietu, redz steka pēdas, paņem no tās dažus vārdus (kuriem ir viņa zināŔanas programmā), meklē Google, starp atbildēm atrod stackoverflow. Nelasot, nedomājot, viņŔ starp jautājuma atbildēm izvēlas kaut ko lÄ«dzÄ«gāku teikumam ā€œdari to un toā€ (izvēlēties Ŕādu atbildi ir viņa talants, jo ne vienmēr atbilde saņēma visvairāk atzÄ«mju), attiecas , izskatās: ja kaut kas ir mainÄ«jies, tad lieliski. Ja tas nav mainÄ«jies, atgrieziet to atpakaļ. Un atkārtojiet palaiÅ”anu-pārbaudi-meklÄ“Å”anu. Un Ŕādā intuitÄ«vā veidā viņŔ nodroÅ”ina, ka kods darbosies pēc kāda laika. ViņŔ nezina, kāpēc, viņŔ nezina, ko viņŔ izdarÄ«ja, viņŔ nevar izskaidrot. Bet! Å Ä« infekcija darbojas. Un "uguns ir nodzēsta". Tagad izdomāsim, ko mēs izdarÄ«jām. Kad programma darbojas, tas ir daudz vieglāk. Un tas ietaupa daudz laika.

Å Ä« metode ir ļoti labi izskaidrota ar Å”o piemēru.

Kādreiz bija ļoti populāri savākt buru laivu pudelē. Tajā paŔā laikā buru laiva ir liela un trausla, un pudeles kakls ir ļoti Å”aurs, to nav iespējams iestumt iekŔā. Kā to salikt?

Kā mēs Sportmaster izvēlējāmies keÅ”atmiņas sistēmu. 1. daļa

Ir tāda metode, ļoti ātra un ļoti efektīva.

Kuģis sastāv no sīkumiem: nūjām, virvēm, burām, līmes. To visu liekam pudelē.
Paņemam pudeli ar abām rokām un sākam kratīt. Mēs viņu kratām un kratām. Un parasti tas, protams, izrādās pilnīgs atkritums. Bet dažreiz. Dažreiz izrādās, ka tas ir kuģis! Precīzāk, kaut kas līdzīgs kuģim.

Mēs kādam parādām Å”o: "Seryoga, vai redzi!?" Un tieŔām, no tālienes tas izskatās pēc kuÄ£a. Taču tā nevar turpināties.

Ir arÄ« cits veids. Tos izmanto pieredzējuŔāki puiÅ”i, piemēram, hakeri.

Iedevu Å”im puisim uzdevumu, viņŔ visu izdarÄ«ja un aizgāja. Un jÅ«s skatāties - izskatās, ka tas ir izdarÄ«ts. Un pēc kāda laika, kad kods jānoformē, tas sākas viņa dēļ... Labi, ka viņŔ jau paguvis aizbēgt tālu prom. Tie ir puiÅ”i, kuri, izmantojot pudeles piemēru, darÄ«s tā: redz, kur ir dibens, stikls liecas. Un nav lÄ«dz galam skaidrs, vai tas ir caurspÄ«dÄ«gs vai nē. Tad ā€œhakeriā€ nogriež Å”o dibenu, ievieto tur kuÄ£i, pēc tam atkal pielÄ«mē dibenu, un Ŕķiet, ka tā tam ir jābÅ«t.

No problēmas noteikÅ”anas viedokļa viss Ŕķiet pareizi. Bet izmantojot kuÄ£us kā piemēru: kāpēc vispār taisÄ«t Å”o kuÄ£i, kam tas vispār vajadzÄ«gs? Tas nenodroÅ”ina nekādu funkcionalitāti. Parasti Ŕādi kuÄ£i ir dāvanas ļoti augsta ranga cilvēkiem, kuri to noliek uz plaukta virs sevis, kā kaut kādu simbolu, kā zÄ«mi. Un, ja Ŕāds cilvēks, liela uzņēmuma vadÄ«tājs vai augsta amatpersona, kā karodziņŔ stāvēs uz tādu kapāŔanu, kam nogriezts kakls? BÅ«tu labāk, ja viņŔ par to nekad nezinātu. Tātad, kā viņi galu galā izgatavo Å”os kuÄ£us, kurus var uzdāvināt svarÄ«gai personai?

VienÄ«gā galvenā vieta, kur jÅ«s tieŔām neko nevarat darÄ«t, ir Ä·ermenis. Un kuÄ£a korpuss iekļaujas tieÅ”i kaklā. Tā kā kuÄ£is ir samontēts ārpus pudeles. Taču tā nav tikai kuÄ£a salikÅ”ana, tā ir Ä«sta juvelierizstrādājumu amatniecÄ«ba. Detaļām tiek pievienotas Ä«paÅ”as sviras, kas pēc tam ļauj tās pacelt. Piemēram, buras tiek salocÄ«tas, rÅ«pÄ«gi ienestas iekŔā un pēc tam ar pincetes palÄ«dzÄ«bu ļoti precÄ«zi, ar precizitāti tiek vilktas un paceltas. Rezultāts ir mākslas darbs, ko var apdāvināt ar tÄ«ru sirdsapziņu un lepnumu.

Un, ja mēs vēlamies, lai projekts bÅ«tu veiksmÄ«gs, komandā jābÅ«t vismaz vienam juvelierim. Tāds, kuram rÅ«p preces kvalitāte un ņem vērā visus aspektus, neko neupurējot, pat stresa brīžos, kad apstākļi liek darÄ«t steidzamo uz svarÄ«gā rēķina. Visi veiksmÄ«gie projekti, kas ir ilgtspējÄ«gi, kas ir izturējuÅ”i laika pārbaudi, ir veidoti uz Ŕī principa. Tajos ir kaut kas ļoti precÄ«zs un unikāls, kaut kas tāds, kas izmanto visas pieejamās iespējas. Piemērā ar kuÄ£i pudelē tiek apspēlēts fakts, ka kuÄ£a korpuss iet caur kaklu.

Atgriežoties pie uzdevuma izvēlēties mÅ«su keÅ”atmiņas serveri, kā varētu izmantot Å”o metodi? Piedāvāju Å”o iespēju izvēlēties no visām esoÅ”ajām sistēmām - nekratiet pudeli, neizvēlaties, bet paskatieties, kas tām principā ir, ko meklēt, izvēloties sistēmu.

Kur meklēt pudeles kaklu

Mēģināsim nekratÄ«t pudeli, neiziet cauri visam, kas tur ir pa vienam, bet paskatÄ«simies, kādas problēmas radÄ«sies, ja pēkŔņi savam uzdevumam paÅ”i konstruēsim Ŕādu sistēmu. Protams, mēs velosipēdu nesaliksim, taču izmantosim Å”o diagrammu, lai saprastu, kuriem punktiem jāpievērÅ” uzmanÄ«ba produktu aprakstos. Ieskicēsim Ŕādu diagrammu.

Kā mēs Sportmaster izvēlējāmies keÅ”atmiņas sistēmu. 1. daļa

Ja sistēma ir izplatÄ«ta, tad mums bÅ«s vairāki serveri (6). Pieņemsim, ka ir četri (ir ērti tos ievietot attēlā, bet, protams, to var bÅ«t tik daudz, cik vēlaties). Ja serveri atrodas dažādos mezglos, tas nozÄ«mē, ka tie visi palaiž kādu kodu, kas ir atbildÄ«gs par to, lai Å”ie mezgli izveidotu kopu un pārtraukuma gadÄ«jumā izveidotu savienojumu un atpazÄ«tu viens otru.

Mums ir nepiecieÅ”ama arÄ« koda loÄ£ika (2), kas faktiski ir saistÄ«ta ar keÅ”atmiņu. Klienti mijiedarbojas ar Å”o kodu, izmantojot kādu API. Klienta kods (1) var atrasties tajā paŔā JVM vai piekļūt tam tÄ«klā. IekÅ”pusē Ä«stenotā loÄ£ika ir lēmums par to, kurus objektus atstāt keÅ”atmiņā un kurus izmest. Mēs izmantojam atmiņu (3), lai saglabātu keÅ”atmiņu, bet, ja nepiecieÅ”ams, mēs varam saglabāt daļu datu diskā (4).

ApskatÄ«sim, kurās daļās notiks slodze. Faktiski tiks ielādēta katra bultiņa un katrs mezgls. Pirmkārt, starp klienta kodu un api, ja tā ir tÄ«kla komunikācija, kritums var bÅ«t diezgan pamanāms. Otrkārt, paÅ”a api ietvaros - ja mēs pārspÄ«lējam ar sarežģītu loÄ£iku, mēs varam saskarties ar problēmām ar centrālo procesoru. Un bÅ«tu jauki, ja loÄ£ika netērētu laiku atmiņai. Un paliek mijiedarbÄ«ba ar failu sistēmu - parastajā versijā tas ir serializÄ“Å”ana / atjaunoÅ”ana un rakstÄ«Å”ana / lasÄ«Å”ana.

Nākamā ir mijiedarbÄ«ba ar kopu. Visticamāk, tas bÅ«s tajā paŔā sistēmā, bet tas varētu bÅ«t atseviŔķi. Å eit jāņem vērā arÄ« datu pārsÅ«tÄ«Å”ana uz to, datu serializācijas ātrums un mijiedarbÄ«ba starp klasteru.

Tagad, no vienas puses, mēs varam iedomāties, "kādi zobrati griezÄ«sies" keÅ”atmiņas sistēmā, apstrādājot pieprasÄ«jumus no mÅ«su koda, un, no otras puses, mēs varam novērtēt, kādus un cik pieprasÄ«jumus mÅ«su kods Ä£enerēs Å”ai sistēmai. Tas ir pietiekami, lai izdarÄ«tu vairāk vai mazāk prātÄ«gu izvēli - lai izvēlētos sistēmu mÅ«su lietoÅ”anas gadÄ«jumam.

lazdu lējums

ApskatÄ«sim, kā piemērot Å”o sadalÄ«jumu mÅ«su sarakstam. Piemēram, Hazelcast.

Lai ievietotu/paņemtu datus no Hazelcast, klienta kods piekļūst (1) API. Hz ļauj palaist serveri kā iegultu, un Å”ajā gadÄ«jumā piekļuve api ir metodes izsaukums JVM iekÅ”ienē, ko var uzskatÄ«t par bezmaksas.

Lai (2) loÄ£ika darbotos, Hz paļaujas uz serializētās atslēgas baitu masÄ«va jaukÅ”anu - tas ir, atslēga tiks serializēta jebkurā gadÄ«jumā. Tas ir neizbēgami pieskaitāmi Hz.
IzlikÅ”anas stratēģijas tiek Ä«stenotas labi, bet Ä«paÅ”iem gadÄ«jumiem varat pievienot savu. Jums nav jāuztraucas par Å”o daļu.

Var pievienot krātuvi (4). Lieliski. MijiedarbÄ«ba (5) iegultai var tikt uzskatÄ«ta par tÅ«lÄ«tēju. Datu apmaiņa starp mezgliem klasterÄ« (6) - jā, tā pastāv. Tas ir ieguldÄ«jums kļūdu tolerancē uz ātruma rēķina. Hz funkcija Near-cache ļauj samazināt cenu ā€“ dati, kas saņemti no citiem klastera mezgliem, tiks saglabāti keÅ”atmiņā.

Ko Ŕādos apstākļos var darīt, lai palielinātu ātrumu?

Piemēram, lai izvairÄ«tos no (2) atslēgas serializācijas, pievienojiet citu keÅ”atmiņu Hazelcast augÅ”pusē, lai iegÅ«tu karstākos datus. Å im nolÅ«kam Sportmaster izvēlējās Caffeine.

Lai pagrieztu 6. lÄ«menÄ«, Hz piedāvā divu veidu krātuves: IMap un ReplicatedMap.
Kā mēs Sportmaster izvēlējāmies keÅ”atmiņas sistēmu. 1. daļa

Ir vērts pieminēt, kā Hazelcast nokļuva Sportmaster tehnoloģiju kaudzē.

2012. gadā, kad strādājām pie paÅ”a pirmā topoŔās vietnes izmēģinājuma versijas, tieÅ”i Hazelcast izrādÄ«jās pirmā saite, ko meklētājprogramma atgrieza. IepazÄ«Å”anās sākās ā€œpirmo reiziā€ ā€“ mÅ«s aizrāva fakts, ka tikai pēc divām stundām, kad sistēmā ieskrÅ«vējām Hz, tā nostrādāja. Un tas darbojās labi. LÄ«dz dienas beigām mēs bijām pabeiguÅ”i vairākus testus un bijām apmierināti. Un ar Å”o spara rezervi pietika, lai pārvarētu pārsteigumus, ko laika gaitā sagādāja Hz. Tagad Sportmaster komandai nav pamata pamest Hezelkastu.

Bet tādi argumenti kā ā€œpirmā saite meklētājāā€ un ā€œHelloWorld tika ātri samontētiā€, protams, ir izņēmums un izvēles brīža iezÄ«me. Reālie izvēlētās sistēmas testi sākas ar izlaiÅ”anu ražoÅ”anā, un tieÅ”i Å”ajā posmā jums jāpievērÅ” uzmanÄ«ba, izvēloties jebkuru sistēmu, ieskaitot keÅ”atmiņu. PatiesÄ«bā mÅ«su gadÄ«jumā varam teikt, ka Hazelcast izvēlējāmies nejauÅ”i, bet tad izrādÄ«jās, ka izvēlējāmies pareizi.

RažoÅ”anai daudz svarÄ«gāk: uzraudzÄ«ba, atseviŔķu mezglu kļūdu apstrāde, datu replikācija, mērogoÅ”anas izmaksas. Tas ir, ir vērts pievērst uzmanÄ«bu uzdevumiem, kas radÄ«sies sistēmas uzturÄ“Å”anas laikā - kad slodze ir desmitiem reižu lielāka nekā plānots, kad mēs nejauÅ”i augÅ”upielādējam kaut ko nepareizā vietā, kad mums ir nepiecieÅ”ams izrullēt jaunu versiju kodu, nomainiet datus un dariet to klientiem nepamanÄ«ti.

Visām Ŕīm prasÄ«bām Hazelcast noteikti atbilst rēķinam.

Turpinājums sekos

Bet Hazelcast nav panaceja. 2017. gadā mēs izvēlējāmies Hazelcast administratora keÅ”atmiņai, vienkārÅ”i pamatojoties uz labiem iespaidiem no iepriekŔējās pieredzes. Tam bija galvenā loma ļoti nežēlÄ«gā jokā, kura dēļ mēs nonācām sarežģītā situācijā un ā€œvaronÄ«giā€ no tās izgājām uz 60 dienām. Bet vairāk par to nākamajā daļā.

Tikmēr... Laimīgu jauno kodeksu!

Avots: www.habr.com

Pievieno komentāru