Kwa nini unaweza kuhitaji urudufishaji wa nusu-synchronous?

Salaam wote. Vladislav Rodin anawasiliana. Kwa sasa ninafundisha kozi za Usanifu wa Programu na Usanifu wa Programu zenye Mkazo wa Juu huko OTUS. Kwa kutarajia kuanza kwa mkondo mpya wa kozi "Msanifu wa mzigo mkubwa" Niliamua kuandika kipande kifupi cha nyenzo asili ambayo nataka kushiriki nawe.

Kwa nini unaweza kuhitaji urudufishaji wa nusu-synchronous?

Utangulizi

Kwa sababu ya ukweli kwamba HDD inaweza kufanya takriban shughuli 400-700 kwa sekunde (ambayo haiwezi kulinganishwa na rps ya kawaida kwenye mfumo wa mzigo mkubwa), hifadhidata ya diski ya classic ni kizuizi cha usanifu. Kwa hiyo, ni muhimu kulipa kipaumbele maalum kwa mifumo ya kuongeza ya hifadhi hii.

Hivi sasa, kuna mifumo 2 ya kuongeza hifadhidata: urudufishaji na ugawaji. Sharding hukuruhusu kuongeza utendakazi wa uandishi, na, kwa sababu hiyo, kupunguza rps kwa kuandika kwa kila seva kwenye nguzo yako. Kurudia hukuruhusu kufanya kitu kimoja, lakini kwa shughuli za kusoma. Ni muundo huu ambao makala hii imejitolea.

Replication

Ikiwa unatazama replication kwa kiwango cha juu sana, ni jambo rahisi: ulikuwa na seva moja, kulikuwa na data juu yake, na kisha seva hii haikuweza tena kukabiliana na mzigo wa kusoma data hii. Unaongeza seva kadhaa zaidi, kusawazisha data kwenye seva zote, na mtumiaji anaweza kusoma kutoka kwa seva yoyote kwenye kundi lako.

Licha ya unyenyekevu wake dhahiri, kuna chaguzi kadhaa za kuainisha utekelezaji kadhaa wa mpango huu:

  • Kwa majukumu katika nguzo (bwana-bwana au bwana-mtumwa)
  • Na vitu vilivyotumwa (kulingana na safu, kauli-msingi au mchanganyiko)
  • Kulingana na utaratibu wa maingiliano ya nodi

Leo tutashughulikia hoja ya 3.

Je, ahadi ya muamala hutokeaje?

Mada hii haihusiani moja kwa moja na urudufishaji; nakala tofauti inaweza kuandikwa juu yake, lakini kwa kuwa usomaji zaidi haufai bila kuelewa utaratibu wa ahadi ya muamala, wacha nikukumbushe mambo ya msingi zaidi. Ahadi ya muamala hufanyika katika hatua 3:

  1. Kuweka muamala kwenye logi ya hifadhidata.
  2. Kutumia shughuli katika injini ya hifadhidata.
  3. Inarejesha uthibitisho kwa mteja kwamba muamala umetekelezwa.

Katika hifadhidata tofauti, algorithm hii inaweza kuwa na nuances: kwa mfano, katika injini ya InnoDB ya hifadhidata ya MySQL kuna kumbukumbu 2: moja kwa ajili ya kuiga (logi ya binary), na nyingine kwa ajili ya kudumisha ACID (tendua/rudia logi), ukiwa kwenye PostgreSQL. kuna logi moja ambayo hufanya kazi zote mbili (andika logi ya mbele = WAL). Lakini kile kilichowasilishwa hapo juu ni dhana ya jumla, ambayo inaruhusu nuances kama hiyo kutozingatiwa.

Usawazishaji (usawazishaji) urudufishaji

Wacha tuongeze mantiki ili kuiga mabadiliko yaliyopokelewa kwa algorithm ya ahadi ya ununuzi:

  1. Kuweka muamala kwenye logi ya hifadhidata.
  2. Kutumia shughuli katika injini ya hifadhidata.
  3. Inatuma data kwa nakala zote.
  4. Inapokea uthibitisho kutoka kwa nakala zote kwamba muamala umekamilika juu yao.
  5. Inarejesha uthibitisho kwa mteja kwamba muamala umetekelezwa.

Kwa njia hii tunapata hasara kadhaa:

  • mteja anasubiri mabadiliko yatumike kwa nakala zote.
  • kadiri idadi ya nodi kwenye nguzo inavyoongezeka, tunapunguza uwezekano kwamba operesheni ya kuandika itafaulu.

Ikiwa kila kitu ni wazi zaidi au kidogo na hatua ya 1, basi sababu za hatua ya 2 zinafaa kuelezea. Ikiwa wakati wa urudufishaji wa kisawazishaji hatupokei jibu kutoka kwa angalau nodi moja, tunarudisha muamala. Kwa hivyo, kwa kuongeza idadi ya nodi kwenye nguzo, unaongeza uwezekano kwamba operesheni ya kuandika itashindwa.

