Roshans Kumars ir uzņēmuma Redis Labs vecākais produktu vadītājs.
Atbilstības un pieejamības liekšana, kā aprakstīts KLP teorēmā, ir bijis liels izaicinājums ģeogrāfiski izplatītu lietojumprogrammu arhitektiem. Tīkla nodalījums ir neizbēgams. Lielais latentums starp datu centriem vienmēr rada īslaicīgu atslēgšanos starp datu centriem. Tādējādi tradicionālās ģeogrāfiski izplatīto lietojumprogrammu arhitektūras ir izstrādātas, lai vai nu atteiktos no datu konsekvences, vai arī novērtētu pieejamību.
Diemžēl jūs nevarat atļauties upurēt interaktīvo lietotāju lietojumprogrammu pieejamību. Pēdējā laikā arhitekti ir fotografējuši konsekvenci un izmantojuši iespējamo konsekvences modeli. Šajā modelī lietojumprogrammas ir atkarīgas no datu bāzes pārvaldības sistēmas, lai apvienotu visas datu lokālās kopijas, lai tās galu galā būtu konsekventas.
Līdz gala konsekvences modelim viss izskatās labi, kamēr nav datu konfliktu. Daži iespējamie konsekvences modeļi sola labākos centienus novērst konfliktus, taču garantē stingru konsekvenci. Labā ziņa ir tā, ka modeļi, kas izveidoti, balstoties uz bezkonfliktu kopētiem datu tipiem (CRDT), nodrošina lielu konsekvenci.
CRDT panāk spēcīgu iespējamo konsekvenci, izmantojot iepriekš noteiktu konfliktu risināšanas noteikumu un semantikas kopumu. CRDT bāzes datubāzēm izveidotās lietojumprogrammas ir jāprojektē tā, lai tās pielāgotos konfliktu risināšanas semantikai. Šajā rakstā mēs izpētīsim, kā izstrādāt, attīstīt un testēt ģeogrāfiski izplatītas lietojumprogrammas, izmantojot uz CRDT balstītu datu bāzi. Mēs izskatīsim arī četrus parauga lietošanas gadījumus: skaitītājus, sadalīto kešatmiņu, koplietotās sesijas un vairāku reģionu datu uzņemšanu.
Mans darba devējs Redis Labs nesen paziņoja par CRDT atbalstu Redis Enterprise, kurā bez konfliktiem atkārtoti datu tipi pievienojas bagātīgajam datu struktūru portfelim - virknes, hašiši, saraksti, kopas, sakārtoti kopas, bitu lauki, ģeogrāfiskā informācija, hiperloglogs un straumes. mūsu datu bāzes produkts. Tomēr šī diskusija attiecas ne tikai uz Redis Enterprise, bet arī uz visām uz CRDT balstītajām datu bāzēm.
Ģeogrāfiski izplatītu lietojumprogrammu datu bāzes
Ģeogrāfiski izplatītās lietojumprogrammās klientiem parasti tiek veikti vietējie pakalpojumi. Tas samazina tīkla trafiku un latentumu, ko rada turp un atpakaļ. Daudzos gadījumos arhitekti izstrādā pakalpojumus, lai izveidotu savienojumu ar vietējo datu bāzi. Tad rodas jautājums, kā jūs uzturat konsekventus datus visās datu bāzēs. Viena no iespējām ir rīkoties ar to lietojumprogrammas līmenī - jūs varat uzrakstīt periodisku darba procesu, kas sinhronizēs visas datu bāzes. Vai arī jūs varat paļauties uz datu bāzi, kas sinhronizēs datus starp datu bāzēm.
Pārējā raksta daļā mēs pieņemam, ka izmantosiet otro iespēju - ļaujiet datu bāzei veikt darbu. Kā parādīts 1. attēlā, jūsu ģeogrāfiski sadalītā lietojumprogramma darbojas vairākos reģionos, katram pakalpojumam izveidojot savienojumu ar vietējo datu bāzi. Bāzes datu bāzes pārvaldības sistēma sinhronizē datus starp reģionos izvietotajām datu bāzēm.
Redis Labs Datu konsekvences modeļi
Konsekvences modelis ir līgums starp izplatīto datu bāzi un lietojumprogrammu, kas nosaka datu tīrības pakāpi starp rakstīšanas un lasīšanas operācijām.
Piemēram, spēcīgas konsekvences modelī datu bāze garantē, ka lietojumprogrammas vienmēr lasīs pēdējo rakstīto. Ar secīgu konsekvenci datu bāze nodrošina, ka izlasīto datu secība atbilst secībai, kādā tie tika ierakstīti datu bāzē. Galīgajā konsekvences modelī izplatītā datu bāze sola sinhronizēt un konsolidēt datus starp datu bāzes kopijām aiz ainas. Tādēļ, ja ierakstāt datus vienā datu bāzes replikā un lasāt citā, iespējams, neizlasīsit jaunāko datu kopiju.
Spēcīga konsistence
Divu fāžu apņemšanās ir izplatīta tehnika, lai panāktu stingru konsekvenci. Šeit katrai vietējās datu bāzes mezgla rakstīšanas operācijai (pievienošana, atjaunināšana, dzēšana) datu bāzes mezgls izplata izmaiņas visos datu bāzes mezglos un gaida, kamēr visi mezgli to apstiprinās. Pēc tam vietējais mezgls nosūta apņemšanos visiem mezgliem un gaida citu apstiprinājumu. Lietojumprogramma varēs izlasīt datus tikai pēc otrās saistības. Sadalītā datu bāze nebūs pieejama rakstīšanas darbībām, kad tīkls atvienosies starp datu bāzēm.
Galīgā konsekvence
Galīgā konsekvences modeļa galvenā priekšrocība ir tā, ka datu bāze būs jums pieejama rakstīšanas darbību veikšanai pat tad, ja tīkla savienojamība starp sadalītās datu bāzes kopijām sabojājas. Kopumā šis modelis ļauj izvairīties no turp un atpakaļ brauciena laika, kas rodas no divfāžu saistības, un tāpēc atbalsta daudz vairāk rakstīšanas operāciju sekundē nekā citi modeļi. Viena problēma, kas jārisina konsekvencei, ir konflikti - vienlaicīgi tiek rakstīts uz viena un tā paša priekšmeta divās dažādās vietās. Pamatojoties uz to, kā izvairīties vai atrisināt konfliktus, galu galā konsekventās datu bāzes tiek klasificētas šādās kategorijās:
- Uzvar pēdējais rakstnieks (LWW). Šajā stratēģijā izplatītās datu bāzes paļaujas uz laika zīmoga sinhronizāciju starp serveriem. Datu bāzes apmaina katras rakstīšanas operācijas laika zīmogu kopā ar pašiem datiem. Ja rodas konflikts, uzvar rakstīšanas operācija ar jaunāko laika zīmogu.
Šīs tehnikas trūkums ir tāds, ka tiek pieņemts, ka visi sistēmas pulksteņi ir sinhronizēti. Praksē ir grūti un dārgi sinhronizēt visus sistēmas pulksteņus.
- Kvoruma iespējamā konsekvence: Šī tehnika ir līdzīga divfāžu saistībām. Tomēr vietējā datu bāze negaida apstiprinājumu no visām datu bāzēm; tas vienkārši gaida apstiprinājumu no lielākās daļas datubāzu. Vairākuma apstiprinājums nosaka kvorumu. Ja rodas konflikts, uzvar rakstīšanas operācija, kas izveidojusi kvorumu.
No otras puses, šī metode pievieno tīkla latentumu rakstīšanas operācijām, kas padara lietotni mazāk mērogojamu. Arī vietējā datu bāze nebūs pieejama rakstīšanai, ja tā tiks izolēta no citām topoloģijas datu bāzes kopijām.
- Apvienot replikāciju: Šajā tradicionālajā pieejā, kas izplatīta starp relāciju datu bāzēm, centralizēts apvienošanas aģents apvieno visus datus. Šī metode piedāvā arī zināmu elastību, ieviešot savus noteikumus konfliktu risināšanai.
Apvienošanas replikācija ir pārāk lēna, lai atbalstītu reāllaika un saistošas lietojumprogrammas. Tam ir arī viens neveiksmes punkts. Tā kā šī metode neatbalsta iepriekš noteiktus noteikumus konfliktu risināšanai, tā bieži noved pie kļūdainas konfliktu risināšanas ieviešanas.
- Bezkonfliktu dublēto datu tips (CRDT): Jūs detalizēti uzzināsiet par CRDT dažās nākamajās sadaļās. Īsumā CRDT bāzes datubāzes atbalsta datu tipus un darbības, kas nodrošina konsekvenci bez iespējamām konsekvencēm. CRDT bāzes datu bāzes ir pieejamas pat tad, ja izplatītās datu bāzes kopijas nevar apmainīties ar datiem. Viņi vienmēr nodrošina vietējo latentumu lasīšanas un rakstīšanas darbībām.
Ierobežojumi? Ne visi datubāzes izmantošanas gadījumi ir ieguvēji no CRDT. Arī CRDT balstītu datu bāzu konfliktu risināšanas semantika ir iepriekš definēta, un to nevar ignorēt.
Kas ir CRDT?
CRDT ir īpaši datu tipi, kas sapludina datus no visām datu bāzes kopijām. Populārie CRDT ir G skaitītāji (tikai augšanas skaitītāji), PN skaitītāji (pozitīvi-negatīvi skaitītāji), reģistri, G-kopas (tikai augšanas kopas), 2P komplekti (divfāžu komplekti), OR-kopas ( novērotie-noņemamie komplekti) utt. Aizkulisēs dati tiek sapludināti ar šādām matemātiskām īpašībām:
- Komutatīvais īpašums: a ☆ b = b ☆ a
- Asociatīvs īpašums: a ☆ (b ☆ c) = (a ☆ b) ☆ c
- Idempotence: a ☆ a = a
G skaitītājs ir lielisks piemērs operatīvai CRDT, kas apvieno operācijas. Šeit a + b = b + a un a + (b + c) = (a + b) + c. Replikas savā starpā apmainās tikai ar atjauninājumiem (papildinājumiem). CRDT apvienos atjauninājumus, tos saskaitot. Piemēram, G kopa pielieto idempotenci ({a, b, c} U {c} = {a, b, c}), lai sapludinātu visus elementus. Idempotence ļauj izvairīties no datu struktūrai pievienoto elementu dublēšanās, kad tie pārvietojas un saplūst pa dažādiem ceļiem.
CRDT datu veidi un to konfliktu risināšanas semantika
Datu struktūras bez konfliktiem: G skaitītāji, PN skaitītāji, G komplekti
Visas šīs datu struktūras pēc konstrukcijas ir bez konfliktiem. Zemāk esošajās tabulās parādīts, kā dati tiek sinhronizēti starp datu bāzes kopijām.
Redis Labs 
Redis Labs G skaitītāji un PN skaitītāji ir populāri lietojuma gadījumos, piemēram, globālā aptauja, straumēšanas skaitīšana, darbību izsekošana utt. G-komplekti tiek ļoti izmantoti, lai ieviestu blokķēdes tehnoloģiju. Piemēram, Bitcoins izmanto tikai pievienotu blokķēdes ierakstus.
Reģistrs: Stīgas, Hašiši
Reģistriem pēc būtības nav konfliktu. Viņi parasti ievēro LWW vai uz kvorumu balstītu konfliktu risināšanas politiku. 4. attēlā parādīts piemērs tam, kā reģistrs atrisina konfliktu, ievērojot LWW politiku.
Redis Labs Reģistrus galvenokārt izmanto, lai saglabātu kešatmiņu un sesiju datus, informāciju par lietotāja profilu, produktu katalogu utt.
2P komplekti
Divfāžu komplekti uztur divus G komplektu komplektus - vienu pievienoto priekšmetu un otru noņemto priekšmetu kopai. Kopijas sinhronizējot apmainās ar G kopas papildinājumiem. Konflikts rodas, ja abos kopumos tiek atrasts viens un tas pats elements. Dažās CRDT balstītās datubāzēs, piemēram, Redis Enterprise, to apstrādā politika “Pievienot uzvar pār dzēšanu”.
Redis Labs 2P komplekts ir laba datu struktūra kopīgu sesiju datu, piemēram, iepirkumu grozu, koplietojama dokumenta vai izklājlapas, glabāšanai.
Kā veidot lietojumprogrammu, lai izmantotu uz CRDT balstītu datu bāzi
Lietotnes pievienošana CRDT bāzes datu bāzei neatšķiras no lietojumprogrammas pievienošanas jebkurai citai datu bāzei. Tomēr konsekvences politikas dēļ jūsu lietojumprogrammai ir jāievēro noteikts noteikumu kopums, lai nodrošinātu konsekventu lietotāja pieredzi. Trīs taustiņi:
- Padariet savu pieteikumu bezvalstnieku. Bezvalstnieka lietojumprogramma parasti tiek virzīta uz API. Katra izsaukuma laikā uz API tiek atjaunots viss ziņojums no jauna. Tas nodrošina, ka jūs jebkurā brīdī vienmēr velkat tīru datu kopiju. Zema lokālā latentuma pakāpe, ko piedāvā CRDT bāzes datu bāze, ļauj ziņojumus rekonstruēt ātrāk un vienkāršāk.
- Izvēlieties pareizo CRDT, kas atbilst jūsu lietošanas gadījumam. Skaitītājs ir vienkāršākais no CRDT. To var izmantot tādos lietošanas gadījumos kā globāla balsošana, aktīvo sesiju izsekošana, mērīšana utt. Tomēr, ja vēlaties apvienot sadalīto objektu stāvokli, jāņem vērā arī citas datu struktūras. Piemēram, lietojumprogrammai, kas ļauj lietotājiem rediģēt koplietojamu dokumentu, iespējams, vēlēsities saglabāt ne tikai labojumus, bet arī to veikšanas secību. Tādā gadījumā labojumu saglabāšana uz CRDT balstītā sarakstā vai rindas datu struktūrā būtu labāks risinājums nekā to saglabāšana reģistrā. Ir arī svarīgi, lai jūs saprastu CRDT ieviesto konfliktu risināšanas semantiku un lai jūsu risinājums atbilstu noteikumiem.
- CRDT nav universāls risinājums. Lai gan CRDT patiešām ir lielisks rīks daudziem lietošanas gadījumiem, tas, iespējams, nav vislabākais visiem lietošanas gadījumiem (piemēram, ACID darījumiem). CRDT bāzes datubāzes parasti labi sader ar mikropakalpojumu arhitektūru, kur jums ir īpaša datu bāze katram mikropakalpojumam.
Šeit galvenais ir tas, ka jūsu lietojumprogrammai ir jākoncentrējas uz loģiku un datu pārvaldības un sinhronizācijas sarežģītība jādeleģē pamatā esošajai datu bāzei.
Lietojumprogrammu testēšana ar izplatītu multi-master datu bāzi
Lai panāktu ātrāku iziešanu tirgū, iesakām konsekventi izstrādāt, testēt, pakāpeniski un ražošanas iestatījumus. Cita starpā tas nozīmē, ka izstrādes un testēšanas iestatījumos ir jābūt miniaturizētam izplatītās datu bāzes modelim. Pārbaudiet, vai jūsu CRDT bāzes datu bāze ir pieejama kā Docker konteiners vai virtuāla ierīce. Izvietojiet datu bāzes kopijas dažādos apakštīklos, lai varētu simulēt savienoto un atvienoto kopu iestatījumus.
Lietojumprogrammu testēšana ar izplatītu daudzu galveno datu bāzi var šķist sarežģīta. Bet lielākoties viss, kas jums būs jāpārbauda, ir datu konsekvence un lietojumprogrammu pieejamība divās situācijās: kad sadalītās datu bāzes ir savienotas un starp datubāzēm ir tīkla nodalījums.
Izstrādes vidē izveidojot trīs mezglu izplatītu datu bāzi, vienības testēšanā varat aptvert (un pat automatizēt) lielāko daļu testēšanas scenāriju. Šeit ir pamatnostādnes lietojumprogrammu testēšanai:
