Redis basics: waar het voor dient en wanneer je het gebruikt
Kort antwoord
Redis is een in-memory datastore. Omdat alles wat Redis bijhoudt in RAM staat in plaats van op schijf, zijn lees- en schrijfacties extreem snel. Daarom wordt het gebruikt voor caching, sessieopslag en lichte message queues. Diezelfde snelheid komt met een afweging: data in het geheugen is kwetsbaarder dan data op schijf, tenzij je bewust persistentie configureert.
Wat Redis eigenlijk is
Redis slaat data op als key-value paren in het geheugen, met ondersteuning voor een handvol nuttige structuren naast gewone strings: lists, sets, sorted sets, hashes en een eenvoudig publish/subscribe-mechanisme. Het draait meestal als aparte service waarmee je applicatie praat via het netwerk of een lokale socket, vergelijkbaar met hoe je met een database praat, maar met een veel kleinere, snellere set aan operaties.
De drie meest voorkomende toepassingen
Caching
De meestgebruikte toepassing. Als een databasequery of berekening duur is om uit te voeren, maar het resultaat niet vaak verandert, sla het resultaat dan op in Redis met een vervaltijd. De volgende aanvraag voor dezelfde data leest hem dan direct uit het geheugen in plaats van opnieuw de database te raken. Dat is zowel sneller voor de gebruiker als lichter voor de belasting op de database.
Sessieopslag
Webapplicaties hebben een plek nodig om sessiedata bij te houden, zoals wie er is ingelogd. Bij één applicatieserver is dat triviaal: sessies kunnen gewoon in het lokale geheugen van die server leven. Dat houdt op triviaal te zijn zodra je meer dan één applicatieserver draait, want de volgende aanvraag van een gebruiker kan op een andere server terechtkomen die zijn sessie nog nooit heeft gezien. Redis lost dit op door elke applicatieserver een gedeelde, snelle plek te geven om sessiedata te lezen en schrijven.
Eenvoudige message queues
De list- en pub/sub-commando's van Redis worden vaak gebruikt om kleine taken of berichten tussen services door te geven, bijvoorbeeld door een job in de wachtrij te zetten die een background worker oppikt. Het is geen volwaardige message broker, maar voor eenvoudige wachtrijbehoeften voorkom je er wel een zwaarder stuk infrastructuur mee.
De afweging: snelheid versus duurzaamheid
Redis is snel, grotendeels omdat het niet bij elke operatie de schijf hoeft te raken. Dat is meteen ook de belangrijkste beperking als primair systeem van record. Stopt het Redis-proces zonder dat er persistentie is geconfigureerd, dan is alles wat het bijhield verdwenen.
Redis biedt wel opties voor persistentie, en het is de moeite waard om te begrijpen wat elke optie precies beschermt:
| Optie | Wat het doet | Afweging |
|---|---|---|
| RDB snapshotting | Schrijft periodiek een snapshot van de complete dataset op een bepaald moment naar schijf | Snel en compact, maar alles wat sinds de laatste snapshot is geschreven, gaat verloren bij een crash |
| AOF (append-only file) | Logt elke schrijfoperatie naar schijf op het moment dat die plaatsvindt | Veel betere duurzaamheid, maar meer schijf-I/O en een groter bestand om af te spelen bij een herstart |
Je kunt beide combineren, en beide zijn af te stellen op hoe vaak ze naar schijf synchroniseren. Het punt is niet dat Redis onveilig is, maar dat duurzaamheid geen standaardgedrag is dat je gratis krijgt: het is iets wat je bewust configureert zodra je begrijpt wat je daarmee inlevert. Heeft een workload gegarandeerde duurzaamheid echt als belangrijkste vereiste, dan is dat een reden om voor de data die nooit verloren mag gaan te leunen op een schijfgebaseerde database, en Redis te gebruiken voor de onderdelen van het systeem waar snelheid belangrijker is dan permanentie.