Saluton al ĉiuj. Vladislav Rodin estas en kontakto. Nuntempe mi instruas kursojn pri Programaro-Arkitekturo kaj Altstresa Programaro-Arkitekturo ĉe OTUS. Antaŭĝoje de la komenco de nova kursfluo Mi decidis skribi mallongan originalan materialon, kiun mi volas dividi kun vi.
Enkonduko
Pro la fakto, ke la HDD nur povas plenumi ĉirkaŭ 400-700 operaciojn sekundo (kio estas nekomparebla kun tipaj rps en alta ŝarĝa sistemo), la klasika disko-datumbazo estas la botelkolo de la arkitekturo. Tial, necesas atenti specialan al la skalaj ŝablonoj de ĉi tiu stokado.
Nuntempe, ekzistas 2 datumbazaj skalaj ŝablonoj: reproduktado kaj sharding. Sharding permesas al vi grimpi la skriban operacion kaj, kiel rezulto, redukti la rps per skribo per servilo en via areto. Reproduktado permesas al vi fari la saman aferon, sed kun legado de operacioj. Estas ĉi tiu ŝablono, al kiu ĉi tiu artikolo estas dediĉita.
reproduktado
Se vi rigardas reproduktadon je tre alta nivelo, ĝi estas simpla afero: vi havis unu servilon, estis datumoj sur ĝi, kaj tiam ĉi tiu servilo ne plu povis elteni la ŝarĝon de legado de ĉi tiuj datumoj. Vi aldonas kelkajn pliajn servilojn, sinkronigas datumojn tra ĉiuj serviloj, kaj la uzanto povas legi de iu ajn servilo en via areto.
Malgraŭ ĝia ŝajna simpleco, ekzistas pluraj ebloj por klasifiki diversajn efektivigojn de ĉi tiu skemo:
- Laŭ roloj en la areto (majstro-mastro aŭ majstro-sklavo)
- Per objektoj senditaj (vic-bazitaj, deklaro-bazitaj aŭ miksitaj)
- Laŭ la noda sinkroniga mekanismo
Hodiaŭ ni traktos punkton 3.
Kiel okazas transakcia kompromiso?
Ĉi tiu temo ne rekte rilatas al reproduktado; aparta artikolo povas esti skribita sur ĝi, sed ĉar plua legado estas senutila sen kompreni la transakcian transakcian mekanismon, mi memorigu vin pri la plej bazaj aferoj. Transakcia kompromiso okazas en 3 stadioj:
- Registrado de transakcio al la datumbaza protokolo.
- Uzante transakcion en datumbaza motoro.
- Revenante konfirmon al la kliento, ke la transakcio estis sukcese aplikita.
En malsamaj datumbazoj, ĉi tiu algoritmo povas havi nuancojn: ekzemple, en la InnoDB-motoro de la datumbazo MySQL estas 2 protokoloj: unu por reproduktado (binara protokolo), kaj la alia por konservi ACID (malfari/refari protokolon), dum en PostgreSQL. estas unu protokolo, kiu plenumas ambaŭ funkciojn (skribi antaŭan protokolon = WAL). Sed tio, kio estas prezentita supre, estas ĝuste la ĝenerala koncepto, kiu permesas tiajn nuancojn ne esti konsiderataj.
Sinkrona (sinkroniga) reproduktado
Ni aldonu logikon por reprodukti la ricevitajn ŝanĝojn al la transakcia transiga algoritmo:
- Registrado de transakcio al la datumbaza protokolo.
- Uzante transakcion en datumbaza motoro.
- Sendante datumojn al ĉiuj kopioj.
- Ricevante konfirmon de ĉiuj kopioj, ke transakcio estis kompletigita pri ili.
- Revenante konfirmon al la kliento, ke la transakcio estis sukcese aplikita.
Kun ĉi tiu aliro ni ricevas kelkajn malavantaĝojn:
- la kliento atendas ke la ŝanĝoj estos aplikitaj al ĉiuj kopioj.
- ĉar la nombro da nodoj en la areto pliiĝas, ni malpliigas la verŝajnecon, ke la skriba operacio sukcesos.
Se ĉio estas pli-malpli klara kun la 1-a punkto, tiam la kialoj de la 2-a punkto estas klarigindaj. Se dum sinkrona reproduktado ni ne ricevas respondon de almenaŭ unu nodo, ni retroiras la transakcion. Tiel, pliigante la nombron da nodoj en la areto, vi pliigas la verŝajnecon ke skriba operacio malsukcesos.
Ĉu ni povas atendi konfirmon de nur certa procento de nodoj, ekzemple, de 51% (kvorumo)? Jes, ni povas, sed en la klasika versio, konfirmo de ĉiuj nodoj estas postulata, ĉar tiel ni povas certigi kompletan datuman konsistencon en la areto, kio estas senduba avantaĝo de ĉi tiu tipo de reproduktado.
Nesinkrona (sensinkrona) reproduktado
Ni modifu la antaŭan algoritmon. Ni sendos datumojn al la kopioj "iam poste", kaj "iam poste" la ŝanĝoj estos aplikitaj al la kopioj:
- Registrado de transakcio al la datumbaza protokolo.
- Uzante transakcion en datumbaza motoro.
- Revenante konfirmon al la kliento, ke la transakcio estis sukcese aplikita.
- Sendante datumojn al kopioj kaj aplikante ŝanĝojn al ili.
Ĉi tiu aliro kondukas al la fakto, ke la areto funkcias rapide, ĉar ni ne tenas la klienton atendante ke la datumoj atingu la kopiojn kaj eĉ fariĝu.
Sed la kondiĉo de forĵetado de datumoj sur kopiojn "iam poste" povas konduki al la perdo de transakcio, kaj al la perdo de transakcio konfirmita de la uzanto, ĉar se la datumoj ne havis tempon por esti reproduktitaj, konfirmo al la kliento. pri la sukceso de la operacio estis sendita, kaj la nodo al kiu alvenis la ŝanĝoj kraŝis HDD, ni perdas la transakcion, kiu povas konduki al tre malagrablaj konsekvencoj.
Semisinkrona reproduktado
Fine ni atingas duonsinkronan reproduktadon. Tiu speco de reproduktado ne estas tre konata aŭ tre ofta, sed ĝi estas de konsiderinda intereso ĉar ĝi povas kombini la avantaĝojn de kaj sinkrona kaj nesinkrona reproduktado.
Ni provu kombini la 2 antaŭajn alirojn. Ni ne konservos la klienton longe, sed ni postulos, ke la datumoj estu reproduktitaj:
- Registrado de transakcio al la datumbaza protokolo.
- Uzante transakcion en datumbaza motoro.
- Sendante datumojn al kopioj.
- Ricevante konfirmon de la kopio, ke la ŝanĝoj estis ricevitaj (ili estos aplikitaj "iam poste").
- Revenante konfirmon al la kliento, ke la transakcio estis sukcese aplikita.
Bonvolu noti, ke kun ĉi tiu algoritmo, transakcia perdo okazas nur se kaj la nodo ricevanta la ŝanĝojn kaj la kopinodo malsukcesas. La probablo de tia malsukceso estas konsiderata malalta, kaj ĉi tiuj riskoj estas akceptitaj.
Sed kun ĉi tiu aliro ekzistas ebla risko de fantomaj legoj. Ni imagu la sekvan scenaron: en la paŝo 4, ni ne ricevis konfirmon de iu kopio. Ni devas refari ĉi tiun transakcion kaj ne redoni konfirmon al la kliento. Ĉar la datumoj estis aplikitaj en la paŝo 2, ekzistas tempointerspaco inter la fino de la paŝo 2 kaj la restarigo de la transakcio, dum kiu paralelaj transakcioj povas vidi ŝanĝojn, kiuj ne devus esti en la datumbazo.
Perd-malpli duonsinkrona reproduktado
Se vi pensas iomete, vi povas simple inversigi la paŝojn de la algoritmo kaj ripari la problemon de fantomaj legoj en ĉi tiu scenaro:
- Registrado de transakcio al la datumbaza protokolo.
- Sendante kopiajn datumojn.
- Ricevante konfirmon de la kopio, ke la ŝanĝoj estis ricevitaj (ili estos aplikitaj "iam poste").
- Uzante transakcion en datumbaza motoro.
- Revenante konfirmon al la kliento, ke la transakcio estis sukcese aplikita.
Nun ni faras ŝanĝojn nur se ili estis reproduktitaj.
konkludo
Kiel ĉiam, ne ekzistas idealaj solvoj; ekzistas aro da solvoj, ĉiu el kiuj havas siajn proprajn avantaĝojn kaj malavantaĝojn kaj taŭgas por solvi malsamajn klasojn de problemoj. Ĉi tio estas absolute vera por elekti mekanismon por sinkronigi datumojn en reproduktita datumbazo. La aro de avantaĝoj kiujn havas duonsinkrona reproduktado estas sufiĉe solida kaj interesa ke ĝi povas esti konsiderita inda je atento, malgraŭ sia malalta tropezo.
Tio estas ĉio. Ĝis revido !
fonto: www.habr.com