|
|
Geplaatst op 04-02-2021 13:47:27
|
|
|
|
1. Voorwoord
Onlangs is Redis gebruikt als cache in het project om gegevensuitwisseling tussen meerdere bedrijfsprocessen te faciliteren. Omdat Redis-gegevens in het geheugen worden opgeslagen, gaat alle data verloren na een herstart van Redis als persistentie niet is geconfigureerd, dus moet je de persistentiefunctie van Redis inschakelen om de data op de schijf op te slaan, en wanneer Redis opnieuw wordt opgestart, kun je data van de schijf terughalen. Redis biedt twee manieren om te behouden: RDB-persistentie (het principe is om de databaserecords van Reids in het geheugen te dumpen naar RDB-persistentie op de schijf) en de andere is AOF-persistentie (het principe is om de operationele logboeken van Reids in een bestand te schrijven in de vorm van een appendix). Wat is dus het verschil tussen deze twee persistentiemethoden, en hoe kies je ervoor om die te veranderen? De meeste dingen die ik op internet lees geven aan hoe je deze twee methoden configureert en gebruikt, maar er is geen introductie over het verschil tussen de twee en in welke toepassingsscenario's je moet gebruiken.
2. Het verschil tussen de twee
RDB-persistentie verwijst naar het schrijven van een snapshot van de dataset in het geheugen naar de schijf binnen een gespecificeerd tijdsinterval, en het daadwerkelijke proces bestaat uit het forken van een subproces, eerst de dataset naar een tijdelijk bestand schrijven, en vervolgens het vorige bestand vervangen nadat het schrijven succesvol is, en het opslaan met binaire compressie.
AOF-persistentie registreert elke schrijf- en verwijderoperatie die door de server wordt verwerkt in de vorm van een logboek, en de queryoperatie wordt niet vastgelegd, maar in tekst vastgelegd, en je kunt het bestand openen om het gedetailleerde operatierecord te bekijken.
3. Voordelen en nadelen van de twee
Wat zijn de voordelen van RDB?
1). Zodra dit is gebruikt, bevat je volledige Redis-database slechts één bestand, wat perfect is voor bestandsback-ups. Je wilt bijvoorbeeld de laatste 24 uur per uur archiveren, en ook elke dag de laatste 30 dagen. Met zo'n back-upstrategie kunnen we gemakkelijk herstellen in het geval van een catastrofale storing van het systeem.
2). RDB is een zeer goede keuze voor rampenherstel. Omdat we eenvoudig één bestand kunnen comprimeren en naar een ander opslagmedium kunnen overzetten.
3). Maximaliseer de prestaties. Voor het Redis-serviceproces hoeft het alleen bij het starten van persistentie de kindprocessen uit te splitsen, waarna de kindprocessen deze persistentietaken uitvoeren, waardoor het serviceproces in grote mate IO-operaties hoeft uit te voeren.
4). In vergelijking met het AOF-mechanisme zal de opstartefficiëntie van RDB hoger zijn als de dataset groot is.
Wat zijn de nadelen van RDB?
1). Als je een hoge beschikbaarheid van data wilt waarborgen, oftewel dataverlies zo veel mogelijk wilt voorkomen, dan is RDB geen goede keuze. Want zodra het systeem uitvalt vóór de geplande persistentie, gaat de data die eerder op de schijf was geschreven verloren.
2). Omdat RDB helpt bij datapersistentie via fork-subprocessen, kan het grote dataset ervoor zorgen dat de hele server de service voor honderden milliseconden, of zelfs 1 seconde, stopt.
Wat zijn de voordelen van AOF?
1). Dit mechanisme kan zorgen voor meer gegevensveiligheid, oftewel datapersistentie. Er zijn drie synchronisatiestrategieën in Redis, namelijk synchronisatie per seconde, synchronisatie per aanpassing en desynchronisatie. In feite gebeurt de synchronisatie per seconde ook asynchroon, en de efficiëntie ervan is ook zeer hoog; het verschil is dat zodra het systeem uitvalt, de gewijzigde data binnen deze seconde verloren gaan. En elke keer dat een wijziging wordt gesynchroniseerd, kunnen we het zien als synchronisatiepersistentie, dat wil zeggen, elke datawijziging die plaatsvindt wordt onmiddellijk op de schijf geregistreerd. Het is voorzienbaar dat deze methode het minst efficiënt is. Wat betreft geen synchronisatie, is er geen reden om meer te zeggen, ik denk dat iedereen het goed kan begrijpen.
2). Aangezien het mechanisme de append-modus gebruikt voor het schrijven van logbestanden, zal zelfs bij een stilstand tijdens het schrijfproces de reeds bestaande inhoud in het logbestand niet worden vernietigd. Maar als we deze keer maar de helft van de data schrijven en het systeem crasht, maak je geen zorgen, we kunnen de redis-check-aof tool gebruiken om het probleem van dataconsistentie op te lossen voordat de volgende start van Resten begint.
3). Als het logboek te groot is, kan Redis automatisch het herschrijfmechanisme inschakelen. Dat wil zeggen, Redis schrijft continu de wijzigingsgegevens naar het oude schijfbestand in de append-modus, en Redis maakt ook een nieuw bestand aan om vast te leggen welke wijzigingscommando's in deze periode worden uitgevoerd. Daarom kan gegevensbeveiliging beter worden gegarandeerd bij het wisselen tussen herschrijvingen.
4). AOF bevat een duidelijk, gemakkelijk te begrijpen logbestand dat alle wijzigingen vastlegt. In feite kunnen we de reconstructie van de data ook voltooien via dit bestand.
Wat zijn de nadelen van OV?
1). Voor hetzelfde aantal datasets zijn OF-bestanden meestal groter dan RDB-bestanden. RDB herstelt grote datasets sneller dan AOF.
2). Afhankelijk van de synchronisatiestrategie is AOF doorgaans langzamer dan RDB qua efficiëntie. Kortom, de efficiëntie van het synchronisatiebeleid per seconde is relatief hoog, en de efficiëntie van het synchrone uitschakelbeleid is even efficiënt als die van RDB.
De criteria voor de keuze van de twee zijn of het systeem bereid is enige prestaties op te offeren in ruil voor hogere cache-consistentie (AOF), of dat het bereid is back-ups niet in te schakelen in ruil voor hogere prestaties wanneer schrijfbewerkingen frequent zijn, en vervolgens back-ups (RDB) te maken bij handmatig Save. RDB heeft een meer uiteindelijke, consistente betekenis. De productieomgeving is echter eigenlijk meer een combinatie van beide.
4. Veelvoorkomende configuraties
RDB-persistentieconfiguratie
Redis dumpt een snapshot van de dataset in het dump.rdb-bestand. Daarnaast kunnen we ook de frequentie van Redis-server-dumpsnapshots aanpassen via het configuratiebestand; na het openen van het 6379.conf-bestand zoeken we naar save, en we kunnen de volgende configuratie-informatie zien:
AOF persistente configuratie
Er zijn drie manieren om te synchroniseren in het Redis-profiel, die zijn:
Volledige configuratie:
Een nieuw bestand "appendonly.aof" wordt aangemaakt onder de testmap, als volgt:
|
Vorig:DataTables implementeert tabelexport, Excel, CSV en printenVolgend:SQL Server stelt het niveau van transactieisolatie in
|
Huisbaas|
Geplaatst op 08-02-2021 11:45:25
|
Geplaatst op 22-09-2021 20:26:16