1. Prefață
Recent, Redis a fost folosit ca cache în proiect pentru a facilita partajarea datelor între mai multe procese de business. Deoarece datele Redis sunt stocate în memorie, dacă persistența nu este configurată, toate datele se vor pierde după repornirea Redis, așa că trebuie să activezi funcția de persistență a Redis pentru a salva datele pe disc, iar când redis este repornit, poți recupera datele de pe disc. Redis oferă două moduri de persistare: persistența RDB (principiul este să se extragă înregistrările bazei de date ale lui Reids în memorie pe persistența RDB pe disc) și cealaltă este persistența AOF (principiul este scrierea jurnalelor de operațiuni ale lui Reids într-un fișier sub forma unui anexă). Deci care este diferența dintre aceste două metode de persistență și cum să alegi să le schimbi? Majoritatea lucrurilor pe care le-am citit pe Internet explică cum să configurezi și să folosești aceste două metode, dar nu există nicio introducere în diferența dintre ele și în scenariile de aplicație folosite.
2. Diferența dintre cele două
Persistența RDB se referă la scrierea unei instantanee a setului de date în memorie pe disc într-un interval de timp specificat, iar procesul operațional real este de a bifurca un subproces, de a scrie mai întâi setul într-un fișier temporar, apoi de a înlocui fișierul anterior după ce scrierea a fost reușită și de a-l stoca cu compresie binară.
Persistența AOF înregistrează fiecare operațiune de scriere și ștergere procesată de server sub forma unui log, iar operația de interogare nu va fi înregistrată, ci va fi înregistrată în text, iar poți deschide fișierul pentru a vedea înregistrarea detaliată a operațiunii.
3. Avantaje și dezavantaje ale celor două
Care sunt avantajele RDB?
1). Odată ce aceasta este folosită, întreaga bază de date Redis va conține un singur fișier, ceea ce este perfect pentru backup-uri de fișiere. De exemplu, poate vrei să arhivezi ultimele 24 de ore în fiecare oră și, de asemenea, să arhivezi ultimele 30 de zile în fiecare zi. Cu o astfel de strategie de rezervă, ne putem recupera ușor în cazul unei defecțiuni catastrofale a sistemului.
2). RDB este o alegere foarte bună pentru recuperarea în caz de dezastru. Pentru că putem comprima ușor un singur fișier și să-l transferăm pe un alt mediu de stocare.
3). Maximizarea performanței. Pentru procesul de serviciu Redis, singurul lucru pe care trebuie să-l facă la pornirea persistenței este să depășească procesele copil, iar apoi procesele copilului vor finaliza aceste sarcini de persistență, ceea ce poate evita foarte mult efectuarea operațiunilor de IO.
4). Comparativ cu mecanismul AOF, dacă setul de date este mare, eficiența de pornire a RDB va fi mai mare.
Care sunt dezavantajele RDB?
1). Dacă doriți să asigurați o disponibilitate ridicată a datelor, adică să evitați pierderea datelor în cea mai mare măsură, atunci RDB nu va fi o alegere bună. Pentru că, odată ce sistemul se oprește înainte de persistența programată, datele care au fost scrise anterior pe disc vor fi pierdute.
2). Deoarece RDB ajută la persistența datelor prin subprocese fork, dacă setul de date este mare, poate determina întregul server să oprească serviciul pentru sute de milisecunde, sau chiar o secundă.
Care sunt avantajele AOF?
1). Acest mecanism poate aduce o securitate mai mare a datelor, adică persistența datelor. Există 3 strategii de sincronizare oferite în Redis, și anume sincronizare pe secundă, sincronizare pe modificare și desincronizare. De fapt, sincronizarea pe secundă se face și asincron, iar eficiența sa este foarte ridicată, diferența fiind că odată ce sistemul cade, datele modificate se vor pierde în această secundă. Și de fiecare dată când o modificare este sincronizată, putem să o privim ca pe o persistență a sincronizării, adică fiecare schimbare de date care are loc este înregistrată imediat pe disc. Este previzibil că această metodă este cea mai puțin eficientă. În ceea ce privește lipsa sincronizării, nu este nevoie să spunem mai mult, cred că toată lumea poate înțelege corect.
2). Deoarece mecanismul adoptă modul de adăugare pentru scrierea fișierelor de jurnal, chiar dacă există o perioadă de nefuncționare în timpul procesului de scriere, conținutul deja existent în fișierul de jurnal nu va fi distrus. Totuși, dacă scriem doar jumătate din date și sistemul se blochează de data aceasta, nu vă faceți griji, putem folosi instrumentul redis-check-aof pentru a ne ajuta să rezolvăm problema consistenței datelor înainte de următoarea pornire a Redis.
3). Dacă jurnalul este prea mare, Redis poate activa automat mecanismul de rescriere. Adică, Redis scrie continuu datele de modificare în vechiul fișier de disc în modul de adăugare, iar Redis va crea și un fișier nou pentru a înregistra comenzile de modificare executate în această perioadă. Prin urmare, securitatea datelor poate fi mai bine asigurată atunci când se comută între rescrieri.
4). AOF conține un fișier de jurnal clar, ușor de înțeles, care înregistrează toate modificările. De fapt, putem finaliza și reconstrucția datelor prin acest fișier.
Care sunt dezavantajele OV?
1). Pentru același număr de seturi de date, fișierele OF sunt de obicei mai mari decât fișierele RDB. RDB recuperează seturi mari de date mai rapid decât AOF.
2). În funcție de strategia de sincronizare, AOF tinde să fie mai lent decât RDB în ceea ce privește eficiența de funcționare. Pe scurt, eficiența politicii de sincronizare pe secundă este relativ ridicată, iar eficiența politicii de dezactivare sincronă este la fel de eficientă ca cea a RDB.
Criteriile pentru alegerea celor două sunt dacă sistemul este dispus să sacrifice o parte din performanță în schimbul unei consistențe mai ridicate ale cache-ului (AOF) sau dacă este dispus să nu permită backup-uri în schimbul performanței superioare atunci când operațiunile de scriere sunt frecvente, și apoi să facă backup-uri (RDB) când rulează manual Salvarea. RDB are o semnificație finală, mai consecventă. Totuși, mediul de producție este de fapt mai degrabă o combinație a celor două.
4. Configurații comune
Configurația de persistență RDB
Redis extrage o imagine a setului de date în fișierul dump.rdb. În plus, putem modifica frecvența snapshot-urilor dump-urilor serverului Redis prin fișierul de configurare; după deschiderea fișierului 6379.conf, căutăm save și putem vedea următoarele informații de configurare:
Configurația persistentă AOF
Există trei moduri de a sincroniza în profilul Redis, acestea sunt:
Configurație completă:
Un nou fișier "appendonly.aof" va fi creat sub directorul de test, după cum urmează:
|
Postat pe 04.02.2021 13:47:27
|
|
|
|
Proprietarul|
Postat pe 08.02.2021 11:45:25
|
Postat pe 22.09.2021 20:26:16