Redis-caching en berichtenuitwisseling (Pub/Sub, Streams) · Les

Strategieën voor cache-invalidatie

Leer gecachete gegevens actueel en consistent te houden met TTL's, write-through, write-behind en eventgestuurde invalidatie in Redis.

Les 4 van 413 stappen

Strategieën voor cache-invalidatie is een gratis Redis-caching en berichtenuitwisseling (Pub/Sub, Streams)-les op CoddyKit. Dit is les 4 van 4. Je kunt 3 lessen uit dit leerpad gratis volledig lezen — daarna ontgrendelt CoddyKit PRO alle lessen, plus praktische oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Redis-caching en berichtenuitwisseling (Pub/Sub, Streams). Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Redis-caching en berichtenuitwisseling (Pub/Sub, Streams) bevat in totaal 4 lessen.

Waarom invalidatie belangrijk is

Caching versnelt leesbewerkingen, maar een cache die verouderde gegevens teruggeeft, kan erger zijn dan helemaal geen cache. Cache-invalidation is het verwijderen of vernieuwen van items wanneer de onderliggende bron van waarheid verandert.

Dit is berucht lastig: er zijn maar twee moeilijke dingen in de informatica, en een daarvan is cache-invalidation.

Verlopen op basis van TTL

De eenvoudigste strategie is time-to-live. Je accepteert dat gegevens maximaal N seconden verouderd kunnen zijn.

SET key value EX 60 verloopt na 60 seconden
EXPIRE key 60 stelt een TTL in op een bestaande sleutel
TTL key toont het resterende aantal seconden

SET user:42:profile "...json..." EX 60
TTL user:42:profile
EXPIRE user:42:profile 120

Write-through-caching

Bij write-through-caching gaat elke schrijfbewerking in dezelfde bewerking naar zowel de database als de cache. Leesbewerkingen zijn altijd actueel, maar schrijven duurt langer.

De applicatie is verantwoordelijk voor het synchroon houden van beide.

def save_user(user):
    db.update(user)
    redis.set('user:' + user.id, serialize(user))
    return user

Write-behind-caching

Write-behind (write-back) schrijft eerst naar de cache en schrijft de gegevens asynchroon door naar de database. Schrijfbewerkingen zijn snel, maar je riskeert gegevensverlies als Redis uitvalt voordat het doorschrijven plaatsvindt.

Gebruik een wachtrij of stream om openstaande schrijfbewerkingen tijdelijk op te slaan.

redis.set('order:' + id, data)
redis.lpush('pending_writes', id)

Expliciet verwijderen bij bijwerken

Het patroon cache-aside + verwijderen: verwijder bij elke update van de database de gecachte sleutel. De volgende leesbewerking vult de cache opnieuw.

Zo voorkom je dat verouderde gegevens worden teruggegeven en hoef je de cachewaarde niet synchroon te houden.

def update_product(p):
    db.update(p)
    redis.delete('product:' + p.id)

Waarom verwijderen beter is dan bijwerken

Door de sleutel te verwijderen (in plaats van deze te overschrijven) voorkom je een raceconditie: twee gelijktijdige updates zouden anders waarden in de verkeerde volgorde kunnen schrijven. Na verwijderen haalt de volgende leesbewerking altijd de nieuwste waarde uit de bron van waarheid.

Versiebeheerde sleutels

Verhoog in plaats van invalidatie een versienummer dat in de sleutel is opgenomen. Oude sleutels verlopen vanzelf via TTL, terwijl nieuwe leesbewerkingen de nieuwe sleutel gebruiken.

INCR config:version
GET config:version
SET config:v7:settings "..."

Gebeurtenisgestuurde invalidatie

Publiceer een invalidatiegebeurtenis wanneer gegevens veranderen. Andere applicatieknooppunten abonneren zich daarop en wissen hun lokale caches. Hiermee combineer je Redis Pub/Sub met caching.

redis.publish('invalidate', 'user:42')
# subscribers:
redis.subscribe('invalidate')

Invalidatie op basis van tags

Groepeer gerelateerde sleutels in een tagset. Wanneer een tag ongeldig wordt, verwijder je alle bijbehorende sleutels in één keer.

SADD tag:user:42 product:1 product:2
Bij een wijziging: SMEMBERS tag:user:42 en daarna op elke sleutel DEL

SADD tag:user:42 cart:42 wishlist:42
SMEMBERS tag:user:42

Stampedes voorkomen

Wanneer een populaire sleutel verloopt, kunnen veel aanvragen tegelijk de database belasten (een cache stampede). Beperk dit met een korte vergrendeling, probabilistisch vroegtijdig verlopen of door iets verouderde gegevens terug te geven terwijl één worker de cache vernieuwt.

SET lock:user:42 1 NX EX 5

Een strategie kiezen

Er is geen aanpak die altijd het beste is:

TTL voor aanvaardbare veroudering
Verwijderen bij schrijven voor correctheid
Gebeurtenisgestuurd voor consistentie tussen meerdere knooppunten
Versiebeheer voor grootschalige configuratiewijzigingen

Korte controle

Test je begrip van invalidatiestrategieën.

Beantwoord dit in de interactieve les

Samenvatting

Je hebt de belangrijkste strategieën voor cache-invalidation geleerd: verlopen via TTL, write-through, write-behind, verwijderen bij schrijven, versiebeheer van sleutels, gebeurtenisgestuurde invalidatie en invalidatie op basis van tags, plus manieren om cache stampedes te voorkomen. Kies de strategie die past bij je tolerantie voor verouderde gegevens en je consistentiebehoeften.

Gratis beginnen

Leer Redis-caching en berichtenuitwisseling (Pub/Sub, Streams) met een AI-tutor — gratis

Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.

Cursussen: 12
Lessen: 48

Gratis beginnen met leren Bekijk de volledige cursus

Veelgestelde vragen

Is de les “Strategieën voor cache-invalidatie” gratis?

Ja — je kunt hier op het web alle 3 lessen van het leerpad Redis-caching en berichtenuitwisseling (Pub/Sub, Streams), waaronder “Strategieën voor cache-invalidatie”, gratis volledig lezen. Daarna ontgrendelt CoddyKit PRO alle lessen, plus interactieve oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. De cursus Redis-caching en berichtenuitwisseling (Pub/Sub, Streams) bevat in totaal 4 lessen.

Wat leer ik in “Strategieën voor cache-invalidatie”?

Leer gecachete gegevens actueel en consistent te houden met TTL's, write-through, write-behind en eventgestuurde invalidatie in Redis. Je oefent met Redis-caching en berichtenuitwisseling (Pub/Sub, Streams) door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.

Heb ik ervaring nodig om met Redis-caching en berichtenuitwisseling (Pub/Sub, Streams) te beginnen?

Ervaring vooraf is niet nodig. Redis-caching en berichtenuitwisseling (Pub/Sub, Streams) op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 4 van 4.

Hoe lang duurt de les “Strategieën voor cache-invalidatie”?

De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.

Kan ik code schrijven en uitvoeren in deze les over Redis-caching en berichtenuitwisseling (Pub/Sub, Streams)?

Ja. Elke les over Redis-caching en berichtenuitwisseling (Pub/Sub, Streams) bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.

Alle lessen in deze cursus

← Terug naar Redis-caching en berichtenuitwisseling (Pub/Sub, Streams)