Configurer Redis comme cache et courtier de messages

Redis tourne en mémoire et oublie les données dès que le processus s'arrête — c'est pourquoi la configuration détermine si vous pouvez utiliser Redis comme cache ou comme message broker. Cet article explique comment configurer Redis 7.2 pour ces deux rôles, y compris la politique de mémoire, la persistance et l'isolation entre les fonctions.

Prérequis

• Redis 7.2 ou plus récent, installé sur un serveur Linux (Debian 12 ou Ubuntu 22.04 recommandé)
• Accès root ou un utilisateur avec les droits `sudo`
• Connaissances de base de la CLI Redis (`redis-cli`)
• Pour la configuration du message broker : une application qui prend en charge Redis comme broker, comme Celery 5.3 ou un client propre

Étapes

1. Vérifiez la version et le statut de Redis

redis-server --version
redis-cli ping

Redis 7.2 contient toutes les fonctionnalités dont vous avez besoin : `maxmemory`, politiques d'éviction, snapshots RDB, AOF et Redis Streams. `redis-cli ping` doit retourner `PONG` ; si ce n'est pas le cas, démarrez d'abord le service avec `sudo systemctl start redis-server`.

2. Configurez Redis comme cache avec limite de mémoire et LRU

Ouvrez le fichier de configuration :

sudo nano /etc/redis/redis.conf

Définissez une taille de mémoire maximale et choisissez la politique d'éviction. Pour la mise en cache, utilisez `allkeys-lru`, qui supprime les clés les moins récemment utilisées dès que la mémoire est pleine :

maxmemory 4096mb
maxmemory-policy allkeys-lru

`4096mb` est une limite réaliste pour la production. Pour les tests, vous pouvez utiliser `2mb`, mais attendez-vous à une éviction agressive. La politique LRU rend le TTL par clé superflu : les données obsolètes disparaissent automatiquement lorsque la mémoire est pleine. Le TTL reste utile pour les données de session ou les jetons d'authentification, mais pas pour les objets de cache génériques.

3. Activez les snapshots RDB pour la récupération du cache

Redis peut écrire périodiquement un snapshot de toutes les données sur le disque. Cela suffit pour un cache : après un redémarrage, les données sont temporairement absentes, mais la base de données backend remplit à nouveau le cache.

save 60 1

Cette commande écrit un snapshot s'il y a au moins une modification dans les 60 secondes. Le fichier `dump.rdb` apparaît dans le répertoire de travail de Redis. Pour un usage en cache, cela suffit ; vous n'avez pas besoin d'AOF, car la perte de données de cache ne cause pas de dommages permanents.

4. Redémarrez Redis et testez la configuration du cache

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

Les deux commandes doivent afficher les valeurs configurées. Testez maintenant si l'éviction fonctionne en écrivant plus de données que la limite ne le permet :

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

Si `used_memory_human` reste autour de la limite, Redis supprime correctement les anciennes clés.

5. Configurez Redis comme message broker avec persistance AOF

Pour la messagerie, les messages ne doivent pas être perdus. Redis Streams et les listes offrent la fonctionnalité de file d'attente, mais sans AOF, aucun message ne survit à un redémarrage. Ouvrez à nouveau le fichier de configuration :

sudo nano /etc/redis/redis.conf

Remplacez les paramètres de snapshot par AOF :

appendonly yes
appendfsync everysec

`appendfsync everysec` écrit chaque seconde toutes les commandes d'écriture dans le fichier AOF. Cela offre un bon équilibre entre performances et sécurité : vous perdez au maximum une seconde de messages en cas de crash. Désactivez les règles `save`, car RDB n'est pas assez fiable pour la messagerie.

6. Utilisez Redis Streams pour une messagerie fiable

Redis Streams est la solution native pour le pub/sub et les files de tâches. Un stream est un journal ordonné dans le temps qui prend en charge plusieurs consommateurs, y compris les accusés de réception et la backpressure.

Créez un stream et ajoutez un message :

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

Lisez les messages en tant que consommateur :

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

Cette commande lit les nouveaux messages qui n'ont pas encore été traités par un autre consommateur. Combinez cela avec AOF : si Redis redémarre, le stream et les groupes de consommateurs restent intacts.

7. Utilisez des instances Redis distinctes pour le cache, le broker et le result store

Une seule instance Redis pour le cache et la messagerie provoque des interférences : l'éviction LRU peut supprimer des messages actifs, et un cache plein ralentit la file d'attente. Utilisez donc des instances distinctes.

Créez un deuxième service Redis :

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

Modifiez au minimum ces paramètres :

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` signifie une mémoire illimitée, et `noeviction` garantit que Redis ne supprime pas de messages lorsque la mémoire est pleine — il refuse alors de nouvelles écritures au lieu de supprimer les existantes. Démarrez la deuxième instance :

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

Répétez ce modèle pour une troisième instance pour le result store, par exemple sur le port 6381.

8. Référencez les applications vers la bonne instance

Configurez votre application avec des URLs distinctes pour chaque fonction. OpenForms utilise ces variables :

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

L’instance de cache sur le port 6379 utilise LRU et un maximum de 4 Go. Le broker sur le port 6380 utilise AOF et aucune éviction. Le stockage de résultats sur le port 6381 enregistre les résultats de tâches avec AOF — ces données ne peuvent jamais être perdues.

Vérification

Vérifiez que les trois instances tournent et ont leur propre configuration :

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

La première doit afficher `maxmemory: 4294967296` (4 Go), la deuxième `appendonly: yes`, et la troisième `maxmemory-policy: noeviction`.

Testez le broker en envoyant et en lisant un message :

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

La deuxième commande doit retourner le message qui vient d’être ajouté. Redémarrez ensuite l’instance du broker et lisez à nouveau : le message doit toujours exister grâce à AOF.

Problèmes fréquents

Redis ne démarre pas après la modification de `maxmemory-policy`

Vérifiez que le fichier de configuration ne contient pas de lignes en double. Redis utilise la dernière valeur, mais une erreur de syntaxe dans une autre ligne peut faire refuser le service entier. Testez avec `redis-server /etc/redis/redis.conf --test-memory 1` et vérifiez le journal : `sudo journalctl -u redis-server -n 50`.

Les messages disparaissent après un redémarrage malgré AOF

Vérifiez que `appendonly` est sur `yes` dans la configuration active : `redis-cli CONFIG GET appendonly`. Si cela retourne `no`, Redis utilisait un autre fichier de configuration. Vérifiez aussi le fichier AOF : `ls -lh /var/lib/redis/appendonly.aof`. Un fichier vide signifie que Redis n’a pas activé AOF pendant le redémarrage.

LRU supprime des messages actifs dans la file d’attente

Cela se produit lorsque le cache et le broker partagent la même instance. Mettez `maxmemory-policy` sur `noeviction` pour l’instance du broker, ou mieux : utilisez des instances séparées comme décrit à l’étape 7. `noeviction` fait en sorte que Redis refuse d’écrire de nouvelles données plutôt que de supprimer celles qui existent.

Le choix entre RDB et AOF n’est pas une question de performance, mais de fiabilité — un cache qui perd des données est une nuisance, un broker qui perd des messages est une panne. En séparant les rôles sur des instances distinctes, vous gardez les deux systèmes prévisibles, et c’est précisément pour cela que Redis tient le coup dans les architectures cloud natives, à la fois comme cache et comme broker de messages.