Redis on täiustatud võtme-väärtuse andmebaas. See on sarnane memcachedile, kuid andmeid saab säilitada ja andmetüübid on rikkalikud. On stringe, seotud loendeid, komplekte ja järjestatud kogumikke. See toetab kogude summamise, lõikumise ja täiendamise (erinevuse) arvutamist serveri poolel ning toetab ka mitmesuguseid sorteerimisfunktsioone. Seega võib Redist vaadelda ka andmestruktuuri serverina. Kõik Redis andmed salvestatakse mällu ja seejärel salvestatakse aeg-ajalt asünkroonselt kettale (seda nimetatakse "poolpüsivaks režiimiks"); Sa saad ka iga andmemuudatuse kirjutada Append Only faili (AOF) (seda nimetatakse "täispüsivuse režiimiks"). Esimene meetod on filesnapshotting: vaikimisi redis säilitab andmed kettale hetktõmmise kujul (binaarfail, dump.rdb, selle failinime saab määrata), ja konfiguratsioonifaili formaat on: salvesta N M tähendab, et N sekundi jooksul võtab redis kettale hetktõmmise, kui redis'is toimub vähemalt M muudatust. Loomulikult saame ka käsitsi salvestada või salvestada (asünkroonne), et teha hetktõmmisi.
Siin on lühike sissejuhatus, kuidas see töötab: Kui Redis peab püsima, teeb Redis lapsprotsessi haru; Lapsprotsess kirjutab andmed ajutisse RDB-faili kettal; Kui alamprotsess lõpetab ajutise faili kirjutamise, asendab ta algse RDB, millel on copy-on-write eelis
On olemas ka püsivuse meetod Appendonly:filesnapshotting meetod. Kui Redis on ebanormaalselt surnud, kaovad hiljutised andmed (kadunud andmete hulk sõltub sinu salvestuspoliitika konfiguratsioonist), seega on see suurim puudus – kui ärimaht on suur, on kadunud andmeid palju. Ainult lisameetod võib põhjustada kogu andmekaotuse, kuid Redis jõudlus on kehvem. AOF-i saab säilitada kogu protsessi vältel, see tuleb sisse lülitada ainult konfiguratsioonifailis (vaikimisi mitte), ainult appendonly jah. Kui AOF on lubatud, lisatakse iga kord, kui redis täidab käsu andmete muutmiseks, see aof faili ning kui redis taaskäivitatakse, loetakse AOF fail "taasesituseks" ja taastatakse viimasele hetkele enne redis sulgemist.
LOGI ümberkirjutamine Kui AOF fail muutub andmete muutmisel järjest suuremaks, paljud neist kirjed muutuvad võtmes. Seetõttu on Redis'il huvitav funktsioon: AOF faili taastamine taustal ilma kliendipoolset operatsiooni mõjutamata. BGREWRITEAOF käsu täitmine igal ajal kirjutab kettale lühima käsude jada praeguses mälus ning need käsud võimaldavad täielikult konstrueerida praeguse andmeolukorra ilma tarbetute muudatusteta (näiteks oleku muutused, loenduri muutused jne), vähendades AOF faili suurust. Seega, kui kasutad OF-i, soovitab redis kasutada ka BGREWRITEAOF-i.
AOF-faili värskendamiseks on kolm viisi, vt konfiguratsiooniparameetrit appendfsync: appendfsync kutsub alati fsync'i, et iga kord, kui esitatakse muudatuskäsk, mis on väga, väga aeglane, kuid ka väga turvaline; appendfsync iga sekund kutsub fsynci iga sekundi tagant, et kiiresti AOF faili jõuda, kuid võib kaotada andmed sekundi jooksul; appendfsync ei tugine operatsioonisüsteemile värskenduseks, Redis ei värskenda aktiivselt OV-i, mis on kõige kiirem, kuid turvalisus on kehv. Vaikimisi soovitatakse värskendust sekundis, et arvestada nii kiirust kui turvalisust.
Võib-olla on AOF rikutud süsteemilistel põhjustel, Redis ei saa enam seda OF OV-d laadida, saad alljärgnevaid samme järgida, et seda parandada: Esiteks tee AOF failist varukoopia ja kopeeri see teise kohta; Paranda algne OF-fail, käivita: $redis-check-aof –fix; Saad kasutada käsku diff–u, et näha, kus failid on enne ja pärast parandamist ebajärjekindlad. Taaskäivita Redis teenus.
Kuidas LOG Rewrite töötab: Sama kasutab copy-on-write: esmalt hargneb Redis lapsprotsessi; Alamprotsess kirjutab viimase AOF ajutisele failile; Vanemprotsess kirjutab järk-järgult viimased täidetud muudatused mällu (praegu kirjutatakse vana AOF endiselt ja on ohutu ümber kirjutada, kui see ebaõnnestub); Kui lapsprotsess lõpetab ajutise faili ümberkirjutamise, saab vanemprotsess signaali ja kirjutab eelnevad inkrementaalsed muudatused mälus ajutise faili lõppu. Redis nimetab vana OF-faili ümber, nimetab ajutise faili ümber ja hakkab kirjutama uuele OF-ile.
Lõpuks, juhuks kui masin või ketas kokku jookseb, pea meeles regulaarselt varundada *rdb *.aof faili, mis genereeritakse failide napshottingu või Append-only abil kaugmasinasse. Ma kasutan iga poole tunni tagant Crontabi SCP-ks. Ma ei kasutanud redis'i master-slave funktsiooni, sest poole tunni varukoopia peaks piisama, ja mulle tundub, et see on masina raiskamine, kui sul on master-slave. See sõltub lõpuks rakendusest.
|