Af hverju gætirðu þurft hálf-samstillta afritun?

Hæ allir. Vladislav Rodin hefur samband. Ég kenni nú námskeið um hugbúnaðararkitektúr og háspennuhugbúnaðararkitektúr hjá OTUS. Í aðdraganda nýs námskeiðsstraums "Hátt álagsarkitekt" Ég ákvað að skrifa stutt stykki frumsamið efni sem mig langar að deila með ykkur.

Af hverju gætirðu þurft hálf-samstillta afritun?

Inngangur

Vegna þess að HDD getur aðeins framkvæmt um 400-700 aðgerðir á sekúndu (sem er ósambærilegt við dæmigerð rps á háhleðslukerfi) er klassíski diskagagnagrunnurinn flöskuháls arkitektúrsins. Þess vegna er nauðsynlegt að huga sérstaklega að stærðarmynstri þessarar geymslu.

Eins og er eru 2 gagnagrunnsstærðarmynstur: afritun og sundrun. Sharding gerir þér kleift að skala skrifaðgerðina og, þar af leiðandi, draga úr rps á hvern skrif á hvern netþjón í klasanum þínum. Afritun gerir þér kleift að gera það sama, en með lestraraðgerðum. Það er þetta mynstur sem þessi grein er helguð.

Afritun

Ef þú horfir á afritun á mjög háu stigi, þá er það einfaldur hlutur: þú varst með einn netþjón, það voru gögn á honum og þá gat þessi netþjónn ekki lengur ráðið við álagið við að lesa þessi gögn. Þú bætir við nokkrum netþjónum í viðbót, samstillir gögn yfir alla netþjóna og notandinn getur lesið frá hvaða netþjóni sem er í klasanum þínum.

Þrátt fyrir augljósan einfaldleika eru nokkrir möguleikar til að flokka ýmsar útfærslur á þessu kerfi:

  • Eftir hlutverkum í klasanum (meistara-meistari eða húsbóndi-þræll)
  • Eftir sendum hlutum (tengdir línur, yfirlýsingu eða blandaðir)
  • Samkvæmt samstillingarkerfi hnútsins

Í dag verður fjallað um lið 3.

Hvernig gerist viðskiptaskuldbinding?

Þetta efni er ekki beint tengt afritun; það er hægt að skrifa sérstaka grein um það, en þar sem frekari lestur er gagnslaus án þess að skilja viðskiptaskuldbindingarkerfið, leyfðu mér að minna þig á grunnatriðin. Viðskiptaskuldbinding á sér stað í 3 þrepum:

  1. Skráning færslu í gagnagrunnsskrá.
  2. Notkun færslu í gagnagrunnsvél.
  3. Skilar staðfestingu til viðskiptavinar um að viðskiptin hafi tekist.

Í mismunandi gagnagrunnum getur þetta reiknirit haft blæbrigði: til dæmis, í InnoDB vél MySQL gagnagrunnsins eru 2 annálar: einn fyrir afritun (tvíundir log) og hinn til að viðhalda ACID (afturkalla/afturkalla log), en í PostgreSQL það er einn log sem framkvæmir báðar aðgerðirnar (skrifa á undan log = WAL). En það sem er kynnt hér að ofan er einmitt almenna hugtakið, sem gerir það kleift að taka ekki tillit til slíkra blæbrigða.

Samstillt (sync) afritun

Við skulum bæta við rökfræði til að endurtaka mótteknar breytingar á reikniritinu fyrir viðskiptaskuldbindingu:

  1. Skráning færslu í gagnagrunnsskrá.
  2. Notkun færslu í gagnagrunnsvél.
  3. Sendir gögn til allra eftirmynda.
  4. Að fá staðfestingu frá öllum eftirlíkingum um að færslu hafi verið lokið á þeim.
  5. Skilar staðfestingu til viðskiptavinar um að viðskiptin hafi tekist.

Með þessari nálgun fáum við fjölda ókosta:

  • viðskiptavinurinn bíður eftir að breytingarnar verði notaðar á allar eftirmyndir.
  • eftir því sem fjöldi hnúta í þyrpingunni eykst minnkum við líkurnar á að skrifaðgerðin heppnist.

Ef allt er meira eða minna ljóst með 1. lið, þá er ástæðan fyrir 2. lið þess virði að útskýra. Ef við fáum ekki svar frá að minnsta kosti einum hnút meðan á samstilltri afritun stendur, snúum við færslunni til baka. Þannig, með því að fjölga hnútum í þyrpingunni, eykur þú líkurnar á því að skrifaðgerð mistakist.

