Redis AOF - Wanneer je het gerust kunt uitschakelen voor betere prestaties

Redis is een krachtig in-memory gegevensopslag systeem. Snelheid is cruciaal, maar door de aard van "in-memory" is er een risico dat alle gegevens verloren gaan wanneer de server opnieuw opstart. Om dit te voorkomen, biedt Redis twee opties voor persistentie.

1. RDB (Snapshotting): Slaat een snapshot op van alle gegevens op een bepaald moment naar de schijf.

2. AOF (Append Only File): Houdt alle schrijfopdrachten (Write) bij in een logbestand in volgorde.

AOF biedt in vergelijking met RDB een bijna garantie dat er geen gegevens verloren gaan (meestal binnen 1 seconde). Maar het registreren van alle schrijfactiviteiten in een bestand brengt duidelijke prestatiekosten met zich mee.

"Is AOF echt nodig voor alle Redis gebruikssituaties?"

Om maar meteen met de deur in huis te vallen: "Nee, absoluut niet."

Vandaag gaan we de gevallen bekijken waarin je AOF niet nodig hebt en de situaties waarin het absoluut essentieel is.

Situaties waarin AOF niet nodig is

De kernwaarde van AOF ligt in de duurzaamheid van gegevens (Durability). Als deze duurzaamheid niet belangrijk is voor de gegevens, kan AOF een onnodige prestatievermindering veroorzaken die als een 'keten' kan voelen.

1. Wanneer het alleen als cache wordt gebruikt

Dit is de meest typische situatie.

• Reden: Gegevens in de cache zijn geen 'origineel'. Er bestaat een aparte 'bron van waarheid' zoals een database (DB) of een andere API.

• Bij gegevensverlies: Als Redis opnieuw opstart en de cache is gewist, zal de applicatie alleen even vertragen (Cache Miss), waarna de originele gegevens opnieuw kunnen worden gelezen om de cache weer op te vullen (Cache-Warm up). De gegevens zijn niet permanent verloren.

• Conclusie: Wanneer het gaat om cachegebruik, wordt AOF vaak volledig uitgeschakeld, net als RDB. Het volledig elimineren van schijf I/O maximaliseert de pure in-memory snelheid van Redis.

2. Celery broker / resultaat backend (minder belangrijke taken)

Redis wordt vaak samen met Celery gebruikt. Bij Redis als broker en resultaat backend in Celery is er een 'belang van de taak' als voorwaarde bij het AOF-instellingen.

• Reden: Als de taken die door Celery worden afgehandeld 'geen probleem zijn als ze falen' of 'gemakkelijk opnieuw kunnen worden geprobeerd', dan is AOF niet nodig.

• Voorbeelden:

  • Analyse van gebruikerslogboeken (het is geen groot probleem als een paar seconden aan logboeken verloren gaan)

  • Periodieke gegevensopruiming (kan opnieuw worden uitgevoerd bij de volgende cyclus)

  • Thumbnail-afbeelding maken (kan opnieuw worden gegenereerd omdat de originele afbeelding aanwezig is)

• Conclusie: In dit soort scenario's kan het zijn dat de taken of resultaten in de wachtrij verloren gaan als de Redis-server crasht. Maar als je deze verlies zakelijk kunt 'risico lopen', dan is het verstandig om AOF uit te schakelen en de prestaties van de broker veilig te stellen.

3. Eenvoudige statistieken en realtime gegevens (vluchtig)

Wanneer je met kortetermijntrends werkt of snel vernieuwende gegevens behandelt.

• Reden: Gegevens worden zeer kortstondig vernieuwd, of een snapshot op een bepaald moment heeft weinig betekenis.

• Voorbeelden:

  • Aantal websitebezoekers in het afgelopen minuut

  • Realtime game ranglijsten (verandert per seconde)

  • Tijdelijke sessiegegevens (verlopen binnen enkele minuten)

• Conclusie: Dit soort gegevens zal toch snel verdwijnen of vernieuwen. Het belang van de prestaties voor het snel verwerken van talloze schrijfverzoeken is veel groter dan het verliezen van enkele seconden aan gegevens. AOF is niet geschikt voor deze omgeving.

Situaties waarin AOF sterk wordt aanbevolen

Daarentegen, wanneer het verlies van gegevens in Redis ernstige problemen kan veroorzaken, is AOF een vereiste, geen keuze.

1. Betrouwbare berichtenwachtrij (Critical Celery Jobs)

Dit is het tegenovergestelde van het bovenstaande Celery-voorbeeld.

• Reden: De taak zelf is verbonden met geld of kern bedrijfslogica.

• Voorbeelden:

  • Betalingsverzoek verwerken

  • Voltooiing van de registratie en verzending van bevestigingsmail

  • Bestelverwerking

• Conclusie: Als een gebruiker op de 'betaal' knop drukt, en Redis start opnieuw op, waardoor het verzoek verdwijnt, is dat een ernstige storing. In dit scenario moet AOF worden ingeschakeld met de fsync everysec (standaardwaarde) optie om ervoor te zorgen dat taken onmiddellijk op de schijf worden geschreven zodra ze in de wachtrij komen.

2. Wanneer Redis als de primaire database wordt gebruikt

Wanneer Redis niet slechts als cache wordt gebruikt, maar als originele gegevensbron (Source of Truth).

• Reden: Er is geen aparte database, en Redis zelf slaat de oorspronkelijke gegevens op, dus gegevensverlies betekent permanente verlies.

• Voorbeelden:

  • Informatie over gebruikersprofielen

  • Gebruikerssessies die permanent moeten worden bewaard

  • Informatie over goederen (goud, items) in een spel

• Conclusie: In dit geval is AOF noodzakelijk, en moet het samen met RDB snapshots worden gebruikt voor een back-up- en herstelstrategie.

3. Transactie- en aggregatiegegevens

Wanneer de consistentie en nauwkeurigheid van gegevens uiterst belangrijk zijn.

• Reden: RDB slaat een 'specifiek moment' op, dus alle gegevens na de laatste snapshot gaan verloren. AOF slaat 'alle wijzigingsgeschiedenis' op, zodat gegevensverlies (maximaal 1 seconde) geminimaliseerd kan worden.

• Voorbeelden:

  • Volgen/ontvolgen relaties

  • Nauwkeurige telling van stemmen

  • Financiële gegevens (eenvoudige stortingen en opnames)

• Conclusie: Wanneer de uiteindelijke consistentie van gegevens belangrijk is, is de 'Append-Only' eigenschap van AOF veel geschikter dan die van RDB.

Conclusie: De trade-off tussen duurzaamheid en prestaties

AOF is een krachtige functie die Duurzaamheid (Durability) aan Redis biedt. Maar deze functie komt met een kosten in prestaties (Performance).

Als je twijfelt of je AOF moet inschakelen, overweeg dan de volgende vragen:

"Als de Redis-server nu onverwacht uitvalt, zal het verliezen van gegevens van de recente minuten (RDB) of 1 seconde (AOF) ernstige problemen voor onze service veroorzaken?"

• "Nee, we kunnen het opnieuw berekenen (cache)." -> Schakel AOF uit.

• "Ja, de betalingsgeschiedenis gaat verloren." -> Zorg ervoor dat AOF aan staat.

Net als bij elke technische beslissing is er geen juiste antwoord. Het is belangrijk om de gegevenskenmerken en vereisten van je service nauwkeurig te begrijpen en de juiste trade-off te maken.