1. Esipuhe
Viime aikoina Redisiä on käytetty projektissa välimuistina helpottamaan tiedon jakamista useiden liiketoimintaprosessien välillä. Koska Redis-data tallennetaan muistiin, jos pysyvyyttä ei ole määritetty, kaikki data katoaa Redisin uudelleenkäynnistyksen jälkeen, joten sinun täytyy ottaa käyttöön Redisin persistenssitoiminto datan tallentamiseksi levylle, ja kun redis käynnistetään uudelleen, voit palauttaa tiedot levyltä. Redis tarjoaa kaksi tapaa säilyttää: RDB-pysyvyys (periaate on dumpata Reidsin tietokantatietueet muistiin RDB-persistenssiin levyllä) ja toinen on AOF-pysyvyys (periaate on kirjoittaa Reidsin operaatiolokit tiedostoon liitteen muodossa). Mikä siis on ero näiden kahden pysyvyysmenetelmän välillä, ja miten sitä voi muuttaa? Suurin osa internetistä lukemistani asioista esittelee, miten näitä kahta menetelmää konfiguroidaan ja käytetään, mutta ei ole mitään johdantoa näiden kahden erosta tai siitä, missä sovellustilanteissa kannattaa käyttää.
2. Ero näiden kahden välillä
RDB-pysyvyys tarkoittaa datasetin snapshotin kirjoittamista muistissa levylle tietyn ajan kuluessa, ja varsinainen toimintaprosessi on haarautua aliprosessi, ensin kirjoittaa datajoukko väliaikaiseen tiedostoon ja korvata edellinen tiedosto kirjoittamisen onnistumisen jälkeen sekä tallentaa se binääripakkauksella.
AOF:n pysyvyys tallentaa jokaisen palvelimen käsittelemän kirjoitus- ja poistotoiminnon lokitiedostona, eikä kyselyoperaatiota tallenneta, vaan se tallennetaan tekstiksi, ja voit avata tiedoston nähdäksesi yksityiskohtaisen operaatiotietueen.
3. Näiden kahden hyödyt ja haitat
Mitkä ovat RDB:n edut?
1). Kun tämä on käytetty, koko Redis-tietokantasi sisältää vain yhden tiedoston, mikä sopii täydellisesti varmuuskopiointiin. Esimerkiksi saatat haluta arkistoida viimeiset 24 tuntia joka tunti ja myös viimeiset 30 päivää joka päivä. Tällaisella varasuunnitelmalla voimme helposti toipua järjestelmän katastrofaalisen vian sattuessa.
2). RDB on erittäin hyvä valinta katastrofipalautukseen. Koska voimme helposti pakata yhden tiedoston ja siirtää sen toiselle tallennusvälineelle.
3). Maksimoi suorituskyky. Redis-palveluprosessille ainoa asia, mitä sen tarvitsee tehdä persistenssin käynnistämisessä, on haarautua lapsiprosessit, jolloin lapsiprosessit suorittavat nämä pysyvyystehtävät, mikä voi merkittävästi estää palveluprosessin suorittamasta IO-toimintoja.
4). Verrattuna AOF-mekanismiin, jos aineisto on suuri, RDB:n käynnistystehokkuus on korkeampi.
Mitkä ovat RDB:n haitat?
1). Jos haluat varmistaa datan korkean saatavuuden, eli välttää datan menetyksen mahdollisimman paljon, RDB ei ole hyvä valinta. Koska kun järjestelmä menee alas ennen suunniteltua pysyvyyttä, aiemmin levylle kirjoitettu data katoaa.
2). Koska RDB auttaa datan pysyvyyden läpi haarautumisaliprosessien kautta, jos datakanta on suuri, koko palvelin voi pysähtyä sadoiksi millisekunneiksi tai jopa sekunniksi.
Mitkä ovat AOF:n edut?
1). Tämä mekanismi voi lisätä tietoturvaa, eli datan pysyvyyttä. Redisissä on kolme synkronointistrategiaa: synkronointi sekunnissa, synkronointi per muokkaus ja desynkronointi. Itse asiassa synkronointi sekunnissa tapahtuu myös asynkronisesti, ja sen tehokkuus on myös erittäin korkea, ero on siinä, että kun järjestelmä kaatuu, muokattu data katoaa tässä sekunnissa. Ja joka kerta kun muutos synkronoidaan, voimme ajatella sitä synkronoinnin pysyvyytenä, eli jokainen datan muutos tallennetaan välittömästi levylle. On ennakoitavissa, että tämä menetelmä on vähiten tehokas. Mitä tulee synkronoinnin puutteeseen, ei tarvitse sanoa enempää, uskon että kaikki ymmärtävät sen oikein.
2). Koska mekanismi käyttää append-tilaa lokitiedostojen kirjoittamiseen, vaikka kirjoitusprosessin aikana olisi käyttökatkoa, lokitiedostossa jo olevaa sisältöä ei tuhoudu. Jos kuitenkin kirjoitamme vain puolet datasta ja järjestelmä kaatuu tällä kertaa, ei hätää, voimme käyttää redis-check-aof -työkalua ratkaisemaan datan johdonmukaisuusongelman ennen seuraavaa Redisin aloitusta.
3). Jos loki on liian suuri, Redis voi automaattisesti ottaa uudelleenkirjoitusmekanismin käyttöön. Toisin sanoen Redis kirjoittaa jatkuvasti muokkaustiedot vanhaan levytiedostoon liittämistilassa, ja Redis luo myös uuden tiedoston tallentamaan, mitkä muokkauskomennot suoritetaan tänä aikana. Näin ollen tietoturva voidaan taata paremmin uudelleenkirjoitusten välillä.
4). AOF sisältää selkeän, helposti ymmärrettävän lokitiedoston, joka tallentaa kaikki muutokset. Itse asiassa voimme myös viimeistellä datan rekonstruoinnin tämän tiedoston avulla.
Mitkä ovat OV:n haitat?
1). Samalla määrällä aineistoja OF-tiedostot ovat yleensä suurempia kuin RDB-tiedostot. RDB palauttaa suuret aineistot nopeammin kuin AOF.
2). Synkronointistrategiasta riippuen AOF on yleensä hitaampi kuin RDB suoritustehokkuuden suhteen. Lyhyesti sanottuna synkronointipolitiikan tehokkuus sekunnissa on suhteellisen korkea, ja synkronisen pois kytkemisen politiikan tehokkuus on yhtä tehokas kuin RDB:n.
Valintakriteerinä ovat, onko järjestelmä valmis uhraamaan osan suorituskyvystä korkeamman välimuistin johdonmukaisuuden (AOF) puolesta vai onko se valmis olemaan ottamatta varmuuskopioita käyttöön paremman suorituskyvyn vuoksi, kun kirjoitusoperaatioita tehdään usein, ja tehdä varmuuskopiot (RDB) manuaalisen Save-toiminnon aikana. RDB:llä on lopullisempi, johdonmukaisempi merkitys. Tuotantoympäristö on kuitenkin enemmän näiden kahden yhdistelmä.
4. Yleiset kokoonpanot
RDB-pysyvyyskonfiguraatio
Redis dumppaa datasetin snapshotin dump.rdb-tiedostoon. Lisäksi voimme myös muokata Redis-palvelimen dump-snapshottien tiheyttä konfiguraatiotiedoston kautta; avattuamme 6379.conf-tiedoston haemme tallennuksen ja näemme seuraavat konfiguraatiotiedot:
AOF pysyvä konfiguraatio
Redis-profiilissa on kolme tapaa synkronoida, ne ovat:
Täydellinen kokoonpano:
Testihakemistoon luodaan uusi tiedosto "appendonly.aof" seuraavasti:
|
Julkaistu 4.2.2021 13.47.27
|
|
|
|
Vuokraisäntä|
Julkaistu 8.2.2021 11.45.25
|
Julkaistu 22.9.2021 20.26.16