Je, tunaweza kusubiri uthibitisho kutoka kwa asilimia fulani tu ya nodes, kwa mfano, kutoka 51% (quorum)? Ndio, tunaweza, lakini katika toleo la kawaida, uthibitisho kutoka kwa nodi zote unahitajika, kwa sababu hii ndio jinsi tunaweza kuhakikisha uthabiti kamili wa data kwenye nguzo, ambayo ni faida isiyo na shaka ya aina hii ya kuiga.

Urudiaji wa Asynchronous (async).

Wacha turekebishe algorithm iliyopita. Tutatuma data kwa nakala "baadaye", na "baadaye" mabadiliko yatatumika kwa nakala:

  1. Kuweka muamala kwenye logi ya hifadhidata.
  2. Kutumia shughuli katika injini ya hifadhidata.
  3. Inarejesha uthibitisho kwa mteja kwamba muamala umetekelezwa.
  4. Kutuma data kwa nakala na kutumia mabadiliko kwao.

Njia hii inaongoza kwa ukweli kwamba nguzo hufanya kazi haraka, kwa sababu hatuweka mteja kusubiri data kufikia replicas na hata kujitolea.

Lakini hali ya kutupa data kwenye nakala "wakati fulani baadaye" inaweza kusababisha upotezaji wa shughuli, na upotezaji wa shughuli iliyothibitishwa na mtumiaji, kwa sababu ikiwa data haikuwa na wakati wa kuigwa, uthibitisho kwa mteja. kuhusu mafanikio ya operesheni ilitumwa, na node ambayo mabadiliko yalifika ilianguka HDD, tunapoteza shughuli, ambayo inaweza kusababisha matokeo mabaya sana.

Urudufu wa usawazishaji

Hatimaye tunapata urudufishaji wa nusu-synchronous. Aina hii ya urudufishaji haifahamiki sana au ya kawaida sana, lakini inavutia sana kwa sababu inaweza kuchanganya faida za urudufishaji wa usawazishaji na ulinganifu.

Wacha tujaribu kuchanganya njia 2 zilizopita. Hatutaweka mteja kwa muda mrefu, lakini tutahitaji kwamba data irudiwe:

  1. Kuweka muamala kwenye logi ya hifadhidata.
  2. Kutumia shughuli katika injini ya hifadhidata.
  3. Inatuma data kwa nakala.
  4. Inapokea uthibitisho kutoka kwa nakala kwamba mabadiliko yamepokelewa (yatatumika "baadaye").
  5. Inarejesha uthibitisho kwa mteja kwamba muamala umetekelezwa.

Tafadhali kumbuka kuwa kwa algoriti hii, hasara ya muamala hutokea tu ikiwa nodi inayopokea mabadiliko na nodi ya nakala itashindwa. Uwezekano wa kushindwa vile unachukuliwa kuwa chini, na hatari hizi zinakubaliwa.

Lakini kwa njia hii kuna hatari inayowezekana ya usomaji wa phantom. Hebu tufikirie hali ifuatayo: katika hatua ya 4, hatukupokea uthibitisho kutoka kwa nakala yoyote. Ni lazima turudishe muamala huu na tusirudishe uthibitisho kwa mteja. Kwa kuwa data ilitumika katika hatua ya 2, kuna pengo la muda kati ya mwisho wa hatua ya 2 na urejeshaji wa shughuli, wakati ambapo shughuli sambamba zinaweza kuona mabadiliko ambayo hayafai kuwa kwenye hifadhidata.

Urudiaji usio na usawazishaji mdogo sana

Ikiwa unafikiria kidogo, unaweza kubadilisha tu hatua za algorithm na kurekebisha shida ya usomaji wa phantom katika hali hii:

  1. Kuweka muamala kwenye logi ya hifadhidata.
  2. Inatuma data ya nakala.
  3. Inapokea uthibitisho kutoka kwa nakala kwamba mabadiliko yamepokelewa (yatatumika "baadaye").
  4. Kutumia shughuli katika injini ya hifadhidata.
  5. Inarejesha uthibitisho kwa mteja kwamba muamala umetekelezwa.

Sasa tunafanya mabadiliko ikiwa tu yameigwa.

Pato

Kama kawaida, hakuna suluhisho bora; kuna seti ya suluhisho, ambayo kila moja ina faida na hasara zake na inafaa kwa kutatua aina tofauti za shida. Hii ni kweli kabisa kwa kuchagua utaratibu wa kusawazisha data katika hifadhidata iliyojirudia. Seti ya faida ambazo urudufishaji wa nusu-synchronous ina uthabiti wa kutosha na wa kuvutia ambao unaweza kuzingatiwa kuwa unastahili kuzingatiwa, licha ya kiwango chake cha chini.

Ni hayo tu. Tuonane kwenye kozi!

Chanzo: mapenzi.com

Kuongeza maoni