Artem Denisov ( , )
Badoo yw safle dyddio mwyaf y byd. Ar hyn o bryd mae gennym tua 330 miliwn o ddefnyddwyr cofrestredig ledled y byd. Ond yr hyn sy'n llawer pwysicach yng nghyd-destun ein sgwrs heddiw yw ein bod yn storio tua 3 petabytes o luniau defnyddwyr. Bob dydd mae ein defnyddwyr yn uwchlwytho tua 3,5 miliwn o luniau newydd, ac mae'r llwyth darllen tua 80 mil o geisiadau yr eiliad. Mae hyn yn dipyn ar gyfer ein backend, ac weithiau mae anawsterau gyda hyn.
Byddaf yn siarad am ddyluniad y system hon, sy'n storio ac yn anfon lluniau yn gyffredinol, a byddaf yn edrych arno o safbwynt datblygwr. Bydd ôl-weithredol byr ar sut y datblygodd, lle byddaf yn amlinellu’r prif gerrig milltir, ond ni fyddaf ond yn siarad yn fanylach am yr atebion yr ydym yn eu defnyddio ar hyn o bryd.
Nawr gadewch i ni ddechrau.
Fel y dywedais, bydd hwn yn ôl-weithredol, ac er mwyn ei gychwyn yn rhywle, gadewch i ni gymryd yr enghraifft fwyaf cyffredin.
Mae gennym dasg gyffredin, mae angen inni dderbyn, storio ac anfon lluniau defnyddwyr. Yn y ffurflen hon, mae'r dasg yn gyffredinol, gallwn ddefnyddio unrhyw beth:
- storfa cwmwl modern,
- ateb bocsus, y mae llawer ohono hefyd yn awr;
- Gallwn osod sawl peiriant yn ein canolfan ddata a rhoi gyriannau caled mawr arnynt a storio lluniau yno.
Yn hanesyddol mae Badoo - yn awr ac yn y man (ar yr adeg pan oedd yn ei fabandod) - yn byw ar ei weinyddion ei hun, y tu mewn i'n DCs ein hunain. Felly, yr opsiwn hwn oedd y gorau i ni.
Fe wnaethon ni gymryd sawl peiriant, a'u galw'n “ffotograffau”, a chawsom glwstwr sy'n storio lluniau. Ond mae'n ymddangos bod rhywbeth ar goll. Er mwyn i hyn i gyd weithio, mae angen i ni benderfynu rhywsut ar ba beiriant y byddwn yn storio pa luniau. Ac yma, hefyd, nid oes angen agor America.
Rydym yn ychwanegu rhywfaint o faes at ein storfa gyda gwybodaeth am ddefnyddwyr. Dyma fydd yr allwedd darnio. Yn ein hachos ni, fe wnaethon ni ei alw'n place_id, ac mae'r id lle hwn yn pwyntio at y man lle mae lluniau defnyddwyr yn cael eu storio. Rydyn ni'n gwneud mapiau.
Yn y cam cyntaf, gellir gwneud hyn â llaw hyd yn oed - dywedwn y bydd llun o'r defnyddiwr hwn gyda lle o'r fath yn glanio ar weinydd o'r fath. Diolch i'r map hwn, rydyn ni bob amser yn gwybod pryd mae defnyddiwr yn uwchlwytho llun, ble i'w gadw, ac rydyn ni'n gwybod o ble i'w roi.
Mae hwn yn gynllun hollol ddibwys, ond mae iddo fanteision eithaf sylweddol. Y cyntaf yw ei fod yn syml, fel y dywedais, a'r ail yw, gyda'r dull hwn, y gallwn yn hawdd raddio'n llorweddol trwy ddanfon ceir newydd a'u hychwanegu at y map. Nid oes angen i chi wneud unrhyw beth arall.
Dyna fel y bu i ni am beth amser.
Roedd hyn tua 2009. Fe wnaethon nhw ddosbarthu ceir, danfon...
Ac ar ryw adeg dechreuasom sylwi fod gan y cynllun hwn rai anfanteision. Beth yw'r anfanteision?
Yn gyntaf oll, mae gallu cyfyngedig. Ni allwn glymu cymaint o yriannau caled ar un gweinydd ffisegol ag yr hoffem. Ac mae hyn wedi dod yn broblem benodol dros amser a chyda thwf y set ddata.
Ac yn ail. Mae hwn yn gyfluniad annodweddiadol o beiriannau, gan fod peiriannau o'r fath yn anodd eu hailddefnyddio mewn rhai clystyrau eraill; maent yn eithaf penodol, h.y. dylent fod yn wan mewn perfformiad, ond ar yr un pryd gyda gyriant caled mawr.
Roedd hyn i gyd ar gyfer 2009, ond, mewn egwyddor, mae'r gofynion hyn yn dal yn berthnasol heddiw. Mae gennym ôl-weithredol, felly yn 2009 roedd popeth yn hollol ddrwg â hyn.
A'r pwynt olaf yw'r pris.
Roedd y pris yn serth iawn bryd hynny, ac roedd angen inni chwilio am rai dewisiadau eraill. Y rhai. roedd angen i ni rywsut wneud defnydd gwell o'r gofod yn y canolfannau data a'r gweinyddwyr ffisegol y mae hyn i gyd wedi'i leoli arnynt. A dechreuodd ein peirianwyr system astudiaeth fawr lle buont yn adolygu criw o wahanol opsiynau. Buont hefyd yn edrych ar systemau ffeiliau clystyrog fel PolyCeph a Luster. Roedd problemau perfformiad a gweithrediad eithaf anodd. Gwrthodasant. Fe wnaethon ni geisio gosod y set ddata gyfan trwy NFS ar bob car er mwyn ei raddfa i fyny rywsut. Aeth darllen yn wael hefyd, fe wnaethon ni roi cynnig ar wahanol atebion gan wahanol werthwyr.
Ac yn y diwedd, fe wnaethom setlo ar ddefnyddio'r Rhwydwaith Ardal Storio fel y'i gelwir.
Mae'r rhain yn SHDs mawr sydd wedi'u cynllunio'n benodol ar gyfer storio llawer iawn o ddata. Maent yn silffoedd gyda disgiau sy'n cael eu gosod ar y peiriannau allbwn optegol terfynol. Hynny. mae gennym ryw fath o gronfa o beiriannau, eithaf bach, a’r SHDs hyn, sy’n dryloyw i’n rhesymeg anfon, h.y. i'n nginx neu unrhyw un arall gyflwyno ceisiadau am y lluniau hyn.
Roedd gan y penderfyniad hwn fanteision amlwg. SHD yw hwn. Ei nod yw storio lluniau. Mae hyn yn rhatach na dim ond rhoi gyriannau caled i beiriannau.
Ail plws.
Hyn yw bod y capasiti wedi dod yn llawer mwy, h.y. gallwn ddarparu ar gyfer llawer mwy o storio mewn cyfaint llawer llai.
Ond roedd anfanteision hefyd a ddaeth i'r amlwg yn eithaf cyflym. Wrth i nifer y defnyddwyr a'r llwyth ar y system hon dyfu, dechreuodd problemau perfformiad godi. Ac mae'r broblem yma yn eithaf amlwg - mae unrhyw SHD sydd wedi'i gynllunio i storio llawer o luniau mewn cyfaint fach, fel rheol, yn dioddef o ddarllen dwys. Mae hyn mewn gwirionedd yn wir am unrhyw storfa cwmwl neu unrhyw beth arall. Nawr nid oes gennym storfa ddelfrydol a fyddai'n anfeidrol scalable, fe allech chi stwffio unrhyw beth i mewn iddo, a byddai'n goddef darlleniadau yn dda iawn. Yn enwedig darlleniadau achlysurol.
Fel sy'n wir am ein lluniau, oherwydd gofynnir am luniau yn anghyson, a bydd hyn yn effeithio'n fawr ar eu perfformiad.
Hyd yn oed yn ôl ffigurau heddiw, os byddwn yn cyrraedd rhywle mwy na 500 RPS ar gyfer lluniau ar beiriant y mae storfa wedi'i gysylltu ag ef, mae problemau eisoes yn dechrau. Ac roedd yn ddigon drwg i ni, oherwydd bod nifer y defnyddwyr yn cynyddu, mae pethau ond yn mynd i waethygu. Mae angen optimeiddio hyn rywsut.
Er mwyn gwneud y gorau, fe benderfynon ni ar yr adeg honno, yn amlwg, edrych ar y proffil llwyth - beth, yn gyffredinol, sy'n digwydd, beth sydd angen ei optimeiddio.
Ac yma mae popeth yn chwarae yn ein dwylo ni.
Dywedais eisoes yn y sleid gyntaf: mae gennym 80 mil o geisiadau darllen yr eiliad gyda dim ond 3,5 miliwn o uwchlwythiadau bob dydd. Hynny yw, mae hwn yn wahaniaeth o dri gorchymyn maint. Mae'n amlwg bod angen optimeiddio darllen ac mae'n ymarferol glir sut.
Mae un pwynt bach arall. Mae manylion y gwasanaeth yn golygu bod person yn cofrestru, yn uwchlwytho llun, yna'n dechrau edrych yn weithredol ar bobl eraill, fel nhw, ac yn cael ei ddangos yn weithredol i bobl eraill. Yna mae'n dod o hyd i gymar neu nid yw'n dod o hyd i gymar, mae'n dibynnu sut mae'n troi allan, ac yn rhoi'r gorau i ddefnyddio'r gwasanaeth am ychydig. Ar hyn o bryd, pan fydd yn ei ddefnyddio, mae ei luniau'n boeth iawn - mae galw amdanynt, mae llawer o bobl yn eu gweld. Cyn gynted ag y bydd yn rhoi'r gorau i wneud hyn, yn eithaf cyflym mae'n gadael cymaint o gysylltiad â phobl eraill ag yr oedd o'r blaen, ac ni ofynnir am ei luniau bron byth.
Y rhai. Mae gennym set ddata boeth fach iawn. Ond ar yr un pryd mae yna lawer o geisiadau amdano. Ac ateb hollol amlwg yma yw ychwanegu storfa.
Bydd storfa gyda LRU yn datrys ein holl broblemau. Beth ydym ni'n ei wneud?
Rydyn ni'n ychwanegu un cymharol fach arall o flaen ein clwstwr mawr gyda storfa, a elwir yn ffotocaches. Yn ei hanfod, dim ond dirprwy caching yw hwn.
Sut mae'n gweithio o'r tu mewn? Dyma ein defnyddiwr, dyma storio. Mae popeth yr un fath ag o'r blaen. Beth ydyn ni'n ei ychwanegu rhyngddynt?
Dim ond peiriant gyda disg lleol corfforol ydyw, sy'n gyflym. Mae hyn gydag SSD, er enghraifft. Ac mae rhyw fath o storfa leol yn cael ei storio ar y ddisg hon.
Beth mae'n edrych fel? Mae'r defnyddiwr yn anfon cais am lun. Mae NGINX yn edrych amdano yn gyntaf yn y storfa leol. Os na, yna yn syml proxy_pass i'n storfa, lawrlwythwch y llun oddi yno a'i roi i'r defnyddiwr.
Ond mae'r un hon yn banal iawn ac nid yw'n glir beth sy'n digwydd y tu mewn. Mae'n gweithio rhywbeth fel hyn.
Rhennir y storfa yn rhesymegol yn dair haen. Pan fyddaf yn dweud “tair haen”, nid yw hyn yn golygu bod rhyw fath o system gymhleth. Na, yn amodol dim ond tri chyfeirlyfr yw'r rhain yn y system ffeiliau:
- Mae hwn yn glustog lle mae lluniau newydd eu llwytho i lawr o ddirprwy yn mynd.
- Mae hwn yn storfa boeth sy'n storio lluniau y gofynnwyd amdanynt yn weithredol ar hyn o bryd.
- A storfa oer, lle mae lluniau'n cael eu gwthio allan o'r storfa boeth yn raddol pan ddaw llai o geisiadau atynt.
Er mwyn i hyn weithio, mae angen i ni reoli'r storfa hon rywsut, mae angen i ni aildrefnu'r lluniau ynddo, ac ati. Mae hon hefyd yn broses gyntefig iawn.
Yn syml, mae Nginx yn ysgrifennu at RAMDisk access.log ar gyfer pob cais, lle mae'n nodi'r llwybr i'r llun y mae wedi'i wasanaethu ar hyn o bryd (llwybr cymharol, wrth gwrs), a pha raniad y cafodd ei weini. Y rhai. gall ddweud “llun 1” ac yna naill ai byffer, neu storfa boeth, neu storfa oer, neu ddirprwy.
Yn dibynnu ar hyn, mae angen i ni rywsut benderfynu beth i'w wneud gyda'r llun.
Mae gennym ellyll bach yn rhedeg ar bob peiriant sy'n darllen y log hwn yn gyson ac yn storio ystadegau ar y defnydd o ffotograffau penodol yn ei gof.
Yn syml, mae'n casglu yno, yn cadw'r cownteri ac yn gwneud y canlynol o bryd i'w gilydd. Mae'n symud lluniau y gofynnwyd amdanynt yn weithredol, y daw llawer o geisiadau amdanynt, i'r storfa boeth, ble bynnag y bônt.
Mae lluniau y gofynnir amdanynt yn anaml ac y gofynnir amdanynt yn llai aml yn cael eu gwthio allan yn raddol o'r storfa boeth i'r un oer.
A phan fyddwn ni'n rhedeg allan o le yn y storfa, rydyn ni'n dechrau dileu popeth o'r storfa oer yn ddiwahân. A gyda llaw, mae hyn yn gweithio'n dda.
Er mwyn i'r llun gael ei gadw ar unwaith wrth ei ddirprwyo i'r byffer, rydym yn defnyddio'r gyfarwyddeb proxy_store ac mae'r byffer hefyd yn RAMDisk, h.y. ar gyfer y defnyddiwr mae'n gweithio'n gyflym iawn. Mae hyn yn ymwneud â mewnol y gweinydd caching ei hun.
Y cwestiwn sy'n weddill yw sut i ddosbarthu ceisiadau ar draws y gweinyddwyr hyn.
Gadewch i ni ddweud bod clwstwr o ugain o beiriannau storio a thri gweinydd caching (dyma sut y digwyddodd).
Mae angen i ni rywsut benderfynu pa geisiadau yw pa luniau a ble i'w glanio.
Yr opsiwn mwyaf cyffredin yw Round Robin. Neu ei wneud ar ddamwain?
Mae'n amlwg bod gan hyn nifer o anfanteision oherwydd byddem yn defnyddio'r storfa yn aneffeithlon iawn mewn sefyllfa o'r fath. Bydd ceisiadau yn glanio ar rai peiriannau ar hap: yma cafodd ei storio, ond ar yr un nesaf nid yw yno mwyach. Ac os bydd hyn i gyd yn gweithio, bydd yn ddrwg iawn. Hyd yn oed gyda nifer fach o beiriannau yn y clwstwr.
Mae angen i ni rywsut benderfynu'n ddiamwys pa weinydd i lanio pa gais.
Mae yna ffordd banal. Rydyn ni'n cymryd yr hash o'r URL neu'r hash o'n bysell rhwygo, sydd yn yr URL, ac yn ei rannu â nifer y gweinyddwyr. Bydd yn gweithio? Bydd.
Y rhai. Mae gennym gais 2%, er enghraifft, ar gyfer rhai “example_url” bydd bob amser yn glanio ar y gweinydd gyda mynegai “XNUMX”, a bydd y storfa yn cael ei waredu'n gyson orau â phosibl.
Ond mae problem gydag ad-dalu mewn cynllun o'r fath. Resharding - rwy'n golygu newid nifer y gweinyddwyr.
Gadewch i ni dybio na all ein clwstwr caching ymdopi mwyach a phenderfynwn ychwanegu peiriant arall.
Gadewch i ni ychwanegu.
Nawr mae popeth yn rhanadwy nid gan dri, ond gan bedwar. Felly, bron pob un o'r allweddi yr oedd gennym ni'n arfer eu cael, mae bron pob URL bellach yn byw ar weinyddion eraill. Roedd y storfa gyfan yn annilys am eiliad yn unig. Syrthiodd pob cais ar ein clwstwr storio, aeth yn sâl, methiant gwasanaeth a defnyddwyr anfodlon. Dydw i ddim eisiau gwneud hynny.
Nid yw'r opsiwn hwn yn addas i ni ychwaith.
Hynny. beth ddylem ni ei wneud? Mae'n rhaid i ni rywsut wneud defnydd effeithlon o'r storfa, glanio'r un cais ar yr un gweinydd dro ar ôl tro, ond bod yn wrthwynebol i ailseilio. Ac mae datrysiad o'r fath, nid yw mor gymhleth â hynny. Mae'n cael ei alw'n stwnsio cyson.
Beth mae'n edrych fel?
Rydym yn cymryd rhywfaint o swyddogaeth o'r allwedd sharding ac yn lledaenu ei holl werthoedd ar y cylch. Y rhai. ar bwynt 0, mae ei werthoedd isaf ac uchaf yn cydgyfeirio. Nesaf, rydyn ni'n gosod ein holl weinyddion ar yr un cylch yn fras fel hyn:
Mae pob gweinydd yn cael ei ddiffinio gan un pwynt, ac mae'r sector sy'n mynd clocwedd iddo, yn unol â hynny, yn cael ei wasanaethu gan y gwesteiwr hwn. Pan ddaw ceisiadau atom, gwelwn ar unwaith, er enghraifft, cais A - mae ganddo hash yno - ac fe'i gwasanaethir gan weinydd 2. Cais B - gan weinydd 3. Ac yn y blaen.
Beth sy'n digwydd yn y sefyllfa hon yn ystod ailseilio?
Nid ydym yn annilysu'r storfa gyfan, fel o'r blaen, ac nid ydym yn symud yr holl allweddi, ond rydym yn symud pob sector bellter byr fel bod, yn gymharol siarad, ein chweched gweinydd, yr ydym am ei ychwanegu, yn ffitio i'r gofod rhydd, a rydym yn ei ychwanegu yno.
Wrth gwrs, mewn sefyllfa o'r fath mae'r allweddi hefyd yn symud allan. Ond maent yn symud allan yn llawer gwannach nag o'r blaen. A gwelwn fod ein dwy allwedd gyntaf yn aros ar eu gweinyddwyr, a dim ond ar gyfer yr allwedd olaf y newidiodd y gweinydd caching. Mae hyn yn gweithio'n eithaf effeithlon, ac os ydych chi'n ychwanegu gwesteiwyr newydd yn gynyddrannol, yna nid oes problem fawr yma. Rydych chi'n ychwanegu ac yn ychwanegu ychydig ar y tro, yn aros nes bod y storfa'n llawn eto, ac mae popeth yn gweithio'n dda.
Erys yr unig gwestiwn gyda gwrthodiadau. Gadewch i ni dybio bod rhyw fath o gar allan o drefn.
Ac ni fyddem wir eisiau adfywio'r map hwn ar hyn o bryd, annilysu rhan o'r storfa, ac yn y blaen, pe bai'r peiriant, er enghraifft, yn cael ei ailgychwyn, a bod angen i ni wneud ceisiadau gwasanaeth rywsut. Yn syml, rydyn ni'n cadw un storfa ffotograffau wrth gefn ym mhob safle, sy'n gweithredu yn lle unrhyw beiriant sydd i lawr ar hyn o bryd. Ac os na fydd un o'n gweinyddion ar gael yn sydyn, mae'r traffig yn mynd yno. Yn naturiol, nid oes gennym unrhyw storfa yno, h.y. mae'n oer, ond o leiaf mae ceisiadau defnyddwyr yn cael eu prosesu. Os mai cyfnod byr yw hwn, yna rydym yn ei brofi'n gwbl dawel. Dim ond mwy o lwyth sydd ar storio. Os yw'r cyfwng hwn yn hir, yna gallwn wneud penderfyniad yn barod - i dynnu'r gweinydd hwn o'r map ai peidio, neu efallai amnewid un arall.
Mae hyn yn ymwneud â'r system caching. Gadewch i ni edrych ar y canlyniadau.
Mae'n ymddangos nad oes dim byd cymhleth yma. Ond rhoddodd y dull hwn o reoli'r storfa gyfradd tric i ni o tua 98%. Y rhai. o'r 80 mil o geisiadau hyn yr eiliad, dim ond 1600 sy'n cyrraedd storfa, ac mae hwn yn lwyth hollol normal, maen nhw'n ei ddioddef yn dawel, mae gennym ni bob amser wrth gefn.
Gosodwyd y gweinyddion hyn mewn tri o'n DCs, a chawsom dri phwynt presenoldeb - Prague, Miami a Hong Kong.
Hynny. maent fwy neu lai wedi'u lleoli'n lleol i bob un o'n marchnadoedd targed.
Ac fel bonws braf, cawsom y dirprwy caching hwn, y mae'r CPU yn segur mewn gwirionedd, oherwydd nid oes ei angen cymaint i wasanaethu cynnwys. Ac yno, gan ddefnyddio NGINX + Lua, fe wnaethom weithredu llawer o resymeg iwtilitaraidd.
Er enghraifft, gallwn arbrofi gyda webp neu jpeg blaengar (mae'r rhain yn fformatau modern effeithiol), gweld sut mae'n effeithio ar draffig, gwneud rhai penderfyniadau, ei alluogi ar gyfer rhai gwledydd, ac ati; gwneud newid maint deinamig neu docio lluniau ar y hedfan.
Mae hwn yn achos defnydd da pan, er enghraifft, mae gennych raglen symudol sy'n dangos lluniau, ac nid yw'r cymhwysiad symudol eisiau gwastraffu CPU y cleient wrth ofyn am lun mawr ac yna ei newid maint i faint penodol er mwyn ei wthio i mewn. yr olygfa. Yn syml, gallwn nodi rhai paramedrau yn URL amodol UPort yn ddeinamig, a bydd y storfa ffotograffau yn newid maint y llun ei hun. Fel rheol, bydd yn dewis y maint sydd gennym yn gorfforol ar y ddisg, mor agos â phosibl at yr un y gofynnwyd amdano, a'i werthu i lawr mewn cyfesurynnau penodol.
Gyda llaw, rydym wedi sicrhau bod recordiadau fideo ar gael yn gyhoeddus o bum mlynedd olaf y gynhadledd i ddatblygwyr systemau llwyth uchel. . Gwylio, dysgu, rhannu a thanysgrifio i .
Gallwn hefyd ychwanegu llawer o resymeg cynnyrch yno. Er enghraifft, gallwn ychwanegu dyfrnodau gwahanol gan ddefnyddio paramedrau URL, gallwn niwlio, niwlio neu picseleiddio lluniau. Dyma pryd rydyn ni eisiau dangos llun o berson, ond nid ydym am ddangos ei wyneb, mae hyn yn gweithio'n dda, mae'r cyfan wedi'i weithredu yma.
Beth gawson ni? Cawsom dri phwynt o bresenoldeb, cyfradd tric dda, ac ar yr un pryd nid oes gennym CPU segur ar y peiriannau hyn. Mae bellach, wrth gwrs, wedi dod yn bwysicach nag o'r blaen. Mae angen inni roi ceir cryfach i ni ein hunain, ond mae'n werth chweil.
Mae hyn yn ymwneud â dychwelyd ffotograffau. Mae popeth yma yn eithaf clir ac amlwg. Rwy'n meddwl na wnes i ddarganfod America, mae bron unrhyw CDN yn gweithio fel hyn.
Ac, yn fwyaf tebygol, efallai y bydd gan wrandäwr soffistigedig gwestiwn: beth am newid popeth i CDN yn unig? Byddai tua'r un peth; gall pob CDN modern wneud hyn. Ac mae yna nifer o resymau.
Y cyntaf yw ffotograffau.
Dyma un o bwyntiau allweddol ein seilwaith, ac mae arnom angen cymaint o reolaeth drosto â phosibl. Os yw hyn yn rhyw fath o ateb gan werthwr trydydd parti, ac nad oes gennych unrhyw bŵer drosto, bydd yn eithaf anodd i chi fyw gydag ef pan fydd gennych set ddata fawr, a phan fydd gennych lif mawr iawn. o geisiadau defnyddwyr.
Gadewch imi roi enghraifft ichi. Nawr, gyda'n seilwaith, gallwn, er enghraifft, rhag ofn rhai problemau neu gnocio tanddaearol, fynd at y peiriant a llanast o gwmpas yno, yn gymharol siarad. Gallwn ychwanegu'r casgliad o rai metrigau sydd eu hangen arnom yn unig, gallwn arbrofi rhywsut, gweld sut mae hyn yn effeithio ar y graffiau, ac ati. Nawr mae llawer o ystadegau'n cael eu casglu ar y clwstwr caching hwn. Ac rydym yn edrych arno o bryd i'w gilydd ac yn treulio amser hir yn archwilio rhai anghysondebau. Pe bai ar yr ochr CDN, byddai'n llawer anoddach ei reoli. Neu, er enghraifft, os bydd rhyw fath o ddamwain yn digwydd, rydyn ni'n gwybod beth ddigwyddodd, rydyn ni'n gwybod sut i fyw ag ef a sut i'w goresgyn. Dyma'r casgliad cyntaf.
Mae'r ail gasgliad hefyd braidd yn hanesyddol, oherwydd mae'r system wedi bod yn datblygu ers amser maith, ac roedd llawer o wahanol ofynion busnes ar wahanol gamau, ac nid ydynt bob amser yn cyd-fynd â'r cysyniad CDN.
A'r pwynt sy'n dilyn o'r un blaenorol yw
Mae hyn oherwydd bod gennym ni lawer o resymeg benodol ar storfa ffotograffau, na ellir ei hychwanegu bob amser ar gais. Mae'n annhebygol y bydd unrhyw CDN yn ychwanegu rhai pethau arferol atoch ar eich cais. Er enghraifft, amgryptio URLs os nad ydych am i'r cleient allu newid rhywbeth. Ydych chi am newid yr URL ar y gweinydd a'i amgryptio, ac yna anfon rhai paramedrau deinamig yma.
Pa gasgliad mae hyn yn ei awgrymu? Yn ein hachos ni, nid yw CDN yn ddewis arall da iawn.
Ac yn eich achos chi, os oes gennych unrhyw ofynion busnes penodol, yna gallwch chi weithredu'r hyn a ddangosais i chi'ch hun yn eithaf hawdd. A bydd hyn yn gweithio'n berffaith gyda phroffil llwyth tebyg.
Ond os oes gennych chi ryw fath o ateb cyffredinol, ac nad yw'r dasg yn benodol iawn, gallwch chi gymryd CDN yn gwbl ddiogel. Neu os yw amser ac adnoddau yn bwysicach i chi na rheolaeth.
Ac mae gan CDNs modern bron popeth y dywedais wrthych amdano nawr. Ac eithrio plws neu finws rhai nodweddion.
Mae hyn yn ymwneud â rhoi lluniau i ffwrdd.
Gadewch i ni nawr symud ymlaen ychydig yn ein hôl-weithredol a siarad am storio.
Roedd 2013 yn mynd heibio.
Ychwanegwyd gweinyddwyr caching, aeth problemau perfformiad i ffwrdd. Mae popeth yn iawn. Set ddata yn tyfu. O 2013 ymlaen, roedd gennym tua 80 o weinyddion wedi'u cysylltu â storfa, a thua 40 o rai caching ym mhob DC. Mae hyn yn 560 terabytes o ddata ar bob DC, h.y. tua phetabyte i gyd.
A chyda thwf y set ddata, dechreuodd costau gweithredu godi'n sylweddol. Beth oedd hyn yn ei olygu?
Yn y diagram hwn sy'n cael ei dynnu - gyda SAN, gyda pheiriannau a caches wedi'u cysylltu ag ef - mae yna lawer o bwyntiau o fethiant. Pe baem eisoes wedi delio â methiant gweinyddwyr caching o'r blaen, roedd popeth yn fwy neu lai yn rhagweladwy ac yn ddealladwy, ond ar yr ochr storio roedd popeth yn waeth o lawer.
Yn gyntaf, y Rhwydwaith Ardal Storio (SAN) ei hun, a all fethu.
Yn ail, mae wedi'i gysylltu trwy opteg i'r peiriannau diwedd. Efallai y bydd problemau gyda chardiau optegol a phlygiau tanio.
Wrth gwrs, nid oes cymaint ohonyn nhw â'r SAN ei hun, ond, serch hynny, mae'r rhain hefyd yn bwyntiau o fethiant.
Nesaf yw'r peiriant ei hun, sydd wedi'i gysylltu â'r storfa. Gall hefyd fethu.
Yn gyfan gwbl, mae gennym dri phwynt o fethiant.
Ymhellach, yn ogystal â phwyntiau methiant, mae llawer o waith cynnal a chadw ar y storfa ei hun.
Mae hon yn system aml-gydran gymhleth, a gall peirianwyr systemau gael amser caled yn gweithio gyda hi.
A'r pwynt olaf, pwysicaf. Os bydd methiant yn digwydd ar unrhyw un o'r tri phwynt hyn, mae gennym siawns nad yw'n sero o golli data defnyddwyr oherwydd gallai'r system ffeiliau chwalu.
Gadewch i ni ddweud bod ein system ffeiliau wedi torri. Yn gyntaf, mae ei adferiad yn cymryd amser hir - gall gymryd wythnos gyda llawer iawn o ddata. Ac yn ail, yn y diwedd mae'n debyg y bydd gennym ni griw o ffeiliau annealladwy y bydd angen eu cyfuno rywsut i luniau defnyddwyr. Ac rydym mewn perygl o golli data. Mae'r risg yn eithaf uchel. A pho fwyaf aml y bydd sefyllfaoedd o'r fath yn digwydd, a pho fwyaf o broblemau sy'n codi yn y gadwyn gyfan hon, yr uchaf yw'r risg hon.
Roedd yn rhaid gwneud rhywbeth am hyn. Ac fe benderfynon ni mai'r cyfan sydd angen i ni ei wneud yw gwneud copi wrth gefn o'r data. Mae hwn mewn gwirionedd yn ateb amlwg ac yn un da. Beth ydyn ni wedi'i wneud?
Dyma sut olwg oedd ar ein gweinydd pan oedd wedi'i gysylltu â storfa o'r blaen. Dyma un prif adran, dim ond dyfais bloc ydyw sydd mewn gwirionedd yn cynrychioli mownt ar gyfer storio o bell trwy opteg.
Rydym newydd ychwanegu ail adran.
Fe wnaethon ni osod ail storfa wrth ei ymyl (yn ffodus, nid yw mor ddrud â hynny o ran arian), a'i alw'n raniad wrth gefn. Mae hefyd wedi'i gysylltu trwy opteg ac mae wedi'i leoli ar yr un peiriant. Ond mae angen inni rywsut gysoni'r data rhyngddynt.
Yma rydym yn syml yn gwneud ciw asyncronaidd gerllaw.
Dyw hi ddim yn brysur iawn. Rydyn ni'n gwybod nad oes gennym ni ddigon o gofnodion. Dim ond tabl yn MySQL yw ciw lle mae llinellau fel “mae angen i chi wneud copi wrth gefn o'r llun hwn” yn cael eu hysgrifennu. Gydag unrhyw newid neu uwchlwythiad, rydyn ni'n copïo o'r prif raniad i'r copi wrth gefn gan ddefnyddio gweithiwr cefndir anghydamserol neu ryw fath o weithiwr cefndir yn unig.
Ac felly mae gennym bob amser ddwy adran gyson. Hyd yn oed os bydd un rhan o'r system hon yn methu, gallwn bob amser newid y prif raniad gyda chopi wrth gefn, a bydd popeth yn parhau i weithio.
Ond oherwydd hyn, mae'r llwyth darllen yn cynyddu'n fawr, oherwydd ... yn ogystal â chleientiaid sy'n darllen o'r brif adran, oherwydd maen nhw'n edrych ar y llun yno yn gyntaf (mae'n fwy diweddar yno), ac yna'n edrych amdano ar y copi wrth gefn, os nad ydyn nhw wedi dod o hyd iddo (ond mae NGINX yn gwneud hyn), mae ein system hefyd yn fwy wrth gefn bellach yn darllen o'r prif raniad. Nid bod hyn yn dagfa, ond nid oeddwn am gynyddu'r llwyth, yn y bôn, yn union fel hynny.
Ac fe wnaethom ychwanegu trydydd disg, sef SSD bach, a'i alw'n glustog.
Sut mae'n gweithio nawr.
Mae'r defnyddiwr yn uwchlwytho llun i'r byffer, yna mae digwyddiad yn cael ei daflu i'r ciw gan nodi bod angen ei gopïo'n ddwy adran. Mae'n cael ei gopïo, ac mae'r llun yn byw ar y byffer am beth amser (dyweder, diwrnod), a dim ond wedyn yn cael ei lanhau oddi yno. Mae hyn yn gwella profiad y defnyddiwr yn fawr, oherwydd bod y defnyddiwr yn uwchlwytho llun, fel rheol, mae ceisiadau'n dechrau dilyn ar unwaith, neu fe ddiweddarodd ef ei hun y dudalen a'i hadnewyddu. Ond mae'r cyfan yn dibynnu ar y cais sy'n gwneud y llwytho i fyny.
Neu, er enghraifft, mae pobl eraill y dechreuodd ddangos ei hun iddynt ar unwaith yn anfon ceisiadau ar ôl y llun hwn. Nid yw yn y storfa eto; mae'r cais cyntaf yn digwydd yn gyflym iawn. Yn y bôn yr un peth ag o storfa ffotograffau. Nid yw storio araf yn ymwneud â hyn o gwbl. A phan fydd yn cael ei lanhau ddiwrnod yn ddiweddarach, mae eisoes naill ai wedi'i storio ar ein haen caching, neu, yn fwyaf tebygol, nid oes ei angen ar unrhyw un mwyach. Y rhai. Mae profiad y defnyddiwr yma wedi tyfu'n dda iawn oherwydd triniaethau mor syml.
Wel, ac yn bwysicaf oll: rhoesom y gorau i golli data.
Gadewch i ni ddweud ein bod wedi stopio o bosibl colli data, oherwydd ni wnaethom ei golli mewn gwirionedd. Ond roedd perygl. Rydym yn gweld bod yr ateb hwn, wrth gwrs, yn dda, ond mae ychydig fel llyfnhau symptomau'r broblem, yn hytrach na'i datrys yn llwyr. Ac erys rhai problemau yma.
Yn gyntaf, mae hwn yn bwynt o fethiant ar ffurf y gwesteiwr ffisegol ei hun y mae'r holl beiriannau hyn yn rhedeg arno; nid yw wedi diflannu.
Yn ail, mae problemau o hyd gyda SANs, mae eu gwaith cynnal a chadw trwm, ac ati yn parhau. Nid ei fod yn ffactor hollbwysig, ond roeddwn i eisiau ceisio byw hebddo rywsut.
Ac fe wnaethom y trydydd fersiwn (mewn gwirionedd, yr ail mewn gwirionedd) - y fersiwn archebu. Sut olwg oedd arno?
Dyma beth ydoedd -
Ein prif broblemau yw'r ffaith mai gwesteiwr corfforol yw hwn.
Yn gyntaf, rydym yn cael gwared ar SANs oherwydd ein bod am arbrofi, rydym am roi cynnig ar yriannau caled lleol yn unig.
Mae hyn eisoes yn 2014-2015, ac ar y pryd daeth y sefyllfa gyda disgiau a'u gallu mewn un gwesteiwr yn llawer gwell. Fe benderfynon ni pam ddim rhoi cynnig arni.
Ac yna rydym yn syml yn cymryd ein rhaniad wrth gefn a'i drosglwyddo'n gorfforol i beiriant ar wahân.
Felly, rydym yn cael y diagram hwn. Mae gennym ddau gar sy'n storio'r un setiau data. Maent yn gwneud copi wrth gefn o'i gilydd yn gyfan gwbl ac yn cydamseru data dros y rhwydwaith trwy giw asyncronaidd yn yr un MySQL.
Y rheswm pam fod hyn yn gweithio'n dda yw mai ychydig o gofnodion sydd gennym. Y rhai. pe bai ysgrifennu yn debyg i ddarllen, efallai y byddai gennym ryw fath o orbenion rhwydwaith a phroblemau. Nid oes llawer o ysgrifennu, llawer o ddarllen - mae'r dull hwn yn gweithio'n dda, h.y. Anaml y byddwn yn copïo lluniau rhwng y ddau weinydd hyn.
Sut mae hyn yn gweithio, os edrychwch ychydig yn fwy manwl.
Llwytho i fyny. Yn syml, mae'r balancer yn dewis gwesteiwyr ar hap gyda phâr ac yn uwchlwytho iddo. Ar yr un pryd, mae'n naturiol yn gwneud gwiriadau iechyd ac yn sicrhau nad yw'r car yn cwympo allan. Y rhai. mae'n uwchlwytho lluniau i weinydd byw yn unig, ac yna trwy giw anghydamserol mae'r cyfan yn cael ei gopïo i'w gymydog. Gyda llwytho i fyny mae popeth yn hynod o syml.
Mae'r dasg ychydig yn anoddach.
Helpodd Lua ni yma, oherwydd gall fod yn anodd gwneud rhesymeg o'r fath ar fanila NGINX. Yn gyntaf, rydyn ni'n gwneud cais i'r gweinydd cyntaf, i weld a yw'r llun yno, oherwydd mae'n bosibl y gellid ei uwchlwytho, er enghraifft, i gymydog, ond nid yw wedi cyrraedd yma eto. Os yw'r llun yno, mae hynny'n dda. Rydyn ni'n ei roi ar unwaith i'r cleient ac, o bosibl, yn ei storio.
Os nad yw yno, rydym yn gwneud cais i'n cymydog ac yn sicr o'i dderbyn oddi yno.
Hynny. eto gallwn ddweud: efallai y bydd problemau gyda pherfformiad, oherwydd mae teithiau crwn cyson - uwchlwythwyd y llun, nid yw yma, rydym yn gwneud dau gais yn lle un, dylai hyn weithio'n araf.
Yn ein sefyllfa ni, nid yw hyn yn gweithio'n araf.
Rydym yn casglu criw o fetrigau ar y system hon, ac mae cyfradd smart amodol mecanwaith o'r fath tua 95%. Y rhai. Mae oedi'r copi wrth gefn hwn yn fach, ac oherwydd hyn rydym bron yn sicr, ar ôl i'r llun gael ei uwchlwytho, byddwn yn ei godi y tro cyntaf ac ni fydd yn rhaid i ni fynd i unman ddwywaith.
Felly beth arall sydd gennym ni sy'n cŵl iawn?
Yn flaenorol, roedd gennym y prif raniad wrth gefn, a darllenasom ohonynt yn ddilyniannol. Y rhai. Roeddem bob amser yn chwilio ar y prif un yn gyntaf, ac yna ar y copi wrth gefn. Un symudiad ydoedd.
Nawr rydym yn defnyddio darllen o ddau beiriant ar unwaith. Rydym yn dosbarthu ceisiadau gan ddefnyddio Rownd Robin. Mewn canran fechan o achosion rydym yn gwneud dau gais. Ond yn gyffredinol, mae gennym ni nawr ddwywaith cymaint o stoc darllen ag oedd gennym ni o'r blaen. A gostyngwyd y llwyth yn fawr ar y peiriannau anfon ac yn uniongyrchol ar y peiriannau storio, a oedd gennym ar y pryd hefyd.
Fel ar gyfer goddefgarwch fai. A dweud y gwir, dyma'r hyn y buom yn brwydro amdano'n bennaf. Gyda goddefgarwch bai, trodd popeth allan yn wych yma.
Mae un car yn torri i lawr.
Dim problem! Efallai na fydd peiriannydd system hyd yn oed yn deffro yn y nos, bydd yn aros tan y bore, ni fydd dim byd drwg yn digwydd.
Os hyd yn oed os bydd y peiriant hwn yn methu, mae'r ciw allan o drefn, nid oes unrhyw broblemau ychwaith, bydd y log yn cael ei gronni yn gyntaf ar y peiriant byw, ac yna bydd yn cael ei ychwanegu at y ciw, ac yna ymlaen i'r car a fydd. mynd i weithrediad ar ôl peth amser.
Yr un peth gyda chynnal a chadw. Yn syml, rydyn ni'n diffodd un o'r peiriannau, yn ei dynnu allan o'r holl byllau â llaw, mae'n atal derbyn traffig, rydyn ni'n gwneud rhyw fath o waith cynnal a chadw, rydyn ni'n golygu rhywbeth, yna rydyn ni'n ei ddychwelyd i'r gwasanaeth, ac mae'r copi wrth gefn hwn yn dal i fyny yn eithaf cyflym. Y rhai. y dydd, mae amser segur un car yn dal i fyny o fewn ychydig funudau. Ychydig iawn yw hyn mewn gwirionedd. Gyda goddefgarwch bai, dywedaf eto, mae popeth yn cŵl yma.
Pa gasgliadau y gellir eu tynnu o'r cynllun dileu swyddi hwn?
Cawsom goddefgarwch bai.
Hawdd i'w defnyddio. Gan fod gan y peiriannau yriannau caled lleol, mae hyn yn llawer mwy cyfleus o safbwynt gweithredol i'r peirianwyr sy'n gweithio gydag ef.
Cawsom lwfans darllen dwbl.
Mae hwn yn fonws da iawn yn ogystal â goddefgarwch namau.
Ond mae yna broblemau hefyd. Nawr mae gennym ddatblygiad llawer mwy cymhleth o rai nodweddion sy'n gysylltiedig â hyn, oherwydd bod y system wedi dod yn 100% yn gyson yn y pen draw.
Rhaid i ni, dyweder, mewn rhyw swydd gefndir, feddwl yn gyson: “Pa weinydd rydyn ni'n rhedeg arno nawr?”, “A oes llun cyfredol yma mewn gwirionedd?” etc. Mae hyn, wrth gwrs, wedi'i lapio i gyd, ac i'r rhaglennydd sy'n ysgrifennu rhesymeg busnes, mae'n dryloyw. Ond, serch hynny, mae'r haen gymhleth fawr hon wedi ymddangos. Ond yr ydym yn barod i oddef hyn yn gyfnewid am y nwyddau a gawsom ganddo.
Ac yma eto mae rhywfaint o wrthdaro yn codi.
Dywedais ar y dechrau bod storio popeth ar yriannau caled lleol yn ddrwg. Ac yn awr yr wyf yn dweud ein bod yn ei hoffi.
Ydy, yn wir, dros amser mae'r sefyllfa wedi newid llawer, ac yn awr mae gan y dull hwn lawer o fanteision. Yn gyntaf, rydym yn cael gweithrediad llawer symlach.
Yn ail, mae'n fwy cynhyrchiol, oherwydd nid oes gennym y rheolwyr awtomatig na'r cysylltiadau hyn â silffoedd disg.
Mae yna lawer iawn o beiriannau yno, a dim ond ychydig o ddisgiau yw'r rhain sy'n cael eu cydosod yma ar y peiriant i mewn i gyrch.
Ond mae yna anfanteision hefyd.
Mae hyn tua 1,5 gwaith yn ddrytach na defnyddio SANs hyd yn oed ar brisiau heddiw. Felly, fe wnaethom benderfynu peidio â throsi ein clwstwr mawr cyfan yn eofn yn geir gyda gyriannau caled lleol a phenderfynwyd gadael datrysiad hybrid.
Mae hanner ein peiriannau'n gweithio gyda gyriannau caled (wel, nid hanner - 30 y cant yn ôl pob tebyg). Ac mae'r gweddill yn hen geir a arferai gael y cynllun cadw lle cyntaf. Yn syml, fe wnaethon ni eu hail-osod, gan nad oedd angen data newydd na dim byd arall arnom, yn syml fe wnaethom symud y mowntiau o un gwesteiwr ffisegol i ddau.
Ac mae gennym ni nawr stoc fawr o ddarllen, ac fe wnaethon ni ei ehangu. Os yn gynharach rydym wedi gosod un storfa ar un peiriant, nawr rydym yn gosod pedwar, er enghraifft, ar un pâr. Ac mae'n gweithio'n iawn.
Gadewch i ni gymryd crynodeb byr o'r hyn a gyflawnwyd gennym, yr hyn y buom yn ymladd drosto, ac a wnaethom lwyddo.
Canlyniadau
Mae gennym ddefnyddwyr - cymaint â 33 miliwn.
Mae gennym dri phwynt o bresenoldeb - Prague, Miami, Hong Kong.
Maent yn cynnwys haen caching, sy'n cynnwys ceir gyda disgiau lleol cyflym (SSDs), y mae peiriannau syml o NGINX, ei access.log a daemons Python yn rhedeg, sy'n prosesu hyn i gyd ac yn rheoli'r storfa.
Os dymunwch, rydych yn eich prosiect, os nad yw lluniau mor hanfodol i chi ag y maent i ni, neu os yw rheolaeth cyfaddawdu yn erbyn cyflymder datblygu a chostau adnoddau i'r cyfeiriad arall i chi, yna gallwch chi gael rhai newydd yn eu lle yn ddiogel. gyda CDN, mae CDNs modern yn gwneud yn dda.
Nesaf daw'r haen storio, lle mae gennym glystyrau o barau o beiriannau sy'n gwneud copi wrth gefn o'i gilydd, mae ffeiliau'n cael eu copïo'n asyncronig o un i'r llall pryd bynnag y byddant yn newid.
At hynny, mae rhai o'r peiriannau hyn yn gweithio gyda gyriannau caled lleol.
Mae rhai o'r peiriannau hyn wedi'u cysylltu â SANs.
Ac, ar y naill law, mae'n fwy cyfleus i'w ddefnyddio ac ychydig yn fwy cynhyrchiol, ar y llaw arall, mae'n gyfleus o ran dwysedd lleoliad a phris fesul gigabeit.
Dyma drosolwg mor gryno o bensaernïaeth yr hyn a gawsom a sut y datblygodd y cyfan.
Ychydig mwy o awgrymiadau gan y capten, rhai syml iawn.
Yn gyntaf, os penderfynwch yn sydyn fod angen i chi wella popeth yn eich seilwaith lluniau ar frys, mesurwch yn gyntaf, oherwydd efallai nad oes angen gwella dim.
Gadewch imi roi enghraifft ichi. Mae gennym glwstwr o beiriannau sy’n anfon lluniau o atodiadau mewn sgyrsiau, ac mae’r cynllun wedi bod yn gweithio yno ers 2009, ac nid oes neb yn dioddef ohono. Mae pawb yn iawn, mae pawb yn hoffi popeth.
Er mwyn mesur, hongian criw o fetrigau yn gyntaf, edrychwch arnyn nhw, ac yna penderfynwch beth rydych chi'n anhapus ag ef a beth sydd angen ei wella. Er mwyn mesur hyn, mae gennym offeryn cŵl o'r enw Pinba.
Mae'n caniatáu ichi gasglu ystadegau manwl iawn gan NGINX ar gyfer pob cais ac ymateb codau, a dosbarthiad amseroedd - beth bynnag y dymunwch. Mae ganddo rwymiadau i bob math o systemau dadansoddi gwahanol, ac yna gallwch chi edrych ar y cyfan yn hyfryd.
Yn gyntaf fe wnaethon ni ei fesur, yna fe wnaethon ni ei wella.
Ymhellach. Rydyn ni'n gwneud y gorau o ddarllen gyda storfa, yn ysgrifennu gyda darnio, ond mae hwn yn bwynt amlwg.
Ymhellach. Os ydych chi newydd ddechrau adeiladu'ch system, yna mae'n llawer gwell gwneud lluniau fel ffeiliau na ellir eu cyfnewid. Oherwydd eich bod yn colli dosbarth cyfan o broblemau ar unwaith gydag annilysu cache, gyda sut y dylai'r rhesymeg ddod o hyd i'r fersiwn gywir o'r llun, ac ati.
Gadewch i ni ddweud ichi uwchlwytho cant, yna ei gylchdroi, ei wneud fel ei bod yn ffeil gorfforol wahanol. Y rhai. dim angen meddwl: nawr byddaf yn arbed ychydig o le, yn ei ysgrifennu i'r un ffeil, yn newid y fersiwn. Nid yw hyn bob amser yn gweithio'n dda ac mae'n achosi llawer o gur pen yn ddiweddarach.
Pwynt nesaf. Ynglŷn â newid maint ar y hedfan.
Yn flaenorol, pan oedd defnyddwyr yn uwchlwytho llun, fe wnaethom dorri criw cyfan o feintiau ar unwaith ar gyfer pob achlysur, ar gyfer gwahanol gleientiaid, ac roeddent i gyd ar y ddisg. Nawr rydym wedi rhoi'r gorau i hyn.
Dim ond tri phrif faint a adawsom: bach, canolig a mawr. Yn syml, rydyn ni'n lleihau popeth arall o'r maint sydd y tu ôl i'r un y gofynnwyd i ni yn Uport, rydyn ni'n gwneud yr israddio ac yn ei roi i'r defnyddiwr.
Mae CPU yr haen caching yma yn llawer rhatach na phe baem yn adfywio'r meintiau hyn yn gyson ar bob storfa. Dewch i ni ddweud ein bod ni eisiau ychwanegu un newydd, bydd hyn yn cymryd mis - rhedeg sgript ym mhobman a fyddai'n gwneud hyn i gyd yn daclus, heb ddinistrio'r clwstwr. Y rhai. Os cewch gyfle i ddewis nawr, mae'n well gwneud cyn lleied o feintiau ffisegol â phosibl, ond fel bod rhywfaint o ddosbarthiad, dyweder, yn dri. A gellir newid maint popeth arall ar y hedfan gan ddefnyddio modiwlau parod. Mae'r cyfan yn hawdd iawn ac yn hygyrch nawr.
Ac mae copi wrth gefn asyncronaidd cynyddrannol yn dda.
Fel y mae ein harfer wedi dangos, mae'r cynllun hwn yn gweithio'n wych gydag oedi wrth gopïo ffeiliau sydd wedi newid.
Mae'r pwynt olaf hefyd yn amlwg. Os nad oes gan eich seilwaith broblemau o'r fath yn awr, ond bod rhywbeth a all dorri, bydd yn bendant yn torri pan ddaw ychydig yn fwy. Felly, mae'n well meddwl am hyn ymlaen llaw a pheidio â chael problemau ag ef. Dyna'r cyfan roeddwn i eisiau ei ddweud.
cysylltiadau
»
»
Mae'r adroddiad hwn yn drawsgrifiad o un o'r areithiau gorau yng nghynhadledd datblygwyr systemau llwyth uchel . Mae llai na mis ar ôl tan gynhadledd HighLoad++ 2017.
Mae gennym ni eisoes yn barod , mae'r amserlen bellach yn cael ei ffurfio'n weithredol.
Eleni rydym yn parhau i archwilio pwnc pensaernïaeth a graddio:
- / Igor Vasiliev
- / Dmitry Egorov
- / Anatoly Plaskovsky
- / Rhufeinig Shekhovtsov, Alexey Gromatchikov
- / Philip Delgado
Rydym hefyd yn defnyddio rhai o'r deunyddiau hyn yn ein cwrs hyfforddi ar-lein ar ddatblygu systemau llwyth uchel yn gadwyn o lythyrau, erthyglau, deunyddiau, fideos a ddewiswyd yn arbennig. Mae ein gwerslyfr eisoes yn cynnwys mwy na 30 o ddeunyddiau unigryw. Cyswllt!
Ffynhonnell: hab.com