1. Pratarmė
Pastaruoju metu "Redis" buvo naudojama kaip talpykla projekte, siekiant palengvinti dalijimąsi duomenimis tarp kelių verslo procesų. Kadangi "Redis" duomenys saugomi atmintyje, jei patvarumas nesukonfigūruotas, visi duomenys bus prarasti paleidus "Redis" iš naujo, todėl turite įjungti "Redis" patvarumo funkciją, kad išsaugotumėte duomenis diske, o paleidę "Redis" iš naujo, galėsite atkurti duomenis iš disko. Redis pateikia du išlikimo būdus: RDB patvarumą (principas yra išmesti Reidso duomenų bazės įrašus į atmintį į RDB patvarumą diske) ir kitą – AOF atkaklumą (principas yra įrašyti Reidso operacijų žurnalus į failą priedo pavidalu). Taigi, kuo skiriasi šie du patvarumo metodai ir kaip pasirinkti jį pakeisti? Dauguma dalykų, kuriuos perskaičiau internete, supažindina su šių dviejų metodų konfigūravimu ir naudojimu, tačiau nėra įvado, kuo skiriasi šie du metodai ir kokius taikymo scenarijus naudoti.
2. Skirtumas tarp šių dviejų
RDB patvarumas reiškia atmintyje esančio duomenų rinkinio momentinės nuotraukos įrašymą į diską per nurodytą laiko intervalą, o tikrasis operacijos procesas yra išsišakoti antrinį procesą, pirmiausia įrašyti duomenų rinkinį į laikinąjį failą, o po to pakeisti ankstesnį failą, kai rašymas sėkmingas, ir saugoti jį dvejetainiu glaudinimu.
AOF patvarumas įrašo kiekvieną serverio apdorotą rašymo ir naikinimo operaciją žurnalo pavidalu, o užklausos operacija nebus įrašyta, o bus įrašyta tekste, ir jūs galite atidaryti failą, kad pamatytumėte išsamų operacijos įrašą.
3. Jų privalumai ir trūkumai
Kokie yra RDB pranašumai?
1). Kai tai bus panaudota, visoje "Redis" duomenų bazėje bus tik vienas failas, kuris puikiai tinka atsarginėms failų kopijoms kurti. Pavyzdžiui, galite archyvuoti paskutines 24 valandas kas valandą, taip pat archyvuoti pastarąsias 30 dienų kiekvieną dieną. Turėdami tokią atsarginės kopijos strategiją, galime lengvai atsigauti katastrofiško sistemos gedimo atveju.
2). RDB yra labai geras pasirinkimas atkūrimui po nelaimių. Nes galime lengvai suspausti vieną failą ir perkelti jį į kitą laikmeną.
3). Maksimaliai padidinkite našumą. "Redis" aptarnavimo procesui vienintelis dalykas, kurį reikia padaryti pradedant atkaklumą, yra išsišakoti antrinius procesus, o tada antriniai procesai atliks šias patvarumo užduotis, o tai gali labai išvengti aptarnavimo proceso, atliekančio IO operacijas.
4). Palyginti su AOF mechanizmu, jei duomenų rinkinys yra didelis, RDB paleidimo efektyvumas bus didesnis.
Kokie yra RDB trūkumai?
1). Jei norite užtikrinti aukštą duomenų prieinamumą, t.y. maksimaliai išvengti duomenų praradimo, tuomet RDB nebus geras pasirinkimas. Nes kai sistema sugenda prieš suplanuotą patvarumą, duomenys, kurie anksčiau buvo įrašyti į diską, bus prarasti.
2). Kadangi RDB padeda išlaikyti duomenis per šakių subprocesus, jei duomenų rinkinys yra didelis, visas serveris gali sustabdyti paslaugą šimtams milisekundžių ar net 1 sekundei.
Kokie yra AOF pranašumai?
1). Šis mechanizmas gali užtikrinti didesnį duomenų saugumą, t. y. duomenų patvarumą. "Redis" pateikiamos 3 sinchronizavimo strategijos, būtent sinchronizavimas per sekundę, sinchronizavimas per modifikaciją ir desinchronizavimas. Tiesą sakant, sinchronizavimas per sekundę taip pat atliekamas asinchroniškai, o jo efektyvumas taip pat yra labai didelis, skirtumas tas, kad kai sistema sugenda, modifikuoti duomenys bus prarasti per šią sekundę. Ir kiekvieną kartą, kai modifikacija sinchronizuojama, galime tai laikyti sinchronizavimo patvarumu, tai yra, kiekvienas įvykęs duomenų pakeitimas nedelsiant įrašomas į diską. Numatoma, kad šis metodas yra mažiausiai efektyvus. Kalbant apie sinchronizavimą, nereikia daugiau sakyti, manau, kad visi gali tai teisingai suprasti.
2). Kadangi mechanizmas priima žurnalo failų rašymo pridėjimo režimą, net jei rašymo proceso metu yra prastova, žurnalo faile jau esantis turinys nebus sunaikintas. Tačiau jei parašysime tik pusę duomenų ir sistema šį kartą sugenda, nesijaudinkite, galime naudoti redis-check-aof įrankį, kuris padės išspręsti duomenų nuoseklumo problemą prieš kitą "Redis" paleidimą.
3). Jei žurnalas yra per didelis, Redis gali automatiškai įjungti perrašymo mechanizmą. Tai reiškia, kad "Redis" nuolat įrašo modifikavimo duomenis į seną disko failą pridėjimo režimu, o "Redis" taip pat sukurs naują failą, kuriame užfiksuos, kurios modifikavimo komandos vykdomos per šį laikotarpį. Todėl duomenų saugumą galima geriau užtikrinti perrašant.
4). AOF yra aiškus, lengvai suprantamas žurnalo failas, kuriame įrašomi visi pakeitimai. Tiesą sakant, mes taip pat galime užbaigti duomenų rekonstrukciją per šį failą.
Kokie yra OV trūkumai?
1). Tam pačiam duomenų rinkinių skaičiui OF failai paprastai yra didesni nei RDB failai. RDB atkuria didelius duomenų rinkinius greičiau nei AOF.
2). Priklausomai nuo sinchronizavimo strategijos, AOF paprastai yra lėtesnis nei RDB veikimo efektyvumo požiūriu. Trumpai tariant, sinchronizavimo politikos efektyvumas per sekundę yra gana didelis, o sinchroninio išjungimo politikos efektyvumas yra toks pat efektyvus kaip RDB.
Šių dviejų pasirinkimo kriterijai yra tai, ar sistema yra pasirengusi paaukoti tam tikrą našumą mainais į didesnį talpyklos nuoseklumą (AOF), ar ji nori neįjungti atsarginių kopijų mainais į didesnį našumą, kai rašymo operacijos yra dažnos, ir tada daryti atsargines kopijas (RDB), kai paleidžiama Išsaugoti rankiniu būdu. RDB turi galutinę nuoseklią reikšmę. Tačiau gamybos aplinka iš tikrųjų yra labiau abiejų derinys.
4. Bendrosios konfigūracijos
RDB patvarumo konfigūracija
"Redis" iškelia duomenų rinkinio momentinę kopiją į failą dump.rdb. Be to, mes taip pat galime keisti "Redis" serverio iškelties momentinių nuotraukų dažnį per konfigūracijos failą, atidarę failą 6379.conf, ieškome išsaugoti ir galime pamatyti šią konfigūracijos informaciją:
AOF nuolatinė konfigūracija
Yra trys būdai, kaip sinchronizuoti "Redis" profilyje:
Pilna konfigūracija:
Bandymo kataloge bus sukurtas naujas failas "appendonly.aof", kaip nurodyta toliau:
|
Paskelbta 2021-02-04 13:47:27
|
|
|
|
Savininkas|
Paskelbta 2021-02-08 11:45:25
|
Paskelbta 2021-09-22 20:26:16