Helo! Fy enw i yw Alexey Pyankov, rwy'n ddatblygwr yn y cwmni Sportmaster. Yn hynny Dywedais sut y dechreuodd y gwaith ar wefan Sportmaster yn 2012, pa fentrau y gwnaethom lwyddo i’w “gwthio drwodd” ac i’r gwrthwyneb, pa gribin a gasglwyd gennym.
Heddiw rwyf am rannu meddyliau sy'n dilyn pwnc arall - dewis system caching ar gyfer y backend java yn ardal weinyddol y safle. Mae gan y plot hwn ystyr arbennig i mi - er mai dim ond am 2 fis y bu i'r stori ddatblygu, yn ystod y 60 diwrnod hyn buom yn gweithio 12-16 awr a heb un diwrnod i ffwrdd. Nid oeddwn erioed wedi meddwl na dychmygu ei bod yn bosibl gweithio mor galed.
Felly, rhannais y testun yn 2 ran er mwyn peidio â'i lwytho'n llwyr. I'r gwrthwyneb, bydd y rhan gyntaf yn ysgafn iawn - paratoi, cyflwyno, rhai ystyriaethau ynghylch beth yw caching. Os ydych chi eisoes yn ddatblygwr profiadol neu wedi gweithio gyda caches, o'r ochr dechnegol mae'n debyg na fydd unrhyw beth newydd yn yr erthygl hon. Ond ar gyfer iau, gall adolygiad mor fach ddweud wrtho i ba gyfeiriad i edrych i mewn os caiff ei hun ar groesffordd o'r fath.
Pan roddwyd y fersiwn newydd o wefan Sportmaster ar waith, derbyniwyd y data mewn ffordd a oedd, i'w roi yn ysgafn, ddim yn gyfleus iawn. Y sail oedd tablau a baratowyd ar gyfer fersiwn flaenorol y safle (Bitrix), yr oedd yn rhaid eu tynnu i mewn i ETL, eu dwyn i ffurf newydd a'u cyfoethogi â gwahanol bethau bach o ddwsin yn fwy o systemau. Er mwyn i lun newydd neu ddisgrifiad o'r cynnyrch ymddangos ar y wefan, roedd yn rhaid i chi aros tan y diwrnod wedyn - diweddariadau yn unig gyda'r nos, unwaith y dydd.
Ar y dechrau, roedd cymaint o bryderon o'r wythnosau cyntaf ar ôl dechrau cynhyrchu fel bod anghyfleustra o'r fath i reolwyr cynnwys yn ddibwys. Ond, cyn gynted ag y setlodd popeth, parhaodd datblygiad y prosiect - ychydig fisoedd yn ddiweddarach, ar ddechrau 2015, dechreuwyd datblygu'r panel gweinyddol yn weithredol. Yn 2015 a 2016, mae popeth yn mynd yn dda, rydym yn rhyddhau'n rheolaidd, mae'r panel gweinyddol yn cwmpasu mwy a mwy o'r gwaith paratoi data, ac rydym yn paratoi ar gyfer y ffaith y bydd ein tîm yn cael ei ymddiried yn y peth pwysicaf a mwyaf cymhleth yn fuan - y cynnyrch cylched (paratoi a chynnal a chadw data ar bob cynnyrch yn llawn). Ond yn ystod haf 2017, ychydig cyn lansio'r cylched nwyddau, bydd y prosiect yn cael ei hun mewn sefyllfa anodd iawn - yn union oherwydd problemau gyda caching. Rwyf am siarad am y bennod hon yn ail ran y cyhoeddiad dwy ran hwn.
Ond yn y swydd hon byddaf yn dechrau o bell, byddaf yn cyflwyno rhai meddyliau - syniadau am caching, a fyddai'n gam da i sgrolio drwyddo cyn prosiect mawr.
Pan fydd tasg caching yn digwydd
Nid yw'r dasg caching yn ymddangos yn unig. Rydym yn ddatblygwyr, yn ysgrifennu cynnyrch meddalwedd ac rydym am iddo fod yn y galw. Os oes galw am y cynnyrch ac yn llwyddiannus, bydd defnyddwyr yn dod. A daw mwy a mwy. Ac yna mae yna lawer o ddefnyddwyr ac yna mae'r cynnyrch yn dod yn llwythog iawn.
Yn y camau cyntaf, nid ydym yn meddwl am optimeiddio a pherfformiad cod. Y prif beth yw ymarferoldeb, cyflwyno cynllun peilot yn gyflym a phrofi damcaniaethau. Ac os yw'r llwyth yn cynyddu, rydyn ni'n pwmpio'r haearn i fyny. Rydyn ni'n ei gynyddu dwy neu dair gwaith, bum gwaith, efallai 10 gwaith. Rhywle yma - ni fydd cyllid yn caniatáu hynny mwyach. Sawl gwaith bydd nifer y defnyddwyr yn cynyddu? Ni fydd yn debyg i 2-5-10, ond os bydd yn llwyddiannus, bydd rhwng 100-1000 a 100 mil o weithiau. Hynny yw, yn hwyr neu'n hwyrach, bydd yn rhaid i chi wneud optimeiddio.
Gadewch i ni ddweud bod rhyw ran o'r cod (gadewch i ni alw'r rhan hon yn swyddogaeth) yn cymryd amser anweddus o hir, ac rydym am leihau'r amser gweithredu. Gall swyddogaeth fod yn fynediad i gronfa ddata, neu gall fod yn gyflawni rhywfaint o resymeg gymhleth - y prif beth yw ei bod yn cymryd amser hir i'w gweithredu. Faint allwch chi leihau'r amser gweithredu? Yn y terfyn, gallwch ei leihau i sero, dim pellach. Sut allwch chi leihau'r amser gweithredu i sero? Ateb: dileu dienyddiad yn gyfan gwbl. Yn lle hynny, dychwelwch y canlyniad ar unwaith. Sut allwch chi ddarganfod y canlyniad? Ateb: naill ai ei gyfrifo neu edrych yn rhywle. Mae'n cymryd amser hir i gyfrifo. Ac i ysbïo yw, er enghraifft, i gofio'r canlyniad bod y swyddogaeth a gynhyrchwyd y tro diwethaf pan gaiff ei alw gyda'r un paramedrau.
Hynny yw, nid yw gweithredu’r swyddogaeth yn bwysig i ni. Mae'n ddigon dim ond gwybod ar ba baramedrau y mae'r canlyniad yn dibynnu. Yna, os yw'r gwerthoedd paramedr yn cael eu cynrychioli ar ffurf gwrthrych y gellir ei ddefnyddio fel allwedd mewn rhywfaint o storfa, yna gellir arbed canlyniad y cyfrifiad a'i ddarllen y tro nesaf y caiff ei gyrchu. Os yw ysgrifennu a darllen y canlyniad hwn yn gyflymach na chyflawni'r swyddogaeth, mae gennym elw o ran cyflymder. Gall swm yr elw gyrraedd 100, 1000, a 100 mil o weithiau (mae 10 ^ 5 braidd yn eithriad, ond yn achos sylfaen eithaf llusgo, mae'n eithaf posibl).
Gofynion sylfaenol ar gyfer system caching
Y peth cyntaf a allai ddod yn ofyniad ar gyfer system caching yw cyflymder darllen cyflym ac, i raddau ychydig yn llai, cyflymder ysgrifennu. Mae hyn yn wir, ond dim ond nes i ni gyflwyno'r system i gynhyrchu.
Gadewch i ni chwarae'r achos hwn.
Gadewch i ni ddweud ein bod wedi darparu caledwedd i'r llwyth presennol ac rydym bellach yn cyflwyno caching yn raddol. Mae nifer y defnyddwyr yn tyfu ychydig, mae'r llwyth yn cynyddu - rydym yn ychwanegu ychydig o caches, yn ei sgriwio yma ac acw. Mae hyn yn parhau ers peth amser, ac erbyn hyn ni chaiff swyddogaethau trwm eu galw'n ymarferol mwyach - mae'r prif lwyth cyfan yn disgyn ar y storfa. Mae nifer y defnyddwyr yn ystod yr amser hwn wedi cynyddu N gwaith.
Ac os gallai'r cyflenwad cychwynnol o galedwedd fod 2-5 gwaith, yna gyda chymorth y storfa gallem wella perfformiad gan ffactor o 10 neu, mewn achos da, gan ffactor o 100, mewn rhai mannau efallai trwy ffactor o 1000. Hynny yw, ar yr un caledwedd – rydym yn prosesu 100 gwaith yn fwy o geisiadau. Gwych, ti'n haeddu'r bara sinsir!
Ond nawr, ar un adeg dda, trwy hap a damwain, fe chwalodd y system a chwalodd y storfa. Dim byd arbennig - wedi'r cyfan, dewiswyd y storfa yn seiliedig ar y gofyniad “cyflymder darllen ac ysgrifennu uchel, nid yw'r gweddill o bwys.”
O'i gymharu â'r llwyth cychwyn, roedd ein cronfa haearn wrth gefn 2-5 gwaith, a chynyddodd y llwyth yn ystod yr amser hwn 10-100 gwaith. Gan ddefnyddio'r storfa, fe wnaethom ddileu galwadau am swyddogaethau trwm ac felly gweithiodd popeth. Ac yn awr, heb storfa, sawl gwaith y bydd ein system yn arafu? Beth fydd yn digwydd i ni? Bydd y system yn disgyn.
Hyd yn oed pe na bai ein storfa yn chwalu, ond dim ond am ychydig y cafodd ei glirio, bydd angen ei gynhesu, a bydd hyn yn cymryd peth amser. Ac yn ystod y cyfnod hwn, bydd y prif faich yn disgyn ar ymarferoldeb.
Casgliad: mae prosiectau cynhyrchu llwyth uchel yn gofyn am system caching nid yn unig i gael cyflymder darllen ac ysgrifennu uchel, ond hefyd i sicrhau diogelwch data a gwrthsefyll methiannau.
Yr ing o ddewis
Mewn prosiect gyda phanel gweinyddol, aeth y dewis fel hyn: yn gyntaf fe wnaethom osod Hazelcast, oherwydd Roeddem eisoes yn gyfarwydd â'r cynnyrch hwn o brofiad y prif safle. Ond yma trodd y dewis hwn yn aflwyddiannus - o dan ein proffil llwyth, nid yn unig mae Hazelcast yn araf, ond yn ofnadwy o araf. Ac ar y pryd roeddem eisoes wedi cofrestru ar gyfer y dyddiad rhyddhau.
Spoiler: sut yn union y datblygodd yr amgylchiadau ein bod wedi methu cymaint o fawr ac yn y diwedd yn wynebu sefyllfa acíwt a llawn tyndra - dywedaf wrthych yn yr ail ran - a sut y daethom i ben a sut y daethom allan. Ond nawr - fe wnaf i ddweud ei fod yn llawer o straen, ac “i feddwl - ni allaf feddwl rhywsut, rydyn ni'n ysgwyd y botel.” Mae “ysgwyd y botel” hefyd yn sbwyliwr, mwy am hynny yn nes ymlaen.
Beth wnaethom ni:
- Rydym yn gwneud rhestr o'r holl systemau y mae Google a StackOverflow yn eu hawgrymu. Ychydig dros 30
- Rydym yn ysgrifennu profion gyda llwyth nodweddiadol ar gyfer cynhyrchu. I wneud hyn, fe wnaethom gofnodi data sy'n mynd trwy'r system mewn amgylchedd cynhyrchu - math o sniffer ar gyfer data nid ar y rhwydwaith, ond y tu mewn i'r system. Yn union defnyddiwyd y data hwn yn y profion.
- Gyda'r tîm cyfan, mae pawb yn dewis y system nesaf o'r rhestr, yn ei ffurfweddu, ac yn rhedeg profion. Nid yw'n pasio'r prawf, nid yw'n cario'r llwyth - rydyn ni'n ei daflu ac yn symud ymlaen i'r un nesaf yn y llinell.
- Ar yr 17eg system daeth yn amlwg bod popeth yn anobeithiol. Stopiwch ysgwyd y botel, mae'n bryd meddwl o ddifrif.
Ond mae hwn yn opsiwn pan fydd angen i chi ddewis system a fydd yn “mynd trwy'r cyflymder” mewn profion a baratowyd ymlaen llaw. Beth os nad oes profion o'r fath eto a'ch bod am ddewis yn gyflym?
Gadewch i ni fodelu'r opsiwn hwn (mae'n anodd dychmygu bod datblygwr canol+ yn byw mewn gwactod, ac ar adeg y dewis nid yw eto wedi ffurfioli ei ddewis pa gynnyrch i roi cynnig arno gyntaf - felly, mae rhesymu pellach yn fwy o ddamcaniaeth/athroniaeth/ am iau).
Ar ôl penderfynu ar y gofynion, byddwn yn dechrau dewis datrysiad allan o'r bocs. Pam ailddyfeisio'r olwyn: byddwn yn mynd i gymryd system caching parod.
Os ydych chi newydd ddechrau ac yn ei google, yna rhowch neu cymerwch yr archeb, ond yn gyffredinol, bydd y canllawiau fel hyn. Yn gyntaf oll, byddwch yn dod ar draws Redis, mae i'w glywed ym mhobman. Yna byddwch yn darganfod mai EhCache yw'r system hynaf a mwyaf profedig. Nesaf byddwn yn ysgrifennu am Tarantool, datblygiad domestig sydd ag agwedd unigryw ar yr ateb. A hefyd Tanio, oherwydd ei fod bellach ar gynnydd mewn poblogrwydd ac yn mwynhau cefnogaeth SberTech. Ar y diwedd mae Hazelcast hefyd, oherwydd yn y byd menter mae'n aml yn ymddangos ymhlith cwmnïau mawr.
Nid yw'r rhestr yn hollgynhwysfawr; mae yna ddwsinau o systemau. A dim ond un peth y byddwn ni'n ei sgriwio. Gadewch i ni gymryd y 5 system a ddewiswyd ar gyfer y “gystadleuaeth harddwch” a gwneud detholiad. Pwy fydd yr enillydd?
Redis
Rydyn ni'n darllen yr hyn maen nhw'n ei ysgrifennu ar y wefan swyddogol.
- prosiect ffynhonnell agored. Mae'n cynnig storfa data yn y cof, y gallu i arbed ar ddisg, rhannu'n awtomatig, argaeledd uchel ac adferiad o doriadau rhwydwaith.
Mae'n ymddangos bod popeth yn iawn, gallwch chi ei gymryd a'i sgriwio ymlaen - popeth sydd ei angen arnoch chi, mae'n ei wneud. Ond dim ond am hwyl, gadewch i ni edrych ar yr ymgeiswyr eraill.
EhCache
- “y storfa a ddefnyddir fwyaf ar gyfer Java” (cyfieithiad o'r slogan o'r wefan swyddogol). Hefyd ffynhonnell agored. Ac yna rydyn ni'n deall nad yw Redis ar gyfer java, ond yn gyffredinol, ac i ryngweithio ag ef mae angen papur lapio arnoch chi. A bydd EhCache yn fwy cyfleus. Beth arall mae'r system yn ei addo? Dibynadwyedd, profedig, ymarferoldeb llawn. Wel, dyma'r mwyaf cyffredin hefyd. Ac yn caches terabytes o ddata.
Mae Redis yn angof, rwy'n barod i ddewis EhCache.
Ond mae ymdeimlad o wladgarwch yn fy ngwthio i weld beth sy'n dda am Tarantool.
Tarantool
- yn cwrdd â'r dynodiad “Llwyfan integreiddio data amser real”. Mae'n swnio'n gymhleth iawn, felly rydyn ni'n darllen y dudalen yn fanwl ac yn dod o hyd i ddatganiad uchel: "Yn storio 100% o'r data mewn RAM." Dylai hyn godi cwestiynau - wedi'r cyfan, gall fod llawer mwy o ddata na chof. Yr esboniad yw ei fod yn golygu nad yw Tarantool yn rhedeg cyfresoli i ysgrifennu data i ddisg o'r cof. Yn lle hynny, mae'n defnyddio nodweddion lefel isel y system, pan fydd cof yn cael ei fapio i system ffeiliau gyda pherfformiad I/O da iawn. Yn gyffredinol, gwnaethant rywbeth gwych ac oer.
Edrychwn ar y gweithrediadau: priffordd gorfforaethol Mail.ru, Avito, Beeline, Megafon, Alfa-Bank, Gazprom ...
Os oedd unrhyw amheuon o hyd ynghylch Tarantool, yna mae'r achos gweithredu yn Mastercard yn rhoi diwedd ar fi. Rwy'n cymryd Tarantool.
Ond beth bynnag…
Ignite
… a oes mwy , yn cael ei bilio fel “llwyfan cyfrifiadura mewn cof...cyflymder cof ar betabytes o ddata.” Mae yna lawer o fanteision yma hefyd: storfa cof wedi'i ddosbarthu, y storfa a'r storfa gwerth allweddol cyflymaf, graddio llorweddol, argaeledd uchel, cywirdeb llym. Yn gyffredinol, mae'n ymddangos mai'r cyflymaf yw Ignite.
Gweithrediadau: Sberbank, American Airlines, Yahoo! Japan. Ac yna darganfyddaf nad yn Sberbank yn unig y gweithredir Ignite, ond mae tîm SberTech yn anfon ei bobl at y tîm Ignite ei hun i fireinio'r cynnyrch. Mae hyn yn hollol gyfareddol ac rwy'n barod i gymryd Ignite.
Mae'n gwbl aneglur pam, rwy'n edrych ar y pumed pwynt.
gollen
Rwy'n mynd i'r safle , darllen. Ac mae'n ymddangos mai'r ateb cyflymaf ar gyfer caching dosbarthedig yw Hazelcast. Mae'n orchmynion maint yn gyflymach na phob datrysiad arall ac yn gyffredinol mae'n arweinydd ym maes grid data cof. Yn erbyn y cefndir hwn, i gymryd rhywbeth arall yw peidio â pharchu eich hun. Mae hefyd yn defnyddio storfa ddata ddiangen ar gyfer gweithrediad parhaus y clwstwr heb golli data.
Dyna ni, dwi'n barod i gymryd Hazelcast.
Cymhariaeth
Ond os edrychwch, disgrifir pob un o'r pum ymgeisydd yn y fath fodd fel bod pob un ohonynt y gorau. Sut i ddewis? Gallwn weld pa un yw'r mwyaf poblogaidd, edrychwch am gymariaethau, a bydd y cur pen yn diflannu.
Rydym yn dod o hyd i un fel hyn , dewiswch ein 5 system.
Yma maen nhw'n cael eu datrys: mae Redis ar y brig, mae Hazelcast yn yr ail safle, mae Tarantool ac Ignite yn ennill poblogrwydd, mae EhCache wedi bod ac yn aros yr un peth.
Ond gadewch i ni edrych ar : dolenni i wefannau, diddordeb cyffredinol yn y system, cynigion swyddi - gwych! Hynny yw, pan fydd fy system yn methu, byddaf yn dweud: “Na, mae'n ddibynadwy! Mae yna lawer o gynigion swyddi..." Ni fydd cymhariaeth mor syml yn ei wneud.
Nid systemau caching yn unig yw'r holl systemau hyn. Mae ganddynt hefyd lawer o ymarferoldeb, gan gynnwys pan na chaiff data ei bwmpio i'r cleient i'w brosesu, ond i'r gwrthwyneb: mae'r cod y mae angen ei weithredu ar y data yn symud i'r gweinydd, yn cael ei weithredu yno, a dychwelir y canlyniad. Ac nid ydynt mor aml yn cael eu hystyried fel system ar wahân ar gyfer caching.
Iawn, gadewch i ni beidio â rhoi'r gorau iddi, gadewch i ni ddod o hyd i gymhariaeth uniongyrchol o'r systemau. Gadewch i ni gymryd y ddau opsiwn gorau - Redis a Hazelcast. Mae gennym ddiddordeb mewn cyflymder, a byddwn yn eu cymharu yn seiliedig ar y paramedr hwn.
Hz yn erbyn Redis
Rydym yn dod o hyd i hyn :
Glas yw Redis, coch yw Hazelcast. Mae Hazelcast yn ennill ym mhobman, ac mae rhesymeg dros hyn: mae'n aml-edau, wedi'i optimeiddio'n fawr, mae pob edefyn yn gweithio gyda'i raniad ei hun, felly nid oes unrhyw rwystro. Ac mae Redis yn un edau; nid yw'n elwa o CPUs aml-graidd modern. Mae gan Hazelcast I/O asyncronaidd, mae gan Redis-Jedis socedi blocio. Wedi'r cyfan, mae Hazelcast yn defnyddio protocol deuaidd, ac mae Redis yn canolbwyntio ar destun, sy'n golygu ei fod yn aneffeithlon.
Rhag ofn, gadewch i ni droi at ffynhonnell arall o gymharu. Beth fydd e'n ei ddangos i ni?
Redis yn erbyn Hz
Un arall :
Yma, i'r gwrthwyneb, coch yw Redis. Hynny yw, mae Redis yn perfformio'n well na Hazelcast o ran perfformiad. Hazelcast enillodd y gymhariaeth gyntaf, Redis enillodd yr ail. esboniodd yn union iawn pam enillodd Hazelcast y gymhariaeth flaenorol.
Mae'n ymddangos bod canlyniad yr un cyntaf wedi'i rigio mewn gwirionedd: cymerwyd Redis yn y blwch sylfaen, a chafodd Hazelcast ei deilwra ar gyfer achos prawf. Yna mae'n troi allan: yn gyntaf, ni allwn ymddiried yn unrhyw un, ac yn ail, pan fyddwn yn dewis system o'r diwedd, mae angen i ni ei ffurfweddu'n gywir o hyd. Mae'r gosodiadau hyn yn cynnwys dwsinau, bron i gannoedd o baramedrau.
Ysgwyd y botel
A gallaf egluro’r holl broses yr ydym bellach wedi’i gwneud gyda’r trosiad canlynol: “Ysgydwodd y botel.” Hynny yw, nawr does dim rhaid i chi raglennu, nawr y prif beth yw gallu darllen stackoverflow. Ac mae gen i berson ar fy nhîm, gweithiwr proffesiynol, sy'n gweithio'n union fel hyn ar adegau tyngedfennol.
Beth mae e'n ei wneud? Mae'n gweld peth wedi torri, yn gweld olrhain pentwr, yn cymryd rhai geiriau ohono (pa rai yw ei arbenigedd yn y rhaglen), yn chwilio ar Google, yn canfod stackoverflow ymhlith yr atebion. Heb ddarllen, heb feddwl, ymhlith yr atebion i’r cwestiwn, mae’n dewis rhywbeth tebycaf i’r frawddeg “gwnewch hyn a hwna” (dewis ateb o’r fath yw ei ddawn, oherwydd nid dyna’r ateb a gafodd fwyaf o hoffter bob amser), yn berthnasol , yn edrych: os oes rhywbeth wedi newid, yna gwych. Os nad yw wedi newid, rholiwch ef yn ôl. Ac ailadrodd lansio-gwirio-chwiliad. Ac yn y ffordd reddfol hon, mae'n sicrhau bod y cod yn gweithio ar ôl peth amser. Nid yw'n gwybod pam, nid yw'n gwybod beth a wnaeth, ni all esbonio. Ond! Mae haint hwn yn gweithio. Ac “mae'r tân wedi'i ddiffodd.” Nawr gadewch i ni ddarganfod beth wnaethom ni. Pan fydd y rhaglen yn gweithio, mae'n drefn maint yn haws. Ac mae'n arbed llawer o amser.
Mae'r dull hwn wedi'i esbonio'n dda iawn gyda'r enghraifft hon.
Roedd yn boblogaidd iawn unwaith i gasglu cwch hwylio mewn potel. Ar yr un pryd, mae'r cwch hwylio yn fawr ac yn fregus, ac mae gwddf y botel yn gul iawn, mae'n amhosibl ei wthio y tu mewn. Sut i'w ymgynnull?
Mae yna ddull o'r fath, yn gyflym iawn ac yn effeithiol iawn.
Mae'r llong yn cynnwys criw o bethau bach: ffyn, rhaffau, hwyliau, glud. Rydyn ni'n rhoi hyn i gyd mewn potel.
Rydyn ni'n cymryd y botel gyda'r ddwy law ac yn dechrau ysgwyd. Rydym yn ysgwyd ac yn ysgwyd hi. Ac fel arfer mae'n troi allan i fod yn sothach llwyr, wrth gwrs. Ond weithiau. Weithiau mae'n troi allan i fod yn llong! Yn fwy manwl gywir, rhywbeth tebyg i long.
Rydyn ni'n dangos y rhywbeth hwn i rywun: "Seryoga, ydych chi'n gweld!?" Ac yn wir, o bell mae'n edrych fel llong. Ond ni ellir caniatáu i hyn barhau.
Mae yna ffordd arall. Maent yn cael eu defnyddio gan ddynion mwy datblygedig, fel hacwyr.
Rhoddais dasg i'r boi hwn, gwnaeth bopeth a gadael. Ac rydych chi'n edrych - mae'n edrych fel ei fod wedi'i wneud. Ac ar ôl ychydig, pan fydd angen cwblhau'r cod, mae hyn yn dechrau oherwydd ef ... Mae'n dda ei fod eisoes wedi llwyddo i redeg ymhell i ffwrdd. Dyma'r dynion a fydd, gan ddefnyddio'r enghraifft o botel, yn gwneud hyn: fe welwch, lle mae'r gwaelod, mae'r gwydr yn troi. Ac nid yw'n gwbl glir a yw'n dryloyw ai peidio. Yna torrodd y “hacwyr” y gwaelod hwn i ffwrdd, mewnosodwch long yno, yna gludwch y gwaelod yn ôl ymlaen eto, ac mae fel pe bai fel hynny i fod.
O safbwynt gosod y broblem, mae'n ymddangos bod popeth yn gywir. Ond gan ddefnyddio llongau fel enghraifft: pam gwneud y llong hon o gwbl, pwy sydd ei angen beth bynnag? Nid yw'n darparu unrhyw ymarferoldeb. Fel arfer mae llongau o'r fath yn anrhegion i bobl uchel iawn, sy'n ei roi ar silff uwch eu pennau, fel rhyw fath o symbol, fel arwydd. Ac os yw person o'r fath, pennaeth busnes mawr neu swyddog uchel ei statws, sut y bydd y faner yn sefyll am hac o'r fath, y mae ei gwddf wedi'i dorri i ffwrdd? Byddai'n well pe na bai byth yn gwybod amdano. Felly, sut maen nhw yn y pen draw yn gwneud y llongau hyn y gellir eu rhoi i berson pwysig?
Yr unig le allweddol na allwch chi wneud dim byd amdano yw'r corff. Ac mae corff y llong yn ffitio i'r gwddf. Tra bod y llong yn cael ei ymgynnull y tu allan i'r botel. Ond nid dim ond cydosod llong ydyw, mae'n grefft gemwaith go iawn. Mae liferi arbennig yn cael eu hychwanegu at y cydrannau, sydd wedyn yn caniatáu iddynt gael eu codi. Er enghraifft, mae'r hwyliau'n cael eu plygu, eu dwyn yn ofalus y tu mewn, ac yna, gyda chymorth tweezers, maent yn cael eu tynnu a'u codi'n fanwl iawn, gyda manwl gywirdeb. Y canlyniad yw gwaith celf y gellir ei roi gyda chydwybod glir a balchder.
Ac os ydym am i'r prosiect fod yn llwyddiannus, rhaid cael o leiaf un gemydd ar y tîm. Rhywun sy'n poeni am ansawdd y cynnyrch ac yn ystyried pob agwedd, heb aberthu unrhyw beth, hyd yn oed mewn eiliadau o straen, pan fo amgylchiadau'n gofyn am wneud y brys ar draul y pwysig. Mae pob prosiect llwyddiannus sy'n gynaliadwy, sydd wedi sefyll prawf amser, wedi'i adeiladu ar yr egwyddor hon. Mae rhywbeth manwl iawn ac unigryw yn eu cylch, rhywbeth sy'n manteisio ar yr holl bosibiliadau sydd ar gael. Yn yr enghraifft gyda'r llong yn y botel, mae'r ffaith bod corff y llong yn mynd trwy'r gwddf yn cael ei chwarae allan.
Gan ddychwelyd at y dasg o ddewis ein gweinydd caching, sut y gellid cymhwyso'r dull hwn? Rwy'n cynnig yr opsiwn hwn o ddewis o'r holl systemau sy'n bodoli - peidiwch ag ysgwyd y botel, peidiwch â dewis, ond edrychwch ar yr hyn sydd ganddynt mewn egwyddor, beth i edrych amdano wrth ddewis system.
Ble i chwilio am botel-gwddf
Gadewch i ni geisio peidio ag ysgwyd y botel, i beidio â mynd trwy bopeth sydd yno fesul un, ond gadewch i ni weld pa broblemau fydd yn codi os byddwn yn sydyn, ar gyfer ein tasg, yn dylunio system o'r fath ein hunain. Wrth gwrs, ni fyddwn yn cydosod y beic, ond byddwn yn defnyddio'r diagram hwn i'n helpu i ddarganfod pa bwyntiau i roi sylw iddynt mewn disgrifiadau cynnyrch. Gadewch i ni fraslunio diagram o'r fath.
Os caiff y system ei dosbarthu, yna bydd gennym sawl gweinydd (6). Gadewch i ni ddweud bod pedwar (mae'n gyfleus eu gosod yn y llun, ond, wrth gwrs, gall fod cymaint ohonyn nhw ag y dymunwch). Os yw'r gweinyddwyr ar nodau gwahanol, mae'n golygu eu bod i gyd yn rhedeg rhywfaint o god sy'n gyfrifol am sicrhau bod y nodau hyn yn ffurfio clwstwr ac, os bydd toriad, yn cysylltu ac yn adnabod ei gilydd.
Mae arnom hefyd angen rhesymeg cod (2), sydd mewn gwirionedd yn ymwneud â caching. Mae cleientiaid yn rhyngweithio â'r cod hwn trwy rai API. Gall cod cleient (1) fod naill ai o fewn yr un JVM neu gael mynediad iddo dros y rhwydwaith. Y rhesymeg a weithredir y tu mewn yw penderfyniad pa wrthrychau i'w gadael yn y storfa a pha rai i'w taflu allan. Rydym yn defnyddio cof (3) i storio'r storfa, ond os oes angen, gallwn arbed rhywfaint o'r data ar ddisg (4).
Gadewch i ni weld ym mha rannau y bydd y llwyth yn digwydd. Mewn gwirionedd, bydd pob saeth a phob nod yn cael eu llwytho. Yn gyntaf, rhwng cod y cleient a'r ap, os mai cyfathrebu rhwydwaith yw hwn, gall yr ymsuddiant fod yn eithaf amlwg. Yn ail, o fewn fframwaith yr api ei hun - os ydym yn gorwneud pethau â rhesymeg gymhleth, gallwn fynd i mewn i broblemau gyda'r CPU. A byddai'n braf pe na bai rhesymeg yn gwastraffu amser ar y cof. Ac erys rhyngweithio gyda'r system ffeiliau - yn y fersiwn arferol mae hyn yn serialize / adfer ac ysgrifennu / darllen.
Nesaf yw rhyngweithio â'r clwstwr. Yn fwyaf tebygol, bydd yn yr un system, ond gallai fod ar wahân. Yma mae angen i chi hefyd ystyried trosglwyddo data iddo, cyflymder cyfresoli data a rhyngweithiadau rhwng y clwstwr.
Nawr, ar y naill law, gallwn ddychmygu “pa gerau fydd yn troi” yn y system storfa wrth brosesu ceisiadau o'n cod, ac ar y llaw arall, gallwn amcangyfrif pa geisiadau a faint o geisiadau y bydd ein cod yn eu cynhyrchu i'r system hon. Mae hyn yn ddigon i wneud dewis mwy neu lai sobr - i ddewis system ar gyfer ein hachos defnydd.
gollen
Gadewch i ni weld sut i gymhwyso'r dadelfeniad hwn i'n rhestr. Er enghraifft, Hazelcast.
Er mwyn rhoi / cymryd data o Hazelcast, mae cod y cleient yn cyrchu (1) yr ap. Mae Hz yn caniatáu ichi redeg y gweinydd fel un sydd wedi'i fewnosod, ac yn yr achos hwn, mae cyrchu'r ap yn alwad dull y tu mewn i'r JVM, y gellir ei ystyried yn rhad ac am ddim.
Er mwyn i'r rhesymeg yn (2) weithio, mae Hz yn dibynnu ar stwnsh arae beit yr allwedd gyfresol - hynny yw, bydd yr allwedd yn cael ei chyfresoli beth bynnag. Mae hyn yn anochel gorbenion ar gyfer Hz.
Mae strategaethau troi allan yn cael eu gweithredu'n dda, ond ar gyfer achosion arbennig gallwch chi ychwanegu'ch rhai chi. Nid oes rhaid i chi boeni am y rhan hon.
Gellir cysylltu storio (4). Gwych. Gellir ystyried rhyngweithio (5) ar gyfer gwreiddio ar unwaith. Cyfnewid data rhwng nodau yn y clwstwr (6) - ydy, mae'n bodoli. Mae hwn yn fuddsoddiad mewn goddefgarwch namau ar draul cyflymder. Mae'r nodwedd Hz Near-cache yn caniatáu ichi leihau'r pris - bydd data a dderbynnir o nodau eraill yn y clwstwr yn cael ei storio.
Beth ellir ei wneud mewn amodau o'r fath i gynyddu cyflymder?
Er enghraifft, er mwyn osgoi cyfresoli'r allwedd yn (2) - atodwch storfa arall ar ben Hazelcast, ar gyfer y data poethaf. Dewisodd Sportmaster Gaffein at y diben hwn.
Ar gyfer troelli ar lefel (6), mae Hz yn cynnig dau fath o storfa: IMap a ReplicatedMap.
Mae'n werth sôn am sut aeth Hazelcast i mewn i stac technoleg Sportmaster.
Yn 2012, pan oeddem yn gweithio ar y peilot cyntaf un o safle'r dyfodol, Hazelcast oedd y ddolen gyntaf i'r peiriant chwilio ddychwelyd. Dechreuodd y cydnabod “y tro cyntaf” - cawsom ein swyno gan y ffaith mai dim ond dwy awr yn ddiweddarach, pan wnaethom sgriwio Hz i mewn i'r system, roedd yn gweithio. Ac fe weithiodd yn dda. Erbyn diwedd y dydd roeddem wedi cwblhau nifer o brofion ac yn hapus. Ac roedd y gronfa wrth gefn hon o egni yn ddigon i oresgyn y syndod a godwyd gan Hz dros amser. Nawr nid oes gan dîm Sportmaster unrhyw reswm i gefnu ar Hazelcast.
Ond mae dadleuon fel “y ddolen gyntaf yn y peiriant chwilio” a “HelloWorld wedi’i ymgynnull yn gyflym”, wrth gwrs, yn eithriad ac yn nodwedd o’r foment y digwyddodd y dewis. Mae'r profion go iawn ar gyfer y system a ddewiswyd yn dechrau gyda'r rhyddhau i'r cynhyrchiad, ac ar hyn o bryd y dylech dalu sylw wrth ddewis unrhyw system, gan gynnwys storfa. A dweud y gwir, yn ein hachos ni, gallwn ddweud ein bod wedi dewis Hazelcast ar ddamwain, ond yna daeth i'r amlwg ein bod wedi dewis yn gywir.
Ar gyfer cynhyrchu, mae'n bwysicach o lawer: monitro, trin methiannau ar nodau unigol, dyblygu data, cost graddio. Hynny yw, mae'n werth talu sylw i'r tasgau a fydd yn codi wrth gynnal a chadw'r system - pan fydd y llwyth ddegau o weithiau'n uwch na'r disgwyl, pan fyddwn yn llwytho rhywbeth i fyny yn ddamweiniol yn y lle anghywir, pan fydd angen i ni gyflwyno fersiwn newydd. o'r cod, disodli data a'i wneud heb i neb sylwi ar gyfer cleientiaid.
Ar gyfer yr holl ofynion hyn, mae Hazelcast yn sicr yn cyd-fynd â'r bil.
I'w barhau
Ond nid yw Hazelcast yn ateb i bob problem. Yn 2017, gwnaethom ddewis Hazelcast ar gyfer y storfa weinyddol, yn seiliedig yn syml ar argraffiadau da o brofiad blaenorol. Chwaraeodd hyn ran allweddol mewn jôc greulon iawn, oherwydd cawsom ein hunain mewn sefyllfa anodd ac yn “arwrol” dod allan ohoni am 60 diwrnod. Ond mwy am hynny yn y rhan nesaf.
Yn y cyfamser... Cod Newydd Hapus!
Ffynhonnell: hab.com