Basiscachepatronen implementeren

Stel dat je app gebruikersgegevens nodig heeft. Zo werkt Cache-Aside:

1. App vraagt gegevens op: Controleert Redis op user:123.
2. Cachemisser: Redis antwoordt met 'niet gevonden'.
3. App bevraagt database: Haalt user:123 uit de database.
4. App werkt cache bij: Slaat user:123 op in Redis.
5. App retourneert gegevens: Geeft de gegevens aan de gebruiker.
6. Volgende aanvragen: Redis bevat nu user:123, wat leidt tot een snelle 'cachetreffer'!

Laten we een Cache-Aside-leesstroom simuleren met Redis CLI. Eerst proberen we een sleutel op te halen die niet in de cache staat (misser). Daarna halen we de sleutel op uit een conceptuele database en slaan we hem op. Tot slot halen we de sleutel opnieuw op (treffer).

Voordelen:

• Eenvoud: Eenvoudig te implementeren.
• Leesintensieve werklasten: Uitstekend voor gegevens die vaak worden gelezen maar zelden veranderen.
• Actualiteit van gegevens: Nieuwe gegevens worden alleen aan de cache toegevoegd wanneer ze worden opgevraagd, waardoor cachevervuiling afneemt.

Nadelen:

• Initiële latentie: De eerste leesbewerking voor bepaalde gegevens resulteert altijd in een cachemiss, waardoor deze trager is.
• Verouderde gegevens: Als de database rechtstreeks wordt bijgewerkt, kan de cache oude gegevens bevatten totdat deze verlopen of expliciet ongeldig worden gemaakt.

Het write-throughpatroon zorgt ervoor dat gegevens tegelijkertijd naar zowel de cache als de primaire gegevensopslag (database) worden geschreven. De applicatie schrijft naar de cache en de cache is verantwoordelijk voor het schrijven van die gegevens naar de database.

• Wanneer gegevens worden geschreven, gaan ze eerst naar de cache.
• De cache schrijft de gegevens vervolgens onmiddellijk naar de database.
• De schrijfbewerking wordt pas als voltooid beschouwd nadat beide bewerkingen zijn geslaagd.

Stel dat je de prijs van een product bijwerkt. Zo werkt write-through:

1. De app schrijft gegevens: Stuurt de nieuwe productprijs voor product:202 naar Redis.
2. De cache schrijft naar de database: Redis schrijft dezelfde update onmiddellijk naar de database.
3. De cache bevestigt: Redis bevestigt de schrijfbewerking aan de applicatie pas nadat het schrijven naar de database is voltooid.
4. De app gaat verder: De applicatie gaat verder en weet dat de cache en de database consistent zijn.

Bij write-through voert je applicatie doorgaans één schrijfbewerking naar de cache uit. De cache (of een clientbibliotheek die het patroon implementeert) zorgt vervolgens voor de opslag in de database. Hier simuleren we het instellen van een waarde die conceptueel ook de database zou bijwerken.

Voordelen:

• Consistentie van gegevens: De cache en de database lopen altijd gelijk.
• Betrouwbaarheid: Gegevens worden onmiddellijk blijvend opgeslagen.
• Eenvoudiger lezen: Alle leesbewerkingen zijn cachehits (ervan uitgaande dat gegevens altijd via write-through worden geschreven).

Nadelen:

• Schrijflatentie: Schrijfbewerkingen zijn trager omdat gegevens twee keer moeten worden geschreven (cache + database).
• Cachevervuiling: Gegevens die naar de cache worden geschreven, worden mogelijk nooit gelezen, waardoor cacheruimte verloren gaat.
• Hogere belasting: Elke schrijfbewerking veroorzaakt een schrijfbewerking in de database, waardoor de database mogelijk zwaarder wordt belast.

Goed gedaan! Je hebt twee fundamentele cachestrategieën geleerd:

• Cache-aside: Je applicatie beheert de cache. Bij het lezen wordt eerst de cache gecontroleerd; bij een cachemiss worden de gegevens uit de database opgehaald, in de cache opgeslagen en vervolgens teruggegeven. Het meest geschikt voor leesintensieve gegevens.
• Write-through: Schrijfbewerkingen gaan naar de cache, die de gegevens vervolgens onmiddellijk naar de database schrijft. Dit zorgt voor sterke consistentie tussen de cache en de database.

Deze patronen vormen de basis voor geavanceerdere cachestrategieën die je in toekomstige lessen gaat verkennen!