Redis instellen als cache en message broker

Redis draait in het geheugen en vergeet gegevens zodra het proces stopt — daarom bepaalt de configuratie of u Redis als cache of als message broker kunt gebruiken. Dit artikel legt uit hoe u Redis 7.2 instelt voor beide rollen, inclusief geheugenbeleid, persistentie en isolatie tussen functies.

Vereisten

• Redis 7.2 of nieuwer, geïnstalleerd op een Linux-server (Debian 12 of Ubuntu 22.04 aanbevolen)
• Root-toegang of een gebruiker met sudo-rechten
• Basiskennis van de Redis CLI (redis-cli)
• Voor de message broker-opstelling: een applicatie die Redis ondersteunt als broker, zoals Celery 5.3 of een eigen client

Stappen

1. Controleer de Redis-versie en status

redis-server --version
redis-cli ping

Redis 7.2 bevat alle functies die u nodig hebt: maxmemory, eviction policies, RDB-snapshots, AOF en Redis Streams. redis-cli ping moet PONG teruggeven; als dat niet gebeurt, start de service eerst met sudo systemctl start redis-server.

2. Configureer Redis als cache met geheugenlimiet en LRU

Open het configuratiebestand:

sudo nano /etc/redis/redis.conf

Stel een maximale geheugengrootte in en kies de eviction policy. Voor caching gebruikt u allkeys-lru, die de minst recent gebruikte sleutels verwijdert zodra het geheugen vol is:

maxmemory 4096mb
maxmemory-policy allkeys-lru

4096mb is een realistische limiet voor productie. Voor testdoeleinden kunt u 2mb gebruiken, maar verwacht dan agressieve eviction. De LRU-policy maakt TTL per sleutel overbodig: verouderde gegevens verdwijnen automatisch wanneer het geheugen vol raakt. TTL blijft nuttig voor sessiegegevens of authenticatietokens, maar niet voor generieke cache-objecten.

3. Schakel RDB-snapshots in voor cache-herstel

Redis kan periodiek een snapshot van alle gegevens naar schijf schrijven. Dit is voldoende voor een cache: na een herstart zijn de gegevens tijdelijk weg, maar de backend-database vult de cache opnieuw.

save 60 1

Dit commando schrijft een snapshot als er binnen 60 seconden minstens één wijziging is. Het bestand dump.rdb verschijnt in de Redis-werkmap. Voor cachegebruik is dit voldoende; u hebt geen AOF nodig, omdat verlies van cachegegevens geen blijvende schade oplevert.

4. Start Redis opnieuw en test de cache-configuratie

sudo systemctl restart redis-server
redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policy

Beide commando's moeten de ingestelde waarden tonen. Test nu of de eviction werkt door meer gegevens te schrijven dan de limiet toelaat:

redis-cli DEBUG POPULATE 1000000
redis-cli INFO memory | grep used_memory_human

Als used_memory_human rond de limiet blijft hangen, verwijdert Redis oude sleutels correct.

5. Configureer Redis als message broker met AOF-persistentie

Voor messaging mogen berichten niet verloren gaan. Redis Streams en lists bieden de queue-functionaliteit, maar zonder AOF overleeft geen enkel bericht een herstart. Open het configuratiebestand opnieuw:

sudo nano /etc/redis/redis.conf

Vervang de snapshot-instellingen door AOF:

appendonly yes
appendfsync everysec

appendfsync everysec schrijft elke seconde alle schrijfcommando's naar het AOF-bestand. Dit levert een goede balans tussen prestaties en veiligheid: u verliest maximaal één seconde aan berichten bij een crash. Zet save-regels uit, want RDB is niet betrouwbaar genoeg voor messaging.

6. Gebruik Redis Streams voor betrouwbare messaging

Redis Streams is de native oplossing voor pub/sub en taakwachtrijen. Een stream is een tijdgeordende log die meerdere consumenten ondersteunt, inclusief acknowledgements en backpressure.

Maak een stream aan en voeg een bericht toe:

redis-cli XADD task_queue '*' task send_email user 42

Lees berichten als consument:

redis-cli XREADGROUP GROUP workers consumer1 COUNT 10 STREAMS task_queue >

Deze opdracht leest nieuwe berichten die nog niet door een andere consument zijn verwerkt. Combineer dit met AOF: als Redis herstart, blijven zowel de stream als de consumenten-groepen intact.

