Sveiki visiem. Vladislavs Rodins sazinās. Pašlaik es pasniedzu kursus par programmatūras arhitektūru un augsta stresa programmatūras arhitektūru OTUS. Gaidot jaunas kursa plūsmas sākumu Es nolēmu uzrakstīt īsu oriģināla materiāla fragmentu, ar kuru vēlos dalīties ar jums.
Ievads
Sakarā ar to, ka HDD var veikt tikai aptuveni 400-700 operācijas sekundē (kas ir nesalīdzināms ar tipisku rps lielas slodzes sistēmai), klasiskā disku datu bāze ir arhitektūras sašaurinājums. Tāpēc ir jāpievērš īpaša uzmanība šīs krātuves mērogošanas modeļiem.
Pašlaik ir 2 datu bāzes mērogošanas modeļi: replikācija un sadalīšana. Dalīšana ļauj mērogot rakstīšanas darbību un tādējādi samazināt rps uz vienu rakstīšanas serveri savā klasterī. Replikācija ļauj veikt to pašu, bet ar lasīšanas darbībām. Šis raksts ir veltīts šim modelim.
Replikācija
Ja paskatās uz replikāciju ļoti augstā līmenī, tā ir vienkārša lieta: jums bija viens serveris, tajā bija dati, un tad šis serveris vairs nevarēja tikt galā ar šo datu lasīšanas slodzi. Jūs pievienojat vēl dažus serverus, sinhronizējat datus visos serveros, un lietotājs var lasīt no jebkura servera jūsu klasterī.
Neskatoties uz šķietamo vienkāršību, ir vairākas iespējas, kā klasificēt dažādas šīs shēmas ieviešanas:
- Pēc lomām klasterī (galvenais-vadītājs vai galvenais-pakalpojums)
- Pēc nosūtītajiem objektiem (pamatojoties uz rindām, pamatojoties uz paziņojumu vai jauktu)
- Saskaņā ar mezglu sinhronizācijas mehānismu
Šodien mēs izskatīsim 3. punktu.
Kā notiek darījuma apņemšanās?
Šī tēma nav tieši saistīta ar replikāciju, par to var uzrakstīt atsevišķu rakstu, taču, tā kā tālāka lasīšana ir bezjēdzīga, neizprotot transakciju veikšanas mehānismu, atgādināšu par elementārāko. Darījuma apņemšanās notiek 3 posmos:
- Darījuma reģistrēšana datu bāzes žurnālā.
- Darījuma izmantošana datu bāzes dzinējā.
- Apstiprinājuma atgriešana klientam, ka darījums ir veiksmīgi piemērots.
Dažādās datu bāzēs šim algoritmam var būt nianses: piemēram, MySQL datu bāzes InnoDB dzinējā ir 2 žurnāli: viens replikācijai (binārais žurnāls), otrs ACID uzturēšanai (undo/redo log), savukārt PostgreSQL. ir viens žurnāls, kas veic abas funkcijas (rakstīt uz priekšu žurnālu = WAL). Bet tas, kas ir parādīts iepriekš, ir tieši vispārīgs jēdziens, kas ļauj šādas nianses neņemt vērā.
Sinhronā (sinhronā) replikācija
Pievienosim loģiku, lai atkārtotu saņemtās izmaiņas darījuma izpildes algoritmā:
- Darījuma reģistrēšana datu bāzes žurnālā.
- Darījuma izmantošana datu bāzes dzinējā.
- Datu sūtīšana uz visām replikām.
- Apstiprinājuma saņemšana no visām replikām, ka ar tām ir pabeigts darījums.
- Apstiprinājuma atgriešana klientam, ka darījums ir veiksmīgi piemērots.
Izmantojot šo pieeju, mēs iegūstam vairākus trūkumus:
- klients gaida, līdz izmaiņas tiks piemērotas visām replikām.
- palielinoties mezglu skaitam klasterī, mēs samazinām iespēju, ka rakstīšanas darbība būs veiksmīga.
Ja ar 1.punktu viss ir vairāk vai mazāk skaidrs, tad 2.punkta iemesli ir izskaidrošanas vērti. Ja sinhronās replikācijas laikā nesaņemam atbildi no vismaz viena mezgla, mēs atceļam darījumu. Tādējādi, palielinot mezglu skaitu klasterī, palielinās iespējamība, ka rakstīšanas darbība neizdosies.
Vai mēs varam gaidīt apstiprinājumu tikai no noteikta mezglu procenta, piemēram, no 51% (kvorums)? Jā, mēs varam, taču klasiskajā versijā ir nepieciešams apstiprinājums no visiem mezgliem, jo tādējādi mēs varam nodrošināt pilnīgu datu konsekvenci klasterī, kas ir neapšaubāma šāda veida replikācijas priekšrocība.
Asinhronā (asinhronā) replikācija
Pārveidosim iepriekšējo algoritmu. Mēs nosūtīsim datus uz replikām "kaut kad vēlāk", un "kaut kad vēlāk" izmaiņas tiks piemērotas replikām:
- Darījuma reģistrēšana datu bāzes žurnālā.
- Darījuma izmantošana datu bāzes dzinējā.
- Apstiprinājuma atgriešana klientam, ka darījums ir veiksmīgi piemērots.
- Datu sūtīšana uz replikām un izmaiņu piemērošana tām.
Šī pieeja noved pie tā, ka klasteris darbojas ātri, jo mēs neļaujam klientam gaidīt, līdz dati nonāks līdz replikām un pat tiks piesaistīti.
Bet nosacījums, ka dati tiek ievietoti replikās “kaut kad vēlāk”, var novest pie darījuma zaudēšanas un lietotāja apstiprināta darījuma zaudēšanas, jo, ja datus nebija laika pavairot, klientam tiek saņemts apstiprinājums. par operācijas veiksmi tika nosūtīts, un mezglā, uz kuru izmaiņas ieradās, avarēja HDD, mēs zaudējam darījumu, kas var novest pie ļoti nepatīkamām sekām.
Daļēji sinhronizēta replikācija
Visbeidzot mēs nonākam pie daļēji sinhronās replikācijas. Šis replikācijas veids nav ļoti labi zināms vai ļoti izplatīts, taču tas rada ievērojamu interesi, jo tas var apvienot gan sinhronās, gan asinhronās replikācijas priekšrocības.
Mēģināsim apvienot 2 iepriekšējās pieejas. Mēs neuzturēsim klientu ilgi, bet pieprasīsim, lai dati tiktu replicēti:
- Darījuma reģistrēšana datu bāzes žurnālā.
- Darījuma izmantošana datu bāzes dzinējā.
- Datu sūtīšana uz replikām.
- Apstiprinājuma saņemšana no replikas, ka izmaiņas ir saņemtas (tās tiks piemērotas “kaut kad vēlāk”).
- Apstiprinājuma atgriešana klientam, ka darījums ir veiksmīgi piemērots.
Lūdzu, ņemiet vērā, ka, izmantojot šo algoritmu, transakciju zudumi rodas tikai tad, ja neizdodas gan mezgls, kas saņem izmaiņas, gan replikas mezgls. Šādas neveiksmes iespējamība tiek uzskatīta par zemu, un šie riski tiek pieņemti.
Taču ar šo pieeju pastāv fantoma nolasījumu risks. Iedomāsimies šādu scenāriju: 4. darbībā mēs nesaņēmām apstiprinājumu no nevienas kopijas. Mums ir jāatsauc šis darījums, nevis jāatgriež klientam apstiprinājums. Tā kā dati tika lietoti 2. darbībā, starp 2. darbības beigām un darījuma atcelšanu ir laika intervāls, kura laikā paralēlās transakcijas var redzēt izmaiņas, kurām nevajadzētu būt datu bāzē.
Daļēji sinhronizēta replikācija bez zaudējumiem
Ja nedaudz padomājat, varat vienkārši mainīt algoritma darbības un novērst fantoma nolasīšanas problēmu šajā scenārijā:
- Darījuma reģistrēšana datu bāzes žurnālā.
- Reprodukcijas datu sūtīšana.
- Apstiprinājuma saņemšana no replikas, ka izmaiņas ir saņemtas (tās tiks piemērotas “kaut kad vēlāk”).
- Darījuma izmantošana datu bāzes dzinējā.
- Apstiprinājuma atgriešana klientam, ka darījums ir veiksmīgi piemērots.
Tagad mēs veicam izmaiņas tikai tad, ja tās ir pavairotas.
secinājums
Ideālu risinājumu, kā vienmēr, nav, ir risinājumu kopums, katram no kuriem ir savas priekšrocības un trūkumi, un tas ir piemērots dažādu problēmu klašu risināšanai. Tas ir absolūti taisnība, izvēloties mehānismu datu sinhronizēšanai replicētā datu bāzē. Pussinhronās replikācijas priekšrocību kopums ir pietiekami stabils un interesants, lai to varētu uzskatīt par uzmanības vērtu, neskatoties uz tā zemo izplatību.
Tas ir viss. Tiekamies plkst !
Avots: www.habr.com