1. Előszó
Az utóbbi időben a Redis-t gyorstárként használják a projektben, hogy megkönnyítsék az adatmegosztást több üzleti folyamat között. Mivel a Redis adatai memóriában vannak tárolva, ha a kitartás nincs konfigurálva, minden adat elveszik a Redis újraindítása után, ezért be kell kapcsolni a Redis kitartási függvényét, hogy az adatokat a lemezre mentse, és amikor a Redis újraindításakor vissza tudod állítani az adatokat a lemezről. A Redis két módot kínál a tartósságra: az RDB kitartást (az elv az, hogy Reids adatbázis rekordjait a memóriába helyezik a lemezen lévő RDB tartósságra), a másik pedig az AOF kitartás (az elv az, hogy Reids műveleti naplóit egy fájlba írják melléklet formájában). Mi tehát a különbség e két kitartó módszer között, és hogyan lehet ezt megváltoztatni? Az interneten olvasott legtöbb dolog bemutatja, hogyan lehet konfigurálni és használni ezt a két módszert, de nincs bevezető a kettő közötti különbségbe, és hogy milyen alkalmazási helyzetekben érdemes használni.
2. A különbség a kettő között
Az RDB kitartás azt jelenti, hogy egy meghatározott időközön belül írják az adathalmazról a memóriában lévő pillanatképet a lemezre, és a tényleges műveleti folyamat egy alprocesszet, először egy ideiglenes fájlba írva az adathalmazt, majd az írás sikere után a korábbi fájl cseréje, és bináris tömörítéssel tárolja.
Az AOF kitartása minden írási és törlési műveletet naplóként rögzít, és a lekérdezési műveletet nem rögzítik, hanem szövegben rögzítik, és megnyithatod a fájlt, hogy meglásd a részletes műveleti rekordot.
3. A kettő előnyei és hátrányai
Mik az RDB előnyei?
1). Ha ezt használod, akkor az egész Redis adatbázisod csak egy fájlt tartalmaz, ami tökéletes a fájlmentésekhez. Például érdemes lehet archiválni az utolsó 24 órát óránként, illetve az utolsó 30 napot is minden nap. Egy ilyen tartalék stratégiával könnyen helyreállhatunk a rendszer katasztrofális meghibásodása esetén.
2). Az RDB nagyon jó választás katasztrófa-helyreállításhoz. Mert könnyen tömöríthetünk egyetlen fájlt, és áthelyezhetjük egy másik tárolóeszközre.
3). Maximális teljesítmény. A Redis szolgáltatási folyamat esetében a tartósság elindításához csak annyi dolog kell, hogy kiadja a gyermekfolyamatokat, majd a gyermek folyamatok teljesítik ezeket a persistenciás feladatokat, ami jelentősen megakadályozhatja, hogy a szolgáltatási folyamat IO műveleteket végezzen.
4). Az AOF mechanizmushoz képest, ha az adathalmaz nagy, az RDB indítási hatékonysága magasabb lesz.
Mik a RDB hátrányai?
1). Ha biztosítani akarod az adatok magas elérhetőségét, azaz a lehető legnagyobb mértékben az adatvesztést akarod elkerülni, akkor az RDB nem lesz jó választás. Mert ha a rendszer leáll az ütemezett tartósság előtt, a korábban a lemezre írt adatok elvesznek.
2). Mivel az RDB az adatok tartósságát támogatja a fork alfolyamatokon keresztül, ha az adatbázis nagy, az egész szerver akár több száz milliszekundumra vagy akár 1 másodpercre leállhat a szolgáltatásnak.
Mik az AOF előnyei?
1). Ez a mechanizmus nagyobb adatbiztonsági szintet hozhat, azaz adattartósságot. A Redis három szinkronizációs stratégiát kínál: szinkronizáció másodpercenként, szinkronizálás módosítás szerint és deszinkronizáció. Valójában a szinkronizáció másodpercenként is aszinkron módon történik, és a hatékonysága is nagyon magas, a különbség az, hogy ha a rendszer leáll, a módosított adatok ebben a másodpercben elvesznek. És minden alkalommal, amikor egy módosítást szinkronizálnak, gondolhatjuk úgy, mint szinkronizációs tartósságot, vagyis minden adatváltozást azonnal rögzítenek a lemezre. Előre látható, hogy ez a módszer a legkevésbé hatékony. Ami a szinkronizációt illeti, nincs szükség arra, hogy többet mondanunk, szerintem mindenki jól érti.
2). Mivel a mechanizmus a naplófájlok írásához az append módot használja, még ha az írás közben is leállás történik, a naplófájlban már meglévő tartalom nem pusztul meg. Azonban, ha ezúttal csak a felet írjuk meg, és a rendszer összeomlik, ne aggódj, használhatjuk a redis-check-aof eszközt, hogy megoldjuk az adatkonzisztenciás problémát a következő Redis kezdete előtt.
3). Ha a napló túl nagy, a Redis automatikusan engedélyezheti az újraírási mechanizmust. Vagyis a Redis folyamatosan írja a módosítási adatokat a régi lemezfájlba a kiegészítő módban, és egy új fájlt is létrehoz, hogy rögzítse, mely módosítási parancsok hajtódnak le ebben az időszakban. Ezért az adatbiztonság jobban garantálható az átírások közötti váltáskor.
4). Az AOF egy világos, könnyen érthető naplófájlt tartalmaz, amely minden módosítást rögzít. Valójában ezen a fájlon keresztül is befejezhetjük az adatok rekonstrukcióját.
Mik a OV hátrányai?
1). Ugyanannyi adathalmaznál az OF fájlok általában nagyobbak, mint az RDB fájlok. Az RDB gyorsabban nyeri el a nagy adathalmazokat, mint az AOF.
2). A szinkronizációs stratégiától függően az AOF általában lassabb, mint az RDB a működési hatékonyság szempontjából. Röviden: a szinkronizációs politika másodpercenkénti hatékonysága viszonylag magas, és a szinkron letiltási politika hatékonysága ugyanolyan hatékony, mint az RDB-é.
A két választás kritériuma az, hogy a rendszer hajlandó-e feláldozni némi teljesítményt a magasabb cache konzibilzivusért (AOF) cserébe, vagy hogy nem engedélyezi a mentéseket a jobb teljesítményért cserébe, amikor gyakoriak az írási műveletek, majd a mentést (RDB) végezni kézi mentés közben. Az RDB-nek véglegesebb, következetes jelentése van. Azonban a gyártási környezet valójában inkább a kettő kombinációja.
4. Gyakori konfigurációk
RDB tartósság konfigurációja
A Redis a dump.rdb fájlba helyezi az adathalmazról egy pillanatképet. Ezen felül módosíthatjuk a Redis szerver dump snapshot-ainak gyakoriságát is a konfigurációs fájlon keresztül, a 6379.conf fájl megnyitása után keresünk a mentést, és a következő konfigurációs információkat látjuk:
AOF tartós konfiguráció
A Redis profilban három szinkronizáció létezik:
Teljes konfiguráció:
A tesztkönyvtár alatt egy új "appendonly.aof" fájl készül az alábbiak szerint:
|
Közzétéve 2021. 02. 04. 13:47:27
|
|
|
|
Háziúr|
Közzétéve 2021. 02. 08. 11:45:25
|
Közzétéve 2021. 09. 22. 20:26:16