1. Priekšvārds
Nesen Redis projektā tika izmantots kā kešatmiņa, lai atvieglotu datu apmaiņu starp vairākiem biznesa procesiem. Tā kā Redis dati tiek glabāti atmiņā, ja noturība nav konfigurēta, visi dati tiks zaudēti pēc redis restartēšanas, tāpēc, lai saglabātu datus diskā, jums ir jāiespējo redis noturības funkcija, un, restartējot redis, varat atgūt datus no diska. Redis piedāvā divus veidus, kā saglabāt, RDB noturību (princips ir izmest Reids datu bāzes ierakstus atmiņā uz RDB noturību diskā) un otru ir AOF noturība (princips ir rakstīt Reids operāciju žurnālus failā pielikuma veidā). Tātad, kāda ir atšķirība starp šīm divām noturības metodēm un kā izvēlēties to mainīt? Lielākā daļa lietu, ko es lasīju internetā, iepazīstina ar to, kā konfigurēt un izmantot šīs divas metodes, bet nav ievada par atšķirību starp abām un kādiem pielietojuma scenārijiem izmantot.
2) Atšķirība starp abiem
RDB noturība attiecas uz datu kopas momentuzņēmuma ierakstīšanu atmiņā uz diska noteiktā laika intervālā, un faktiskais darbības process ir apakšprocesa sadalīšana, vispirms datu kopas ierakstīšana pagaidu failā un pēc tam iepriekšējā faila nomaiņa pēc veiksmīgas rakstīšanas un saglabāšana ar bināro saspiešanu.
AOF noturība ieraksta katru servera apstrādāto rakstīšanas un dzēšanas operāciju žurnāla veidā, un vaicājuma operācija netiks ierakstīta, bet tiks ierakstīta tekstā, un jūs varat atvērt failu, lai redzētu detalizētu operācijas ierakstu.
3. Abu priekšrocības un trūkumi
Kādas ir RDB priekšrocības?
1). Kad tas tiek izmantots, visā Redis datu bāzē būs tikai viens fails, kas ir ideāli piemērots failu dublēšanai. Piemēram, jūs varat arhivēt pēdējās 24 stundas katru stundu, kā arī arhivēt pēdējās 30 dienas katru dienu. Izmantojot šādu rezerves stratēģiju, mēs varam viegli atgūties sistēmas katastrofālas kļūmes gadījumā.
2). RDB ir ļoti laba izvēle katastrofu atjaunošanai. Tā kā mēs varam viegli saspiest vienu failu un pārsūtīt to uz citu datu nesēju.
3). Maksimāli palieliniet veiktspēju. Redis pakalpojuma procesam vienīgais, kas jādara, sākot noturību, ir atdalīt bērna procesus, un pēc tam bērna procesi pabeigs šos noturības uzdevumus, kas var ievērojami izvairīties no pakalpojuma procesa, kas veic IO darbības.
4). Salīdzinot ar AOF mehānismu, ja datu kopa ir liela, RDB palaišanas efektivitāte būs augstāka.
Kādi ir RDB trūkumi?
1). Ja vēlaties nodrošināt augstu datu pieejamību, t.i., maksimāli izvairīties no datu zuduma, tad RDB nebūs laba izvēle. Jo, tiklīdz sistēma pazūd pirms plānotās noturības, dati, kas iepriekš tika ierakstīti diskā, tiks zaudēti.
2). Tā kā RDB palīdz saglabāt datus, izmantojot dakšas apakšprocesus, ja datu kopa ir liela, tas var izraisīt visa servera apturēšanu simtiem milisekunžu vai pat 1 sekundes.
Kādas ir AOF priekšrocības?
1). Šis mehānisms var nodrošināt lielāku datu drošību, t.i., datu noturību. Redis ir 3 sinhronizācijas stratēģijas, proti, sinhronizācija sekundē, sinhronizācija pēc modifikācijas un desinhronizācija. Faktiski sinhronizācija sekundē tiek veikta arī asinhroni, un tās efektivitāte ir arī ļoti augsta, atšķirība ir tāda, ka, tiklīdz sistēma pazūd, modificētie dati tiks zaudēti šīs sekundes laikā. Un katru reizi, kad modifikācija tiek sinhronizēta, mēs to varam uzskatīt par sinhronizācijas noturību, tas ir, katra datu maiņa, kas notiek, tiek nekavējoties ierakstīta diskā. Paredzams, ka šī metode ir vismazāk efektīva. Kas attiecas uz sinhronizāciju, nav nepieciešams teikt vairāk, es domāju, ka visi to var pareizi saprast.
2). Tā kā mehānisms pieņem pievienošanas režīmu žurnālfailu rakstīšanai, pat ja rakstīšanas procesā ir dīkstāve, žurnālfailā jau esošais saturs netiks iznīcināts. Tomēr, ja mēs rakstām tikai pusi no datiem un sistēma šoreiz avarē, neuztraucieties, mēs varam izmantot rīku redis-check-aof, lai palīdzētu mums atrisināt datu konsekvences problēmu pirms nākamās Redis palaišanas.
3). Ja žurnāls ir pārāk liels, Redis var automātiski iespējot pārrakstīšanas mehānismu. Tas nozīmē, ka Redis nepārtraukti raksta modifikācijas datus vecajā diska failā pievienošanas režīmā, un Redis arī izveidos jaunu failu, lai reģistrētu, kuras modifikācijas komandas tiek izpildītas šajā periodā. Tāpēc datu drošību var labāk garantēt, pārslēdzoties starp pārrakstījumiem.
4). AOF satur skaidru, viegli saprotamu žurnālfailu, kurā reģistrētas visas izmaiņas. Faktiski mēs varam arī pabeigt datu rekonstrukciju, izmantojot šo failu.
Kādi ir OV trūkumi?
1). Tādam pašam datu kopu skaitam OF faili parasti ir lielāki nekā RDB faili. RDB atgūst lielas datu kopas ātrāk nekā AOF.
2). Atkarībā no sinhronizācijas stratēģijas, AOF darbības efektivitātes ziņā mēdz būt lēnāks nekā RDB. Īsāk sakot, sinhronizācijas politikas efektivitāte sekundē ir salīdzinoši augsta, un sinhronās atspējošanas politikas efektivitāte ir tikpat efektīva kā RDB.
Abu izvēles kritēriji ir tas, vai sistēma ir gatava upurēt kādu veiktspēju apmaiņā pret augstāku kešatmiņas konsekvenci (AOF), vai arī tā ir gatava neiespējot dublējumus apmaiņā pret augstāku veiktspēju, kad rakstīšanas operācijas ir biežas, un pēc tam veikt dublējumus (RDB), palaižot Saglabāt manuāli. RDB ir galīgāka konsekventa nozīme. Tomēr ražošanas vide patiesībā ir vairāk abu kombinācija.
4. Kopējās konfigurācijas
RDB noturības konfigurācija
Redis izmet datu kopas momentuzņēmumu failā dump.rdb. Turklāt mēs varam arī mainīt Redis servera izgāztuvju momentuzņēmumu biežumu, izmantojot konfigurācijas failu, pēc 6379.conf faila atvēršanas mēs meklējam saglabāt, un mēs varam redzēt šādu konfigurācijas informāciju:
AOF pastāvīgā konfigurācija
Ir trīs veidi, kā sinhronizēt Redis profilu, tie ir:
Pilnīga konfigurācija:
Testa direktorijā tiks izveidots jauns fails "appendonly.aof" šādi:
|
Publicēts 04.02.2021 13:47:27
|
|
|
|
Saimnieks|
Publicēts 08.02.2021 11:45:25
|
Publicēts 22.09.2021 20:26:16