Kamusta! Ang pangalan ko ay Alexey Pyankov, isa akong developer sa kumpanya ng Sportmaster. Sa ganyan Sinabi ko kung paano nagsimula ang trabaho sa website ng Sportmaster noong 2012, anong mga inisyatiba ang nagawa naming "push through" at vice versa, anong rake ang nakolekta namin.
Ngayon gusto kong magbahagi ng mga saloobin na sumusunod sa isa pang paksa - pagpili ng isang caching system para sa java backend sa admin panel ng site. Ang balangkas na ito ay may espesyal na kahulugan para sa akin - bagama't ang kuwento ay nagbukas lamang ng 2 buwan, sa loob ng 60 araw na ito ay nagtrabaho kami ng 12-16 na oras at walang isang araw na pahinga. Hindi ko naisip o naisip na posible na magtrabaho nang husto.
Samakatuwid, hinati ko ang teksto sa 2 bahagi upang hindi ito ganap na mai-load. Sa kabaligtaran, ang unang bahagi ay magiging napakagaan - paghahanda, pagpapakilala, ilang mga pagsasaalang-alang tungkol sa kung ano ang caching. Kung isa ka nang makaranasang developer o nagtrabaho sa mga cache, mula sa teknikal na bahagi ay malamang na walang bago sa artikulong ito. Ngunit para sa isang junior, ang isang maliit na pagsusuri ay maaaring sabihin sa kanya kung aling direksyon ang titingnan kung nahanap niya ang kanyang sarili sa isang sangang-daan.
Kapag ang bagong bersyon ng website ng Sportmaster ay inilagay sa produksyon, ang data ay natanggap sa paraang, sa madaling salita, hindi masyadong maginhawa. Ang batayan ay ang mga talahanayan na inihanda para sa nakaraang bersyon ng site (Bitrix), na kailangang i-pull sa ETL, dinala sa isang bagong anyo at pinayaman ng iba't ibang maliliit na bagay mula sa isang dosenang higit pang mga sistema. Upang lumitaw ang isang bagong larawan o paglalarawan ng produkto sa site, kailangan mong maghintay hanggang sa susunod na araw - mga update lamang sa gabi, isang beses sa isang araw.
Sa una, napakaraming alalahanin mula sa mga unang linggo ng pagpasok sa produksyon na ang gayong mga abala para sa mga tagapamahala ng nilalaman ay isang maliit na bagay. Ngunit, sa sandaling maayos ang lahat, nagpatuloy ang pagbuo ng proyekto - pagkalipas ng ilang buwan, sa simula ng 2015, nagsimula kaming aktibong bumuo ng admin panel. Sa 2015 at 2016, maayos ang lahat, regular kaming naglalabas, sinasaklaw ng admin panel ang higit pa at higit pa sa paghahanda ng data, at naghahanda kami para sa katotohanan na sa lalong madaling panahon ang aming koponan ay ipagkatiwala sa pinakamahalaga at kumplikadong bagay - ang produkto circuit (buong paghahanda at pagpapanatili ng data sa lahat ng mga produkto). Ngunit sa tag-araw ng 2017, bago ang paglunsad ng commodity circuit, ang proyekto ay mahahanap ang sarili sa isang napakahirap na sitwasyon - tiyak dahil sa mga problema sa pag-cache. Gusto kong pag-usapan ang episode na ito sa ikalawang bahagi ng dalawang-bahaging publikasyong ito.
Ngunit sa post na ito magsisimula ako mula sa malayo, magpapakita ako ng ilang mga saloobin - mga ideya tungkol sa pag-cache, na magiging isang magandang hakbang upang mag-scroll bago ang isang malaking proyekto.
Kapag naganap ang isang gawain sa pag-cache
Ang gawain sa pag-cache ay hindi lamang lilitaw. Kami ay mga developer, sumusulat ng isang software na produkto at gusto itong maging in demand. Kung ang produkto ay in demand at matagumpay, ang mga gumagamit ay darating. At parami nang parami ang dumating. At pagkatapos ay mayroong maraming mga gumagamit at pagkatapos ay ang produkto ay nagiging napaka-load.
Sa mga unang yugto, hindi namin iniisip ang tungkol sa pag-optimize at pagganap ng code. Ang pangunahing bagay ay ang pag-andar, mabilis na ilunsad ang isang piloto at pagsubok ng mga hypotheses. At kung tumaas ang load, i-pump up namin ang bakal. Dinadagdagan natin ito ng dalawa o tatlong beses, limang beses, marahil 10 beses. Sa isang lugar dito - hindi na ito papayagan ng pananalapi. Ilang beses tataas ang bilang ng mga gumagamit? Hindi ito magiging tulad ng 2-5-10, ngunit kung matagumpay, ito ay mula 100-1000 hanggang 100 libong beses. Iyon ay, maaga o huli, kailangan mong gawin ang pag-optimize.
Sabihin natin na ang ilang bahagi ng code (tawagin natin ang bahaging ito na isang function) ay tumatagal ng napakahabang panahon, at gusto nating bawasan ang oras ng pagpapatupad. Ang isang function ay maaaring maging access sa isang database, o maaaring ito ay ang pagpapatupad ng ilang kumplikadong lohika - ang pangunahing bagay ay na ito ay tumatagal ng mahabang panahon upang maisakatuparan. Magkano ang maaari mong bawasan ang oras ng pagpapatupad? Sa limitasyon, maaari mo itong bawasan sa zero, wala nang hihigit pa. Paano mo mababawasan ang oras ng pagpapatupad sa zero? Sagot: ganap na alisin ang pagpapatupad. Sa halip, ibalik kaagad ang resulta. Paano mo malalaman ang resulta? Sagot: maaaring kalkulahin ito o tumingin sa isang lugar. Ito ay tumatagal ng mahabang panahon upang makalkula. At ang pag-espiya ay, halimbawa, upang matandaan ang resulta na ginawa ng function sa huling pagkakataon kapag tinawag na may parehong mga parameter.
Ibig sabihin, hindi mahalaga sa amin ang pagpapatupad ng function. Ito ay sapat na upang malaman kung anong mga parameter ang nakasalalay sa resulta. Pagkatapos, kung ang mga halaga ng parameter ay kinakatawan sa anyo ng isang bagay na maaaring magamit bilang isang susi sa ilang imbakan, kung gayon ang resulta ng pagkalkula ay maaaring i-save at basahin sa susunod na ma-access ito. Kung ang pagsusulat at pagbabasa ng resulta na ito ay mas mabilis kaysa sa pagpapatupad ng function, mayroon tayong tubo sa mga tuntunin ng bilis. Ang halaga ng kita ay maaaring umabot ng 100, 1000, at 100 beses (10^5 ay sa halip isang pagbubukod, ngunit sa kaso ng isang medyo lagging base, ito ay lubos na posible).
Mga pangunahing kinakailangan para sa isang sistema ng pag-cache
Ang unang bagay na maaaring maging kinakailangan para sa isang sistema ng pag-cache ay mabilis na bilis ng pagbasa at, sa bahagyang mas mababang lawak, bilis ng pagsulat. Totoo ito, ngunit hanggang sa ilunsad natin ang sistema sa produksyon.
Laruin natin ang kasong ito.
Sabihin nating naibigay namin ang kasalukuyang load na may hardware at ngayon ay unti-unti nang nagpapakilala ng caching. Ang bilang ng mga gumagamit ay lumalaki nang kaunti, ang pag-load ay lumalaki - nagdaragdag kami ng kaunting mga cache, i-screw ito dito at doon. Ito ay nagpapatuloy sa loob ng ilang panahon, at ngayon ang mabibigat na pag-andar ay halos hindi na tinatawag - ang buong pangunahing pag-load ay nahuhulog sa cache. Ang bilang ng mga user sa panahong ito ay tumaas ng N beses.
At kung ang paunang supply ng hardware ay maaaring 2-5 beses, pagkatapos ay sa tulong ng cache maaari naming mapabuti ang pagganap sa pamamagitan ng isang kadahilanan ng 10 o, sa isang magandang kaso, sa pamamagitan ng isang kadahilanan ng 100, sa ilang mga lugar marahil sa pamamagitan ng isang kadahilanan ng 1000. Iyon ay, sa parehong hardware - pinoproseso namin ang 100 beses na higit pang mga kahilingan. Mahusay, karapat-dapat ka sa gingerbread!
Ngunit ngayon, sa isang magandang sandali, nagkataon, nag-crash ang system at bumagsak ang cache. Walang espesyal - pagkatapos ng lahat, ang cache ay pinili batay sa kinakailangan na "mataas na bilis ng pagbasa at pagsulat, ang iba ay hindi mahalaga."
May kaugnayan sa panimulang pagkarga, ang aming reserbang bakal ay 2-5 beses, at ang pagkarga sa panahong ito ay tumaas ng 10-100 beses. Gamit ang cache, inalis namin ang mga tawag para sa mabibigat na pag-andar at samakatuwid ay gumana ang lahat. At ngayon, nang walang cache, gaano karaming beses bumagal ang aming system? Ano ang mangyayari sa atin? Babagsak ang sistema.
Kahit na hindi nag-crash ang aming cache, ngunit na-clear lang saglit, kakailanganin itong painitin, at magtatagal ito. At sa panahong ito, ang pangunahing pasanin ay mahuhulog sa pag-andar.
Konklusyon: ang mataas na load na mga proyekto sa produksyon ay nangangailangan ng isang sistema ng pag-cache hindi lamang upang magkaroon ng mataas na bilis ng pagbasa at pagsulat, kundi pati na rin upang matiyak ang kaligtasan ng data at paglaban sa mga pagkabigo.
Flour of choice
Sa isang proyekto na may admin panel, ang pagpipilian ay naging ganito: una naming na-install ang Hazelcast, dahil Pamilyar na kami sa produktong ito mula sa karanasan ng pangunahing site. Ngunit narito ang pagpipiliang ito ay naging hindi matagumpay - sa ilalim ng aming profile sa pag-load, ang Hazelcast ay hindi lamang mabagal, ngunit napakabagal. At sa oras na iyon ay nag-sign up na kami para sa petsa ng paglabas.
Spoiler: kung paano eksaktong nabuo ang mga pangyayari na napalampas namin ang napakalaking bagay at nauwi sa isang talamak at tense na sitwasyon - sasabihin ko sa iyo sa ikalawang bahagi - at kung paano tayo napunta at kung paano tayo nakalabas. Pero ngayon - sasabihin ko na lang na sobrang stress iyon, at "to think - somehow I can't think, we're shaking the bottle." Ang "pag-alog ng bote" ay isang spoiler din, higit pa sa susunod.
Ang ginawa namin:
- Gumagawa kami ng listahan ng lahat ng system na iminumungkahi ng Google at StackOverflow. Medyo mahigit 30
- Nagsusulat kami ng mga pagsubok na may karaniwang pagkarga para sa produksyon. Upang gawin ito, naitala namin ang data na dumadaan sa system sa isang kapaligiran ng produksyon - isang uri ng sniffer para sa data hindi sa network, ngunit sa loob ng system. Eksakto ang data na ito ay ginamit sa mga pagsubok.
- Sa buong team, pinipili ng lahat ang susunod na system mula sa listahan, iko-configure ito, at nagpapatakbo ng mga pagsubok. Hindi ito pumasa sa pagsubok, hindi ito nagdadala ng karga - itinatapon natin ito at nagpapatuloy sa susunod na linya.
- Sa ika-17 na sistema ay naging malinaw na ang lahat ay walang pag-asa. Itigil ang pag-alog ng bote, oras na para mag-isip ng seryoso.
Ngunit ito ay isang opsyon kapag kailangan mong pumili ng isang sistema na "makalampas sa bilis" sa mga pre-prepared na pagsubok. Paano kung wala pang ganitong mga pagsubok at gusto mong pumili ng mabilis?
Imodelo natin ang opsyong ito (mahirap isipin na ang isang middle+ developer ay naninirahan sa isang vacuum, at sa oras ng pagpili ay hindi pa pormal ang kanyang kagustuhan kung aling produkto ang unang subukan - samakatuwid, ang karagdagang pangangatwiran ay higit pa sa isang teorista/pilosopiya/ tungkol sa isang junior).
Ang pagkakaroon ng pagpapasya sa mga kinakailangan, magsisimula kaming pumili ng isang solusyon sa labas ng kahon. Bakit muling likhain ang gulong: pupunta tayo at kukuha ng isang yari na sistema ng pag-cache.
Kung nagsisimula ka lang at i-google ito, pagkatapos ay ibigay o kunin ang order, ngunit sa pangkalahatan, ang mga alituntunin ay magiging ganito. Una sa lahat, makakatagpo ka ng Redis, naririnig ito kahit saan. Pagkatapos ay malalaman mo na ang EhCache ay ang pinakaluma at pinakanapatunayang sistema. Susunod na isusulat namin ang tungkol sa Tarantool, isang domestic development na may kakaibang aspeto ng solusyon. At gayundin ang Ignite, dahil ito ay tumataas na ngayon sa katanyagan at tinatamasa ang suporta ng SberTech. Sa dulo mayroon ding Hazelcast, dahil sa mundo ng negosyo madalas itong lumilitaw sa mga malalaking kumpanya.
Ang listahan ay hindi kumpleto; mayroong dose-dosenang mga sistema. At isang bagay lang ang gagawin natin. Kunin natin ang napiling 5 system para sa "paligsahan sa kagandahan" at pumili. Sino ang magwawagi?
Redis
Nabasa namin ang isinulat nila sa opisyal na website.
- proyektong opensource. Nag-aalok ng in-memory na data storage, ang kakayahang mag-save sa disk, auto-partitioning, mataas na availability at pagbawi mula sa network outages.
Mukhang maayos ang lahat, maaari mo itong kunin at i-screw - lahat ng kailangan mo, ginagawa nito. Pero katuwaan lang, tingnan natin ang ibang mga kandidato.
EhCache
- "ang pinakamalawak na ginagamit na cache para sa Java" (pagsasalin ng slogan mula sa opisyal na website). Opensource din. At pagkatapos ay naiintindihan namin na ang Redis ay hindi para sa java, ngunit pangkalahatan, at upang makipag-ugnayan dito kailangan mo ng isang wrapper. At ang EhCache ay magiging mas maginhawa. Ano pa ang ipinangako ng sistema? Pagiging maaasahan, napatunayan, buong pag-andar. Well, ito rin ang pinakakaraniwan. At nag-cache ng terabytes ng data.
Nakalimutan si Redis, handa akong pumili ng EhCache.
Ngunit ang pakiramdam ng pagiging makabayan ay nagtutulak sa akin na makita kung ano ang mabuti tungkol sa Tarantool.
Tarantool
- nakakatugon sa pagtatalaga na "Real-time na platform ng pagsasama ng data". Mukhang napakakomplikado, kaya binasa namin ang pahina nang detalyado at nakahanap kami ng isang malakas na pahayag: "Nag-cache ng 100% ng data sa RAM." Dapat itong magtaas ng mga katanungan - pagkatapos ng lahat, maaaring mayroong higit na data kaysa sa memorya. Ang paliwanag ay nangangahulugan ito na ang Tarantool ay hindi nagpapatakbo ng serialization upang magsulat ng data sa disk mula sa memorya. Sa halip, ito ay gumagamit ng mababang antas ng mga tampok ng system, kapag ang memorya ay nakamapa lamang sa isang file system na may napakahusay na pagganap ng I/O. Sa pangkalahatan, gumawa sila ng isang bagay na kahanga-hanga at cool.
Tingnan natin ang mga pagpapatupad: Mail.ru corporate highway, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Kung mayroon pa ring mga pagdududa tungkol sa Tarantool, ang kaso ng pagpapatupad sa Mastercard ay tatapusin ako. Kumuha ako ng Tarantool.
Pero kahit naβ¦
Papag-apuyin
β¦ meron pa ba , ay sinisingil bilang isang "in-memory computing platform...in-memory speeds sa petabytes ng data." Mayroon ding maraming mga pakinabang dito: ipinamahagi na in-memory cache, ang pinakamabilis na key-value storage at cache, horizontal scaling, mataas na availability, mahigpit na integridad. Sa pangkalahatan, lumalabas na ang pinakamabilis ay Ignite.
Mga Pagpapatupad: Sberbank, American Airlines, Yahoo! Hapon. At pagkatapos ay nalaman ko na ang Ignite ay hindi lamang ipinatupad sa Sberbank, ngunit ang SberTech team ay nagpapadala ng mga tao nito sa Ignite team mismo upang pinuhin ang produkto. Ito ay ganap na nakakabighani at handa akong kunin ang Ignite.
Ito ay ganap na hindi malinaw kung bakit, tinitingnan ko ang ikalimang punto.
Hazelcast
Pumunta ako sa site , nagbabasa. At lumalabas na ang pinakamabilis na solusyon para sa distributed caching ay Hazelcast. Ito ay mga order ng magnitude na mas mabilis kaysa sa lahat ng iba pang mga solusyon at sa pangkalahatan ito ay isang nangunguna sa larangan ng in-memory data grid. Laban sa background na ito, ang kumuha ng ibang bagay ay hindi ang paggalang sa iyong sarili. Gumagamit din ito ng kalabisan na imbakan ng data para sa tuluy-tuloy na operasyon ng kumpol nang walang pagkawala ng data.
Ayan, handa na akong kunin si Hazelcast.
Paghahambing
Ngunit kung titingnan mo, lahat ng limang kandidato ay inilarawan sa paraang ang bawat isa sa kanila ay ang pinakamahusay. Paano pumili? Makikita natin kung alin ang pinakasikat, maghanap ng mga paghahambing, at mawawala ang sakit ng ulo.
Nakahanap kami ng ganito , piliin ang aming 5 system.
Narito ang mga ito ay pinagsunod-sunod: Redis ay nasa tuktok, Hazelcast ay nasa pangalawang lugar, Tarantool at Ignite ay nakakakuha ng katanyagan, EhCache ay naging at nananatiling pareho.
Ngunit tingnan natin : mga link sa mga website, pangkalahatang interes sa system, mga alok ng trabaho - mahusay! Ibig sabihin, kapag nabigo ang aking sistema, sasabihin ko: "Hindi, ito ay maaasahan! Maraming job offer..." Ang gayong simpleng paghahambing ay hindi magagawa.
Ang lahat ng mga sistemang ito ay hindi lamang mga sistema ng pag-cache. Mayroon din silang maraming pag-andar, kabilang ang kapag ang data ay hindi na-pump sa kliyente para sa pagproseso, ngunit kabaligtaran: ang code na kailangang isagawa sa data ay lumipat sa server, ay isinasagawa doon, at ang resulta ay ibinalik. At hindi sila madalas na itinuturing bilang isang hiwalay na sistema para sa pag-cache.
Okay, huwag tayong sumuko, maghanap tayo ng direktang paghahambing ng mga sistema. Kunin natin ang nangungunang dalawang opsyon - Redis at Hazelcast. Interesado kami sa bilis, at ihahambing namin ang mga ito batay sa parameter na ito.
Hz kumpara sa Redis
Natagpuan namin ito :
Blue ay Redis, pula ay Hazelcast. Ang Hazelcast ay nanalo sa lahat ng dako, at may katwiran para dito: ito ay multi-threaded, lubos na na-optimize, ang bawat thread ay gumagana sa sarili nitong partition, kaya walang pagharang. At ang Redis ay single-threaded; hindi ito nakikinabang sa mga modernong multi-core na CPU. Ang Hazelcast ay may asynchronous na I/O, ang Redis-Jedis ay may mga naka-block na socket. Pagkatapos ng lahat, ang Hazelcast ay gumagamit ng binary protocol, at ang Redis ay text-centric, ibig sabihin ay hindi ito mahusay.
Kung sakali, lumiko tayo sa isa pang mapagkukunan ng paghahambing. Ano ang ipapakita niya sa atin?
Redis kumpara sa Hz
Isa pa :
Dito, sa kabaligtaran, ang pula ay Redis. Iyon ay, ang Redis ay higit na gumaganap sa Hazelcast sa mga tuntunin ng pagganap. Nanalo si Hazelcast sa unang paghahambing, nanalo si Redis sa pangalawa. ipinaliwanag nang tumpak kung bakit nanalo si Hazelcast sa nakaraang paghahambing.
Ito ay lumalabas na ang resulta ng una ay talagang na-rigged: Redis ay kinuha sa base box, at Hazelcast ay pinasadya para sa isang pagsubok na kaso. Pagkatapos ito ay lumalabas: una, hindi namin mapagkakatiwalaan ang sinuman, at pangalawa, kapag sa wakas ay pumili kami ng isang system, kailangan pa rin namin itong i-configure nang tama. Kasama sa mga setting na ito ang dose-dosenang, halos daan-daang mga parameter.
Inalog ang bote
At maaari kong ipaliwanag ang buong proseso na ginawa natin ngayon sa sumusunod na metapora: "Pag-alog ng bote." Iyon ay, ngayon hindi mo na kailangang mag-program, ngayon ang pangunahing bagay ay upang mabasa ang stackoverflow. At mayroon akong isang tao sa aking koponan, isang propesyonal, na gumagana nang eksakto tulad nito sa mga kritikal na sandali.
Ano ang ginagawa niya? Nakakakita siya ng sirang bagay, nakakakita ng stack trace, kumukuha ng ilang salita mula rito (kung alin ang kanyang kadalubhasaan sa programa), naghahanap sa Google, nakahanap ng stackoverflow sa mga sagot. Nang walang pagbabasa, nang hindi nag-iisip, kabilang sa mga sagot sa tanong, pumili siya ng isang bagay na pinakakapareho sa pangungusap na "gawin ito at iyon" (ang pagpili ng ganoong sagot ay ang kanyang talento, dahil hindi palaging ang sagot ang tumanggap ng pinakamaraming gusto), nalalapat , hitsura: kung may nagbago, pagkatapos ay mahusay. Kung hindi ito nagbago, i-roll ito pabalik. At ulitin ang launch-check-search. At sa intuitive na paraan na ito, tinitiyak niya na gumagana ang code pagkaraan ng ilang oras. Hindi niya alam kung bakit, hindi niya alam kung ano ang ginawa niya, hindi niya maipaliwanag. Ngunit! Gumagana ang impeksyong ito. At βnapatay ang apoy.β Ngayon, alamin natin kung ano ang ginawa natin. Kapag gumagana ang programa, ito ay isang order ng magnitude na mas madali. At nakakatipid ito ng maraming oras.
Ang pamamaraang ito ay napakahusay na ipinaliwanag sa halimbawang ito.
Dati ay napakapopular ang pagkolekta ng bangka sa isang bote. Kasabay nito, ang bangka ay malaki at marupok, at ang leeg ng bote ay napakakitid, imposibleng itulak ito sa loob. Paano ito i-assemble?
Mayroong ganoong paraan, napakabilis at napaka-epektibo.
Ang barko ay binubuo ng isang bungkos ng maliliit na bagay: patpat, lubid, layag, pandikit. Inilalagay namin ang lahat ng ito sa isang bote.
Kinuha namin ang bote gamit ang dalawang kamay at nagsimulang manginig. Niyugyog namin siya. At kadalasan ito ay lumalabas na kumpletong basura, siyempre. Pero minsan. Minsan ito ay nagiging isang barko! Mas tiyak, isang bagay na katulad ng isang barko.
Ipinakikita namin ito sa isang tao: "Seryoga, nakikita mo ba!?" At sa katunayan, mula sa malayo ay mukhang isang barko. Ngunit hindi ito maaaring payagang magpatuloy.
May isa pang paraan. Ginagamit sila ng mga mas advanced na tao, tulad ng mga hacker.
Binigyan ko ang taong ito ng isang gawain, ginawa niya ang lahat at umalis. At tingnan mo - mukhang tapos na. And after a while, when the code need to be finalized, this starts because of him... Buti na lang nakatakbo na siya sa malayo. Ito ang mga lalaki na, gamit ang halimbawa ng isang bote, ay gagawin ito: nakikita mo, kung saan ang ibaba ay, ang salamin ay yumuko. At hindi lubos na malinaw kung ito ay transparent o hindi. Pagkatapos ay pinutol ng mga "hacker" ang ilalim na ito, ipasok ang isang barko doon, pagkatapos ay idikit muli ang ibaba, at parang ganoon ang dapat.
Mula sa punto ng view ng pagtatakda ng problema, ang lahat ay tila tama. Ngunit ang paggamit ng mga barko bilang isang halimbawa: bakit gagawin ang barkong ito, sino pa rin ang nangangailangan nito? Hindi ito nagbibigay ng anumang functionality. Karaniwan ang gayong mga barko ay mga regalo sa napakataas na ranggo ng mga tao, na inilalagay ito sa isang istante sa itaas nila, bilang isang uri ng simbolo, bilang isang tanda. At kung ang gayong tao, ang pinuno ng isang malaking negosyo o isang mataas na opisyal, paano tatayo ang watawat para sa naturang hack, na pinutol ang leeg? Mas mabuti kung hindi na niya alam ang tungkol dito. Kaya, paano nila natatapos ang paggawa ng mga barkong ito na maaaring ibigay sa isang mahalagang tao?
Ang tanging pangunahing lugar na wala ka talagang magagawa ay ang katawan. At ang katawan ng barko ay umaangkop sa leeg. Samantalang ang barko ay naka-assemble sa labas ng bote. Ngunit ito ay hindi lamang pag-assemble ng isang barko, ito ay isang tunay na bapor ng alahas. Ang mga espesyal na lever ay idinagdag sa mga bahagi, na pagkatapos ay nagpapahintulot sa kanila na iangat. Halimbawa, ang mga layag ay nakatiklop, maingat na dinala sa loob, at pagkatapos, sa tulong ng mga sipit, sila ay hinila at itinaas nang tumpak, nang may katumpakan. Ang resulta ay isang likhang sining na maaaring bigyan ng malinis na budhi at pagmamalaki.
At kung gusto nating maging matagumpay ang proyekto, dapat mayroong kahit isang mag-aalahas sa koponan. Isang taong nagmamalasakit sa kalidad ng produkto at isinasaalang-alang ang lahat ng aspeto, nang hindi isinakripisyo ang anuman, kahit na sa mga sandali ng stress, kapag ang mga pangyayari ay nangangailangan na gawin ang kagyat sa gastos ng mahalaga. Ang lahat ng matagumpay na proyekto na napapanatiling, na tumayo sa pagsubok ng oras, ay binuo sa prinsipyong ito. Mayroong isang bagay na napaka-tumpak at kakaiba tungkol sa kanila, isang bagay na sinasamantala ang lahat ng magagamit na mga posibilidad. Sa halimbawa na may barko sa bote, ang katotohanan na ang katawan ng barko ay dumaan sa leeg ay nilalaro.
Pagbabalik sa gawain ng pagpili ng aming caching server, paano maaaring ilapat ang pamamaraang ito? Inaalok ko ang pagpipiliang ito ng pagpili mula sa lahat ng mga system na umiiral - huwag kalugin ang bote, huwag pumili, ngunit tingnan kung ano ang mayroon sila sa prinsipyo, kung ano ang hahanapin kapag pumipili ng isang sistema.
Kung saan hahanapin ang bottle-neck
Subukan nating huwag kalugin ang bote, huwag isa-isa ang lahat ng naroroon, ngunit tingnan natin kung anong mga problema ang lilitaw kung bigla nating, para sa ating gawain, ang magdidisenyo ng gayong sistema sa ating sarili. Siyempre, hindi namin i-assemble ang bike, ngunit gagamitin namin ang diagram na ito upang matulungan kaming malaman kung anong mga punto ang dapat bigyang pansin sa mga paglalarawan ng produkto. I-sketch natin ang gayong diagram.
Kung ang sistema ay ibinahagi, magkakaroon tayo ng ilang mga server (6). Sabihin nating mayroong apat (ito ay maginhawa upang ilagay ang mga ito sa larawan, ngunit, siyempre, maaaring mayroong marami sa kanila hangga't gusto mo). Kung ang mga server ay nasa iba't ibang mga node, nangangahulugan ito na lahat sila ay nagpapatakbo ng ilang code na responsable para sa pagtiyak na ang mga node na ito ay bumubuo ng isang kumpol at, sa kaganapan ng isang break, kumonekta at makilala ang isa't isa.
Kailangan din namin ng code logic (2), na talagang tungkol sa pag-cache. Nakikipag-ugnayan ang mga kliyente sa code na ito sa pamamagitan ng ilang API. Ang code ng kliyente (1) ay maaaring nasa loob ng parehong JVM o i-access ito sa network. Ang lohika na ipinatupad sa loob ay ang desisyon kung aling mga bagay ang iiwan sa cache at kung alin ang itatapon. Gumagamit kami ng memorya (3) upang iimbak ang cache, ngunit kung kinakailangan, maaari naming i-save ang ilan sa mga data sa disk (4).
Tingnan natin kung saang bahagi magaganap ang pagkarga. Sa totoo lang, ilo-load ang bawat arrow at bawat node. Una, sa pagitan ng client code at ng api, kung ito ay komunikasyon sa network, ang paghupa ay maaaring maging kapansin-pansin. Pangalawa, sa loob ng balangkas ng api mismo - kung sobra-sobra natin ito sa kumplikadong lohika, maaari tayong magkaroon ng mga problema sa CPU. At magiging maganda kung ang lohika ay hindi nag-aaksaya ng oras sa memorya. At may nananatiling pakikipag-ugnayan sa file system - sa karaniwang bersyon ito ay serialize / ibalik at magsulat / basahin.
Susunod ay ang pakikipag-ugnayan sa kumpol. Malamang, ito ay nasa parehong sistema, ngunit maaari itong magkahiwalay. Dito kailangan mo ring isaalang-alang ang paglipat ng data dito, ang bilis ng serialization ng data at mga pakikipag-ugnayan sa pagitan ng kumpol.
Ngayon, sa isang banda, maaari nating isipin ang "kung anong mga gear ang liliko" sa cache system kapag nagpoproseso ng mga kahilingan mula sa aming code, at sa kabilang banda, maaari naming tantiyahin kung ano at ilang mga kahilingan ang bubuo ng aming code para sa system na ito. Ito ay sapat na upang makagawa ng higit pa o hindi gaanong matino na pagpipilian - upang pumili ng isang sistema para sa aming kaso ng paggamit.
Hazelcast
Tingnan natin kung paano ilapat ang agnas na ito sa aming listahan. Halimbawa, ang Hazelcast.
Para makapaglagay/kumuha ng data mula sa Hazelcast, ina-access ng client code ang (1) api. Pinapayagan ka ng Hz na patakbuhin ang server bilang naka-embed, at sa kasong ito, ang pag-access sa api ay isang method call sa loob ng JVM, na maaaring ituring na libre.
Upang gumana ang lohika sa (2), umaasa ang Hz sa hash ng byte array ng serialized key - iyon ay, ang key ay isa-serialize sa anumang kaso. Ito ay hindi maiiwasang overhead para sa Hz.
Ang mga diskarte sa pagpapalayas ay ipinatupad nang maayos, ngunit para sa mga espesyal na kaso maaari kang magdagdag ng iyong sarili. Hindi mo kailangang mag-alala tungkol sa bahaging ito.
Maaaring ikonekta ang storage (4). Malaki. Ang pakikipag-ugnayan (5) para sa naka-embed ay maaaring ituring na instant. Pagpapalitan ng data sa pagitan ng mga node sa cluster (6) - oo, umiiral ito. Ito ay isang pamumuhunan sa fault tolerance sa kapinsalaan ng bilis. Ang tampok na Hz na Near-cache ay nagbibigay-daan sa iyo na bawasan ang presyo - ang data na natanggap mula sa iba pang mga node sa cluster ay mai-cache.
Ano ang maaaring gawin sa ganitong mga kondisyon upang madagdagan ang bilis?
Halimbawa, upang maiwasan ang serialization ng key sa (2) - mag-attach ng isa pang cache sa ibabaw ng Hazelcast, para sa pinakamainit na data. Pinili ng Sportmaster ang Caffeine para sa layuning ito.
Para sa pag-twist sa antas (6), nag-aalok ang Hz ng dalawang uri ng storage: IMap at ReplicatedMap.
Ito ay nagkakahalaga ng pagbanggit kung paano nakapasok si Hazelcast sa stack ng teknolohiya ng Sportmaster.
Noong 2012, noong ginagawa namin ang pinakaunang pilot ng hinaharap na site, ang Hazelcast ang naging unang link na ibinalik ng search engine. Nagsimula ang kakilala "sa unang pagkakataon" - nabihag kami ng katotohanan na makalipas ang dalawang oras, nang i-screw namin ang Hz sa system, gumana ito. At ito ay gumana nang maayos. Sa pagtatapos ng araw nakumpleto na namin ang ilang pagsubok at naging masaya kami. At ang reserbang ito ng kalakasan ay sapat na upang madaig ang mga sorpresa na inihagis ni Hz sa paglipas ng panahon. Ngayon ang koponan ng Sportmaster ay walang dahilan upang iwanan ang Hazelcast.
Ngunit ang mga argumento tulad ng "ang unang link sa search engine" at "Ang HelloWorld ay mabilis na binuo" ay, siyempre, isang pagbubukod at isang tampok ng sandali kung saan naganap ang pagpili. Ang mga tunay na pagsubok para sa napiling sistema ay nagsisimula sa paglabas sa produksyon, at ito ay sa yugtong ito na dapat mong bigyang pansin kapag pumipili ng anumang sistema, kabilang ang cache. Sa totoo lang, sa aming kaso maaari naming sabihin na pinili namin ang Hazelcast nang hindi sinasadya, ngunit pagkatapos ay naging tama ang aming napili.
Para sa produksyon, mas mahalaga: pagsubaybay, paghawak ng mga pagkabigo sa mga indibidwal na node, pagtitiklop ng data, gastos ng pag-scale. Iyon ay, ito ay nagkakahalaga ng pagbibigay pansin sa mga gawain na lilitaw sa panahon ng pagpapanatili ng system - kapag ang pag-load ay sampu-sampung beses na mas mataas kaysa sa binalak, kapag hindi namin sinasadyang mag-upload ng isang bagay sa maling lugar, kapag kailangan naming ilunsad ang isang bagong bersyon ng code, palitan ang data at gawin itong hindi napapansin para sa mga kliyente.
Para sa lahat ng kinakailangang ito, tiyak na umaangkop ang Hazelcast sa bayarin.
Itutuloy
Ngunit ang Hazelcast ay hindi isang panlunas sa lahat. Noong 2017, pinili namin ang Hazelcast para sa admin cache, batay lang sa magagandang impression mula sa nakaraang karanasan. Ito ay gumaganap ng isang mahalagang papel sa isang napakalupit na biro, dahil kung saan natagpuan namin ang aming sarili sa isang mahirap na sitwasyon at "kabayanihan" ay nakalabas dito sa loob ng 60 araw. Ngunit higit pa sa na sa susunod na bahagi.
Pansamantala... Maligayang Bagong Code!
Pinagmulan: www.habr.com