Redis on edistynyt avain-arvo-tietokanta. Se on samankaltainen kuin memcached, mutta data voidaan säilyttää ja tietotyypit ovat rikkaita. Siellä on merkkijonoja, linkitettyjä listoja, joukkoja ja järjestettyjä kokoelmia. Se tukee kokoelmien summan, leikkaamisen ja täydentävän (erotuksen) laskemista palvelinpuolella, ja tukee myös erilaisia lajittelufunktioita. Joten Redis voidaan nähdä myös tietorakenteen palvelimena.
Kaikki Redis-data tallennetaan muistiin ja tallennetaan levylle asynkronisesti ajoittain (tätä kutsutaan "puolipysyväksi tilaksi"); Voit myös kirjoittaa jokaisen datan muutoksen Append Only -tiedostoon (AOF) (tätä kutsutaan "täyden pysyvyystilaksi").
Ensimmäinen menetelmä on filesnapshotting: oletusredis säilyttää datan levylle snapshotin muodossa (binääritiedosto, dump.rdb, tämän tiedoston nimi voidaan määrittää), ja konfiguraatiotiedoston muoto on: tallenna N M tarkoittaa, että N sekunnin kuluessa redis ottaa snapshotin levylle, jos vähintään M muutosta tapahtuu redisissä. Tietenkin voimme myös manuaalisesti suorittaa tallennuksen tai bgsave-toiminnon (asynkroninen) ottaaksemme snapshotteja.
Tässä lyhyt johdanto siihen, miten se toimii: Kun Redis tarvitsee jatkamista, Redis haarautuu lapsiprosessin; Lapsiprosessi kirjoittaa tiedot väliaikaiseen RDB-tiedostoon levylle; Kun aliprosessi saa väliaikaisen tiedoston valmiiksi, se korvaa alkuperäisen RDB:n, jolla on copy-on-write -etuna
On myös persistenssimenetelmä Appendonly:filesnapshotting method Kun Redis on epänormaalisti kuollut, viimeisimmät tiedot katoavat (kadonneen datan määrä riippuu tallennuskäytännön konfiguraatiosta), joten tämä on sen suurin haittapuoli: kun liiketoiminnan volyymi on suuri, menetetty data on paljon. Pelkkä liitemenetelmä voi aiheuttaa kaiken datan menetyksen, mutta Redisin suorituskyky on heikompi. AOF voidaan säilyttää koko prosessin ajan, se tarvitsee vain kytkeä päälle konfiguraatiotiedostossa (oletus on ei), liitteenonly kyllä. Kun AOF on käytössä, joka kerta kun redis suorittaa komennon datan muokkaamiseksi, se lisätään aof-tiedostoon, ja kun redis käynnistetään uudelleen, AOF-tiedosto luetaan "uudelleenkatseluun" palauttaakseen viimeiseen hetkeen ennen redisin sulkemista.
LOGIN uudelleenkirjoitus Kun AOF-tiedosto kasvaa yhä suuremmaksi datan muokatessa, ja monet tietueista muuttuvat avaimessa. Siksi Redisilla on mielenkiintoinen ominaisuus: AOF-tiedoston rekonstruointi taustalla vaikuttamatta asiakaspuolen toimintaan. BGREWRITEAOF-komennon suorittaminen milloin tahansa kirjoittaa levylle lyhimmän komentosarjan nykyisestä muistista, ja nämä komennot voivat rakentaa nykyisen datatilanteen täysin ilman tarpeettomia muutoksia (kuten tilan muutoksia, laskurimuutoksia jne.), mikä pienentää AOF-tiedoston kokoa. Joten kun käytät OF:ää, Redis suosittelee myös BGREWRITEAOFia.
AOF-tiedoston päivittämiseen on kolme tapaa, katso konfiguraatioparametri appendfsync: appendfsync kutsuu aina fsynciä AOF-tiedostoon joka kerta, kun muutoskomento lähetetään, mikä on hyvin, hyvin hidasta, mutta myös erittäin turvallista; appendfsync everysec kutsuu fsynciä joka sekunti ja siirtyy nopeasti AOF-tiedostoon, mutta voi menettää dataa sekunnissa; appendfsync ei luottaa käyttöjärjestelmään päivityksessä, Redis ei aktiivisesti päivitä OV:ta, joka on nopein, mutta turvallisuus on heikko. Päivitys sekunnissa suositellaan oletuksena, jotta sekä nopeus että turvallisuus otetaan huomioon.
Järjestelmäsyistä voi johtua AOF on vioittunut, Redis ei enää voi ladata tätä OF OV:ta, voit seurata alla olevia ohjeita korjataksesi sen: Tee ensin varmuuskopio AOF-tiedostosta ja kopioi se toiseen paikkaan; Korjaa alkuperäinen OF-tiedosto, suorita: $redis-check-aof –fix; Voit käyttää diff –u -komentoa nähdäksesi, missä tiedostot ovat epäjohdonmukaisia ennen ja jälkeen korjauksen. Käynnistä Redis-palvelu uudelleen.
Miten LOG Rewrite toimii: Sama käyttää copy-on-writea: ensin Redis haarautuu lapsiprosessin; Lapsiprosessi kirjoittaa viimeisimmän AOF:n väliaikaiseen tiedostoon; Vanhempi prosessi kirjoittaa viimeisimmät suoritetut muutokset asteittain muistiin (tällä hetkellä vanha AOF on yhä kirjoitettu, ja on turvallista kirjoittaa uudelleen, jos se epäonnistuu); Kun lapsiprosessi lopettaa väliaikaisen tiedoston uudelleenkirjoittamisen, vanhempi prosessi saa signaalin ja kirjoittaa aiemmat inkrementaaliset muutokset muistiin väliaikaisen tiedoston loppuun. Redis nimeää vanhan OF-tiedoston uudelleen, nimeää väliaikaisen tiedoston uudelleen ja alkaa kirjoittaa uudelle OF:lle.
Lopuksi, varmuuden vuoksi (kone kaatuu tai levy kaatuu), muista säännöllisesti varmuuskopioida *rdb *.aof, joka on generoitu filesnapshottingilla tai Append-only:lla etäkoneelle. Käytän crontab-sovellusta SCP:hen puolen tunnin välein. En käyttänyt redisin master-slave-toimintoa, koska puolen tunnin varmuuskopiointi pitäisi riittää, ja mielestäni koneen hukkaan heittäminen on vähän turhaa, jos sinulla on master-slave. Tämä riippuu lopulta sovelluksesta.
|
Julkaistu 24.8.2017 16.37.45
|
|
|
