Veelgebruikte cachingpatronen

Welkom! In deze les verkennen we veelgebruikte cachingpatronen. Dit zijn gestructureerde manieren waarop je applicatie met een cache communiceert om de prestaties te verbeteren en gegevens te beheren.

Zie ze als blauwdrukken voor de manier waarop gegevens stromen tussen je applicatie, de cache en de belangrijkste gegevensopslag, zoals een database.

Cache-Aside (ook wel Lazy Loading genoemd) is een zeer populair cachingpatroon. Bij deze aanpak is je applicatie verantwoordelijk voor het rechtstreeks beheren van de cache.

• De applicatie controleert de cache eerst op gegevens.
• Als de gegevens worden gevonden (een "cachetreffer"), worden ze direct teruggegeven.
• Als de gegevens niet worden gevonden (een "cachemisser"), haalt de applicatie ze uit de database, slaat ze op in de cache en geeft ze vervolgens terug.

Zo werkt een leesbewerking doorgaans met Cache-Aside:

// Pseudocode for reading data
function getData(key):
  data = cache.get(key)
  if data is null:
    data = database.get(key)
    cache.put(key, data)
  return data

Zo bevat de cache alleen gegevens die daadwerkelijk worden opgevraagd, waardoor geheugen wordt bespaard voor gegevens die minder vaak worden gebruikt.

Wanneer gegevens worden bijgewerkt met het Cache-Aside-patroon, schrijft de applicatie eerst naar de database en maakt daarna het bijbehorende item in de cache ongeldig (verwijdert het).

// Pseudocode for writing data
function updateData(key, newData):
  database.update(key, newData)
  cache.invalidate(key) // Remove from cache
  return success

Door het item ongeldig te maken, wordt het volgende leesverzoek voor deze gegevens een cachemisser. Daardoor worden de actuele gegevens uit de database opgehaald en wordt de cache bijgewerkt.

Bij het patroon Read-Through fungeert de cache als tussenpersoon voor alle leesverzoeken. De applicatie communiceert voor leesbewerkingen niet rechtstreeks met de database.

• De applicatie vraagt de gegevens op bij de cache.
• Als de cache de gegevens heeft (treffer), geeft hij ze terug.
• Als de cache de gegevens niet heeft (misser), haalt de cache ze zelf uit de database, slaat ze intern op en geeft ze vervolgens terug aan de applicatie.

De applicatie praat alleen met de cache, waardoor de logica eenvoudiger wordt.

Hoewel het leesgedrag vergelijkbaar is, is het belangrijkste verschil wie de gegevens bij een misser ophaalt:

• Cache-Aside: de applicatie verwerkt de cachemisser en haalt de gegevens uit de database.
• Read-Through: de cacheprovider (bijvoorbeeld een cachingbibliotheek of -service) verwerkt de misser en haalt de gegevens uit de database.

Read-Through leidt vaak tot overzichtelijkere applicatiecode, omdat de cachinglogica centraal in de cachelaag staat.

Het patroon Write-Through zorgt voor gegevensconsistentie door gegevens synchroon naar zowel de cache als de database te schrijven.

• De applicatie schrijft de gegevens naar de cache.
• De cache schrijft dezelfde gegevens vervolgens onmiddellijk naar de database.
• Pas nadat beide bewerkingen zijn geslaagd, bevestigt de cache de schrijfbewerking aan de applicatie.

Zo blijven de cache en database altijd gesynchroniseerd, maar kunnen schrijfbewerkingen meer vertraging oplopen.

Write-Back (ook wel Write-Behind genoemd) geeft prioriteit aan schrijfprestaties. Wanneer de applicatie gegevens schrijft:

• Worden de gegevens onmiddellijk naar de cache geschreven en bevestigt de cache het succes aan de applicatie.
• De onderliggende database wordt op een later moment asynchroon op de achtergrond bijgewerkt.

Dit zorgt voor zeer weinig vertraging bij schrijfbewerkingen, maar brengt het risico van gegevensverlies met zich mee als de cache uitvalt voordat de gegevens in de database zijn opgeslagen.

Welk patroon je kiest, hangt af van je behoeften:

• Cache-Aside: geschikt voor werklasten met veel leesbewerkingen, waarbij verouderde gegevens gedurende korte tijd na schrijfbewerkingen acceptabel zijn. De app beheert de complexiteit.
• Read-Through: vereenvoudigt app-code voor leesbewerkingen; de cache verwerkt de interactie met de database.
• Write-Through: zorgt voor sterke consistentie tussen cache en database, maar geeft meer vertraging bij schrijfbewerkingen.
• Write-Back: het beste voor veel schrijfbewerkingen met weinig vertraging; bij een cache-uitval bestaat het risico op gegevensverlies.

Goed gedaan! Je hebt de belangrijkste cachingpatronen geleerd:

• Cache-Aside: de applicatie beheert de cache, met lazy loading en ongeldigmaking bij het schrijven.
• Read-Through: de cache fungeert als gegevensbron en haalt gegevens bij een misser uit de database.
• Write-Through: synchrone schrijfbewerkingen naar cache en database voor consistentie.
• Write-Back: asynchrone schrijfbewerkingen naar de database voor betere prestaties, met een groter risico.

Elk patroon heeft sterke punten; kies verstandig op basis van de behoeften van je applicatie voor lees- en schrijf頻quentie, consistentie en vertraging.