7. Gebruik aparte Redis-instanties voor cache, broker en result store

Een enkele Redis-instantie voor zowel cache als messaging veroorzaakt interferentie: LRU-eviction kan actieve berichten verwijderen, en een volle cache vertraagt de queue. Gebruik daarom aparte instanties.

Maak een tweede Redis-service aan:

sudo cp /etc/redis/redis.conf /etc/redis/redis-broker.conf
sudo nano /etc/redis/redis-broker.conf

Wijzig minimaal deze instellingen:

port 6380
maxmemory 0
maxmemory-policy noeviction
appendonly yes
pidfile /var/run/redis/redis-server-broker.pid
logfile /var/log/redis/redis-server-broker.log

maxmemory 0 betekent onbeperkt geheugen, en noeviction zorgt ervoor dat Redis geen berichten verwijdert wanneer het geheugen vol raakt — het weigert dan nieuwe schrijfacties in plaats van bestaande te verwijderen. Start de tweede instantie:

sudo redis-server /etc/redis/redis-broker.conf --daemonize yes

Herhaal dit patroon voor een derde instantie voor de result store, bijvoorbeeld op poort 6381.

8. Verwijs applicaties naar de juiste instantie

Configureer uw applicatie met aparte URLs voor elke functie. OpenForms gebruikt deze variabelen:

CACHE_REDIS_URL=redis://localhost:6379/0
CELERY_BROKER_URL=redis://localhost:6380/0
CELERY_RESULT_BACKEND=redis://localhost:6381/0

De cache-instantie op poort 6379 heeft LRU en maximaal 4 GB. De broker op poort 6380 heeft AOF en geen eviction. De result store op poort 6381 slaat taakresultaten op met AOF — die gegevens mogen nooit verloren gaan.

Verificatie

Controleer of alle drie de instanties draaien en hun eigen configuratie hebben:

redis-cli -p 6379 INFO memory | grep maxmemory
redis-cli -p 6380 CONFIG GET appendonly
redis-cli -p 6381 CONFIG GET maxmemory-policy

De eerste moet `maxmemory: 4294967296` tonen (4 GB), de tweede `appendonly: yes`, en de derde `maxmemory-policy: noeviction`.

Test de broker door een bericht te verzenden en te lezen:

redis-cli -p 6380 XADD test_stream '*' message hello
redis-cli -p 6380 XREAD COUNT 1 STREAMS test_stream 0

Het tweede commando moet het zojuist toegevoegde bericht teruggeven. Herstart daarna de broker-instantie en lees opnieuw: het bericht moet nog steeds bestaan dankzij AOF.

Veelgestelde problemen

Redis start niet na het wijzigen van `maxmemory-policy`

Controleer of het configuratiebestand geen dubbele regels bevat. Redis gebruikt de laatste waarde, maar een syntaxfout in een andere regel kan de hele service laten weigeren. Test met `redis-server /etc/redis/redis.conf --test-memory 1` en controleer de log: `sudo journalctl -u redis-server -n 50`.

Berichten verdwijnen na een herstart ondanks AOF

Controleer of `appendonly` op `yes` staat in de actieve configuratie: `redis-cli CONFIG GET appendonly`. Als dit `no` teruggeeft, gebruikte Redis een ander configuratiebestand. Controleer ook het AOF-bestand: `ls -lh /var/lib/redis/appendonly.aof`. Een leeg bestand betekent dat Redis AOF niet heeft geactiveerd tijdens de herstart.

LRU verwijdert actieve berichten in de queue

Dit gebeurt wanneer cache en broker dezelfde instantie delen. Zet `maxmemory-policy` op `noeviction` voor de broker-instantie, of beter: gebruik aparte instanties zoals beschreven in stap 7. `noeviction` zorgt ervoor dat Redis weigert nieuwe gegevens te schrijven in plaats van bestaande te verwijderen.

De keuze tussen RDB en AOF is geen prestatiekwestie, maar een betrouwbaarheidskwestie — een cache die gegevens verliest is een irritatie, een broker die berichten verliest is een storing. Door de rollen te scheiden over aparte instanties houd je beide systemen voorspelbaar, en dat is precies waarom Redis in cloudnative architecturen standhoudt als zowel cache als message broker.