Moien alleguer. De Vladislav Rodin ass a Kontakt. Ech léieren de Moment Coursen iwwer Software Architecture an High-Stress Software Architecture bei OTUS. An Erwaardung vum Start vun engem neie Cours Stream Ech hu beschloss, e kuerzt Stéck Originalmaterial ze schreiwen, dat ech mat Iech deele wëll.
Aféierung
Wéinst der Tatsaach, datt d'HDD nëmmen ongeféier 400-700 Operatiounen pro Sekonn ausféiere kann (wat onvergläichbar ass mat typesche RPS fir e High-load System), ass déi klassesch Disk-Datebank de Flaschenhals vun der Architektur. Dofir ass et néideg speziell Opmierksamkeet op d'Skaléierungsmuster vun dëser Lagerung ze bezuelen.
De Moment ginn et 2 Datebank Skaléierungsmuster: Replikatioun a Scherp. Sharding erlaabt Iech d'Schreifoperatioun ze skaléieren, an als Resultat d'rps pro Schreiwen pro Server an Ärem Cluster reduzéieren. Replikatioun erlaabt Iech déi selwecht Saach ze maachen, awer mat Liesoperatiounen. Et ass dëst Muster un deem dësen Artikel gewidmet ass.
Replikatioun
Wann Dir d'Replikatioun op engem ganz héijen Niveau kuckt, ass et eng einfach Saach: Dir hutt ee Server, et waren Daten op et, an dann konnt dëse Server net méi mat der Laascht vun der Liesung vun dësen Donnéeën eens. Dir füügt e puer méi Serveren un, synchroniséiert Daten iwwer all Server, an de Benotzer kann vun all Server an Ärem Cluster liesen.
Trotz senger anscheinend Einfachheet ginn et e puer Méiglechkeeten fir verschidde Implementatioune vun dësem Schema ze klassifizéieren:
- Duerch Rollen am Cluster (Meeschter-Meeschter oder Meeschter-Sklave)
- Vun Objekter geschéckt (Rei-baséiert, Ausso-baséiert oder gemëscht)
- No der Node Synchroniséierung Mechanismus
Haut beschäftege mir eis mam Punkt 3.
Wéi geschitt eng Transaktiounsverpflichtung?
Dëst Thema ass net direkt mat der Replikatioun verbonnen; en getrennten Artikel kann doriwwer geschriwwe ginn, awer well weider Liesung nëtzlos ass ouni den Transaktiounsverpflichtungsmechanismus ze verstoen, loosst mech Iech un déi elementarste Saachen erënneren. Eng Transaktiounsverpflichtung geschitt an 3 Etappen:
- Logéiert eng Transaktioun an d'Datebankprotokoll.
- Benotzt eng Transaktioun an enger Datebankmotor.
- Retour Bestätegung un de Client datt d'Transaktioun erfollegräich applizéiert gouf.
A verschiddenen Datenbanken kann dësen Algorithmus Nuancen hunn: zum Beispill, am InnoDB-Motor vun der MySQL-Datebank sinn et 2 Logbicher: eent fir Replikatioun (binär Log), an deen aneren fir ACID z'erhalen (Undo / Redo Log), wärend am PostgreSQL et gëtt e Log dee béid Funktiounen ausféiert (Schreift viraus Log = WAL). Mä wat uewen duergestallt ass, ass genee d'allgemeng Konzept, déi esou Nuancen erlaabt net Rechnung ze huelen.
Synchron (synchroniséiert) Replikatioun
Loosst eis Logik derbäi fir déi kritt Ännerunge vum Transaktiounscommit Algorithmus ze replizéieren:
- Logéiert eng Transaktioun an d'Datebankprotokoll.
- Benotzt eng Transaktioun an enger Datebankmotor.
- Schéckt Daten un all Repliken.
- Kritt Bestätegung vun all Repliken datt eng Transaktioun op hinnen ofgeschloss ass.
- Retour Bestätegung un de Client datt d'Transaktioun erfollegräich applizéiert gouf.
Mat dëser Approche kréie mir eng Rei Nodeeler:
- de Client waart op d'Ännerunge fir all Repliken applizéiert ze ginn.
- wéi d'Zuel vun de Wirbelen am Stärekoup eropgeet, reduzéieren mir d'Wahrscheinlechkeet datt d'Schreifoperatioun erfollegräich ass.
Wann alles méi oder manner kloer mam 1. Punkt ass, da sinn d'Grënn fir den 2. Punkt derwäert ze erklären. Wa mir während der synchroner Replikatioun keng Äntwert vun op d'mannst engem Node kréien, rullen mir d'Transaktioun zréck. Also, andeems Dir d'Zuel vun den Noden am Stärekoup erhéicht, erhéicht Dir d'Wahrscheinlechkeet datt eng Schreifoperatioun versoen.
Kënne mir fir Bestätegung vun nëmmen engem bestëmmte Prozentsaz vun Wirbelen wait, Zum Beispill, aus 51% (Quorum)? Jo, mir kënnen, awer an der klassescher Versioun ass d'Bestätegung vun all Noden erfuerderlech, well dëst ass wéi mir eng komplett Datekonsistenz am Cluster garantéieren, wat en zweifelhafte Virdeel vun dëser Aart vu Replikatioun ass.
Asynchron (async) Replikatioun
Loosst eis de fréiere Algorithmus änneren. Mir schécken Daten un d'Repliken "emol méi spéit", an "emol méi spéit" ginn d'Ännerungen op d'Repliken applizéiert:
- Logéiert eng Transaktioun an d'Datebankprotokoll.
- Benotzt eng Transaktioun an enger Datebankmotor.
- Retour Bestätegung un de Client datt d'Transaktioun erfollegräich applizéiert gouf.
- Schéckt Daten op Repliken an applizéiert Ännerungen op hinnen.
Dës Approche féiert zu der Tatsaach, datt de Cluster séier funktionnéiert, well mir de Client net halen op d'Daten fir d'Repliken z'erreechen an och ze engagéieren.
Awer d'Konditioun fir Daten op Repliken ze dumpen "emol méi spéit" kann zum Verloscht vun enger Transaktioun féieren, an zum Verloscht vun enger Transaktioun, déi vum Benotzer bestätegt gëtt, well wann d'Donnéeën keng Zäit hunn ze replizéieren, eng Bestätegung fir de Client iwwer den Erfolleg vun der Operatioun geschéckt gouf, an den Node, op deen d'Ännerungen ukomm sinn, gefall HDD, verléieren mir d'Transaktioun, wat zu ganz onsympathesche Konsequenze féieren kann.
Semisync Replikatioun
Endlech komme mir zu semi-synchroner Replikatioun. Dës Aart vu Replikatioun ass net ganz bekannt oder ganz heefeg, awer et ass bedeitend Interesse well et d'Virdeeler vun der Synchroner an der asynchroner Replikatioun kombinéiere kann.
Loosst eis probéieren déi 2 virdrun Approche ze kombinéieren. Mir halen de Client net laang, awer mir erfuerderen datt d'Donnéeën replizéiert ginn:
- Logéiert eng Transaktioun an d'Datebankprotokoll.
- Benotzt eng Transaktioun an enger Datebankmotor.
- Schéckt Daten op Repliken.
- Kritt Bestätegung vun der Replika datt d'Ännerunge kritt goufen (se ginn "emol méi spéit" applizéiert).
- Retour Bestätegung un de Client datt d'Transaktioun erfollegräich applizéiert gouf.
Notéiert w.e.g. datt mat dësem Algorithmus Transaktiounsverloscht nëmme geschitt wann souwuel den Node, deen d'Ännerunge kritt, wéi och de Replica Node versoen. D'Wahrscheinlechkeet vun esou engem Echec gëtt als niddereg ugesinn, an dës Risiken ginn ugeholl.
Awer mat dëser Approche besteet e méigleche Risiko vu Phantom Liesungen. Loosst eis de folgende Szenario virstellen: am Schrëtt 4 hu mir keng Bestätegung vun enger Replik kritt. Mir mussen dës Transaktioun zréckrollen an net eng Bestätegung un de Client zréckginn. Zënter datt d'Donnéeën am Schrëtt 2 applizéiert goufen, gëtt et en Zäitspalt tëscht dem Enn vum Schrëtt 2 an dem Réckgang vun der Transaktioun, wärend parallele Transaktioune Ännerunge gesinn, déi net an der Datebank solle sinn.
Verloscht-manner semisync Replikatioun
Wann Dir e bëssen denkt, kënnt Dir just d'Schrëtt vum Algorithmus ëmgedréint an de Problem vu Phantom Liesungen an dësem Szenario fixéieren:
- Logéiert eng Transaktioun an d'Datebankprotokoll.
- Schéckt Replikdaten.
- Kritt Bestätegung vun der Replika datt d'Ännerunge kritt goufen (se ginn "emol méi spéit" applizéiert).
- Benotzt eng Transaktioun an enger Datebankmotor.
- Retour Bestätegung un de Client datt d'Transaktioun erfollegräich applizéiert gouf.
Elo verpflichte mir Ännerungen nëmmen wa se replizéiert goufen.
Konklusioun
Wéi ëmmer gëtt et keng ideal Léisungen; et gëtt eng Rei vu Léisungen, déi all seng eegen Virdeeler an Nodeeler huet an ass gëeegent fir verschidde Klasse vu Probleemer ze léisen. Dëst ass absolut wouer fir e Mechanismus ze wielen fir Daten an enger replizéierter Datebank ze synchroniséieren. D'Set vu Virdeeler déi semi-synchron Replikatioun huet ass genuch zolidd an interessant datt et als Wäert opmierksam ass, trotz senger gerénger Prävalenz.
Dat ass alles. Bis zu !
Source: will.com