Getum við beðið eftir staðfestingu frá aðeins ákveðnu hlutfalli hnúta, til dæmis frá 51% (ályktun)? Já, við getum það, en í klassísku útgáfunni þarf staðfestingu frá öllum hnútum, því þannig getum við tryggt fullkomið gagnasamræmi í þyrpingunni, sem er ótvíræður kostur við þessa tegund af afritun.

Ósamstilltur (ósamstilltur) afritun

Við skulum breyta fyrri reikniritinu. Við munum senda gögn til eftirmyndanna „einhvern tíma seinna“ og „einhvern tíma seinna“ verða breytingarnar beittar á eftirmyndirnar:

  1. Skráning færslu í gagnagrunnsskrá.
  2. Notkun færslu í gagnagrunnsvél.
  3. Skilar staðfestingu til viðskiptavinar um að viðskiptin hafi tekist.
  4. Að senda gögn á eftirmyndir og beita breytingum á þeim.

Þessi nálgun leiðir til þess að þyrpingin virkar hratt, vegna þess að við látum viðskiptavininn ekki bíða eftir að gögnin nái til eftirmyndanna og jafnvel skuldbindist.

En skilyrðið um að henda gögnum á eftirlíkingar „einhvern tíma seinna“ getur leitt til taps á viðskiptum og til taps á viðskiptum sem notandinn hefur staðfest, vegna þess að ef gögnin höfðu ekki tíma til að afrita, þá er það staðfesting til viðskiptavinarins. um árangur aðgerðarinnar var sent, og hnúturinn sem breytingarnar komu til hrundi HDD, við töpum viðskiptum, sem getur leitt til mjög óþægilegra afleiðinga.

Hálfsamstillt afritun

Að lokum komum við að hálf-samstilltri afritun. Þessi tegund af afritun er ekki mjög þekkt eða mjög algeng, en hún hefur töluverðan áhuga vegna þess að hún getur sameinað kosti bæði samstilltar og ósamstilltra afritunar.

Við skulum reyna að sameina 2 fyrri aðferðirnar. Við munum ekki geyma viðskiptavininn lengi, en við munum krefjast þess að gögnin séu afrituð:

  1. Skráning færslu í gagnagrunnsskrá.
  2. Notkun færslu í gagnagrunnsvél.
  3. Sendir gögn til eftirmynda.
  4. Að fá staðfestingu frá eftirmyndinni um að breytingarnar hafi borist (þeim verður beitt „einhvern tíma seinna“).
  5. Skilar staðfestingu til viðskiptavinar um að viðskiptin hafi tekist.

Vinsamlegast athugaðu að með þessu reikniriti á sér stað viðskiptatap aðeins ef bæði hnúturinn sem tekur við breytingunum og eftirmyndarhnúturinn mistakast. Líkur á slíkri bilun eru taldar litlar og viðurkennd er sú áhætta.

En með þessari nálgun er hugsanleg hætta á fantomlestri. Við skulum ímynda okkur eftirfarandi atburðarás: í skrefi 4 fengum við enga staðfestingu frá neinni eftirmynd. Við verðum að afturkalla þessa færslu og ekki skila staðfestingu til viðskiptavinarins. Þar sem gögnin voru notuð í skrefi 2 er tímabil frá lokum skrefs 2 og afturköllun færslunnar, þar sem samhliða færslur geta séð breytingar sem ættu ekki að vera í gagnagrunninum.

Tapalaus hálfsamstillt afritun

Ef þú hugsar aðeins, geturðu bara snúið við skrefum reikniritsins og lagað vandamálið með phantom lestur í þessari atburðarás:

  1. Skráning færslu í gagnagrunnsskrá.
  2. Sendir eftirmyndargögn.
  3. Að fá staðfestingu frá eftirmyndinni um að breytingarnar hafi borist (þeim verður beitt „einhvern tíma seinna“).
  4. Notkun færslu í gagnagrunnsvél.
  5. Skilar staðfestingu til viðskiptavinar um að viðskiptin hafi tekist.

Nú skuldbindum við aðeins breytingar ef þær hafa verið endurteknar.

Output

Eins og alltaf eru engar hugsjónalausnir, það er sett af lausnum, sem hver um sig hefur sína kosti og galla og hentar til að leysa mismunandi flokka vandamála. Þetta á alveg við um val á kerfi til að samstilla gögn í endurteknum gagnagrunni. Samanburðurinn af kostum sem hálf-samstilltur afritun hefur er nægilega traustur og áhugaverður til að það geti talist athyglisvert, þrátt fyrir lágt algengi.

Það er allt og sumt. Sjáumst kl námskeið!

Heimild: www.habr.com

Bæta við athugasemd