Charges Redis de cache et de file d’attente sur Dockup

Les charges de cache et de file d’attente Redis peuvent utiliser le même service Redis managé, mais leurs exigences en matière de cohérence sont différentes. Un cache peut généralement être reconstruit après une perte. Une file d’attente peut représenter des tâches qui ne doivent pas être supprimées silencieusement ni traitées deux fois.

Dockup provisionne Redis comme une base de données managée, fournit des opérations de dimensionnement et de consultation des logs, prend en charge les workflows de sauvegarde et de migration des nœuds, et peut connecter la base de données aux services applicatifs via le réseau privé du projet.

Comment provisionner Redis managé ?

Créez Redis dans l’espace de travail sélectionné :

dockup db create \
  --name app-redis \
  --type redis \
  --json

Vérifiez la cible de la base de données :

dockup db list --json

Stockez les informations de connexion retournées en dehors du dépôt de code, puis transmettez-les au service consommateur en tant que secret :

dockup env set REDIS_URL="$REDIS_URL" \
  --secret \
  -s production/api \
  --json

dockup deploy production/api --wait --json

Le redeploy crée un nouveau conteneur applicatif avec l’environnement mis à jour. Un redémarrage de l’ancien conteneur n’applique pas une nouvelle valeur souhaitée qui vient d’être enregistrée.

Utilisez des bases de données ou des instances Redis distinctes lorsque le comportement d’éviction du cache et la rétention des files d’attente critiques ne doivent pas entrer en concurrence pour la même mémoire. L’isolation simplifie également le diagnostic des incidents et le contrôle des accès.

Quand utiliser Redis comme cache ?

Un cache réduit le travail répétitif ou la latence en stockant des données dérivées. La source de vérité reste ailleurs, généralement dans PostgreSQL, MySQL, MongoDB, une API externe ou un calcul déterministe.

Une conception de cache robuste définit :

• Le format et l’espace de noms des clés.
• La durée de vie.
• Le niveau maximal de fraîcheur acceptable.
• Le déclencheur d’invalidation.
• Le comportement en cas de cache miss.
• Le comportement lorsque Redis est indisponible.
• La protection contre l’effet de thundering herd.
• Les données qui ne doivent jamais être mises en cache.

Défaillance	Comportement sûr du cache
Clé absente	Recalculer ou lire la source de vérité
Redis indisponible	Basculer vers la source avec une protection contre la surcharge
Entrée obsolète	Expirer ou invalider
Changement de sérialisation	Versionner l’espace de noms des clés
Pression mémoire	Évincer en priorité les données reconstructibles
Clé très sollicitée	Ajouter un cache local, du sharding ou une coalescence des requêtes

Ne rendez pas toute l’application indisponible uniquement parce qu’un cache facultatif est hors service. Utilisez des timeouts bornés et des chemins de fallback. En revanche, ne masquez pas toutes les défaillances : une panne prolongée du cache peut surcharger la base de données source.

Qu’est-ce qui change lorsque Redis est utilisé comme file d’attente de tâches ?

Une file d’attente représente des tâches en attente ; l’application doit donc définir les sémantiques de livraison et de récupération. Redis est lui-même un serveur de structures de données ; les garanties dépendent de la bibliothèque de file d’attente et du protocole des workers.

Déterminez :

1. Quand une tâche est-elle considérée comme acceptée ?
2. Quand est-elle acquittée ?
3. Que se passe-t-il si un worker tombe en panne après avoir effectué l’effet de bord, mais avant l’acquittement ?
4. Comment les retries sont-ils retardés et plafonnés ?
5. Où sont envoyées les tâches ayant échoué définitivement ?
6. Comment rendre l’exécution en double sûre ?
7. Comment observer la profondeur de la file d’attente ?
8. Le payload de la tâche peut-il être reconstitué ?

Concevez des workers idempotents. Un encaissement, un e-mail ou un import de données peut être livré plus d’une fois après une défaillance. Utilisez une clé d’idempotence métier et enregistrez l’achèvement dans la base de données source de vérité.

Séparez les noms de files d’attente selon la charge et la priorité. Une tâche de traitement multimédia lente ne doit pas bloquer le traitement des réinitialisations de mot de passe ou des webhooks. Évitez de placer des secrets dans les payloads des tâches lorsqu’un ID de référence suffit.

Un déploiement de cache et de file d’attente Redis doit documenter les clés qui sont supprimables et celles qui représentent des tâches métier.

Comment le réseau privé connecte-t-il les services à Redis ?

Activez le réseau du projet :

dockup network enable production --json

Le service Redis devient accessible via son hostname stable <slug>.internal depuis les services du même projet. Effectuez le redeploy de l’application afin que Dockup puisse injecter les variables de connexion internes.

Pour rendre Redis accessible uniquement en privé :

dockup db private production/app-redis --json

Restaurez le listener public lorsque cela est nécessaire :

dockup db private production/app-redis --off --json

Le réseau privé supprime le chemin passant par l’Internet public pour le trafic entre services d’un même projet, mais ne remplace pas l’authentification. Gardez les informations de connexion Redis secrètes et limitez les services qui les reçoivent.

Des projets différents ne peuvent pas accéder au réseau privé des uns et des autres. Cette limite peut être utile lorsque la production et le staging ne doivent pas partager les clés de cache ni les tâches des files d’attente.

Consultez le réseau privé et les domaines internes pour découvrir le modèle complet.

Quel impact les défaillances de Redis doivent-elles avoir sur l’application ?

Classez la charge avant d’écrire le code de récupération.

Charge	Tolérance à la perte	Réponse en cas de panne
Cache de fragments HTML	Élevée	Reconstruire depuis la source
Stockage de sessions	Faible à moyenne	Peut déconnecter les utilisateurs ; concevoir un fallback
Compteurs de rate limiting	Dépend de la politique	Échouer en autorisant ou en refusant explicitement
File d’attente de tâches	Faible	Cesser d’accepter les tâches ou les conserver ailleurs
Distributed lock	Très faible pour les sections critiques	Utiliser du fencing/de l’idempotence
Cache de fonctionnalités	Élevée	Utiliser la valeur par défaut ou la source

Un client Redis ne doit pas réessayer indéfiniment. Des retries prolongés peuvent mobiliser tous les workers de l’application et transformer un incident Redis en panne généralisée. Les workers de file d’attente doivent appliquer un backoff, exposer les tâches en échec et s’arrêter conformément à une politique définie.

Examinez la taille de Redis et les logs d’exécution de l’application consommatrice :

dockup db size production/app-redis --json
dockup logs production/api --json

Une augmentation de la taille peut signaler l’absence d’expiration, une profondeur de file d’attente qui s’emballe, des payloads trop volumineux ou des espaces de noms abandonnés. Ne considérez pas le redémarrage d’une base de données comme la première réponse aux timeouts applicatifs ; vérifiez d’abord la configuration, le réseau et le comportement du client.

Comment les sauvegardes, la migration et la supervision s’intègrent-elles à Redis ?

Dockup expose le workflow de sauvegarde des bases de données managées :

dockup db backups production/app-redis --json
dockup db backup production/app-redis --json

La capacité d’une sauvegarde Redis à répondre à l’objectif de récupération de la charge dépend de la signification des données. Une sauvegarde de cache peut être inutile. Une sauvegarde de file d’attente peut tout de même perdre les tâches acceptées après le point de sauvegarde. Dans la mesure du possible, les tâches critiques pour l’activité doivent disposer d’un enregistrement source récupérable en dehors de la file d’attente.

Déplacez Redis entre les nœuds avec :

dockup db migrate production/app-redis \
  --node <nodeId> \
  --json

Planifiez l’impact de la migration sur les clients et les workers. Vérifiez le bon fonctionnement de la reconnexion, des retries et de l’idempotence avant la mise en production.

Supervisez les métriques au niveau de l’application en plus de la taille de la base de données :

• Taux de hit du cache.
• Latence des cache miss.
• Évictions.
• Profondeur de la file d’attente et âge de la tâche la plus ancienne.
• Nombre de tâches réussies, réessayées et en échec.
• Concurrence des workers.
• Erreurs de connexion Redis.
• Taille des payloads.

Dockup mesure chaque minute la consommation de CPU, de RAM et de disque par rapport au solde du plan. Le plan Pro recommandé coûte 20 $ par mois et inclut 20 $ de crédit d’utilisation, mais ce sont les métriques de charge — et non le nom du plan — qui doivent guider les décisions de capacité.

Quelle checklist Redis de production appliquer en toute sécurité ?

Avant le lancement, vérifiez les points suivants :

1. La cible project/db exacte.
2. Les responsabilités du cache et de la file d’attente sont documentées.
3. L’URL de connexion est stockée comme secret masqué.
4. La politique de réseau privé est définie.
5. Chaque cache dispose d’un TTL ou d’une invalidation explicite.
6. Les workers de file d’attente sont idempotents.
7. Le comportement des retries et des dead letters est défini par le système de file d’attente.
8. Des alertes de taille et de profondeur de file d’attente sont configurées.
9. La valeur et les limites des sauvegardes sont comprises.
10. Les redémarrages et les migrations sont soumis à approbation.

Exemple de séparation du cache et de la file d’attente

Une petite application peut commencer avec une seule base de données Redis lorsque le risque est faible, mais utilisez des préfixes de clés explicites :

cache:user-profile:v2:<user-id>
cache:catalog:v5:<product-id>
queue:email:waiting
queue:email:active
lock:invoice:<invoice-id>

À mesure que la charge augmente, séparez l’état critique des files d’attente de l’état du cache soumis à une éviction agressive. Il s’agit d’une limite opérationnelle, pas simplement d’une préférence de nommage.

Une conception réussie du cache et de la file d’attente Redis rend le comportement de l’application prévisible lorsque Redis est rapide, lent, vide ou indisponible.

Pour les opérations relationnelles utilisant une source de vérité, consultez PostgreSQL managé. Pour découvrir des choix de capacité plus larges, consultez les stratégies de scaling des bases de données. Utilisez la référence de la Dockup CLI pour connaître les commandes actuelles relatives aux bases de données.

Définir l’évolution des clés et des payloads

Les données de cache et de file d’attente peuvent survivre à un processus applicatif donné. Une nouvelle release peut lire des clés écrites par la release précédente pendant un cutover blue-green. Versionnez les espaces de noms des clés et les payloads des tâches afin que les deux versions puissent coexister.

Pour les files d’attente, incluez une version du payload et veillez à ce que les workers puissent traiter au moins les versions qui peuvent encore être en attente. Un rollback de déploiement peut restaurer l’ancien code alors que des tâches au nouveau format restent dans Redis. Sans compatibilité, le rollback de l’application peut augmenter le nombre d’échecs.

Tester délibérément la pression sur les ressources

Dans un environnement hors production, testez les clés absentes, les réponses Redis lentes, les réinitialisations de connexion, l’accumulation de tâches, la livraison en double et une condition de mémoire pleine ou presque pleine. Observez si l’application échoue en autorisant, échoue en refusant, réessaie ou surcharge une autre dépendance.

Un runbook de cache et de file d’attente Redis doit fixer des limites au nombre de retries et à la concurrence. Des boucles de retries illimitées peuvent mobiliser tous les workers et rendre la récupération plus difficile que l’incident initial.

Conserver un chemin de récupération vers la source de vérité

Pour les tâches critiques, stockez suffisamment d’état dans la base de données principale pour pouvoir reconstituer le travail après une perte de Redis. Une file d’attente doit accélérer le traitement, et non devenir l’unique preuve qu’une action client a eu lieu.

Commencer par un déploiement vérifiable

Provisionnez Redis dans un projet hors production, testez le fallback du cache et la livraison en double des tâches, puis explicitez la politique de défaillance avant d’y faire transiter des tâches critiques.

Commencez gratuitement sur app.dockup.ai. Le plan Free coûte 0 $ par mois, inclut 10 $ de crédit de départ et prend en charge un espace de travail, trois bases de données et trois déploiements.

FAQ

Dockup peut-il créer un Redis managé ?

Oui. Utilisez la commande de création de base de données managée avec le type redis, puis connectez l’application à l’aide des informations de connexion retournées et stockées comme secret.

Les données de cache et de file d’attente doivent-elles partager une seule instance Redis ?

C’est possible pour une petite charge présentant peu de risques, mais la séparation est plus sûre lorsque l’éviction du cache et la rétention des files d’attente critiques ont des exigences différentes en matière de disponibilité et de mémoire.

Redis garantit-il qu’une tâche en file d’attente s’exécute exactement une fois ?

Aucune garantie générale d’exécution exactement une fois ne doit être supposée. Les sémantiques de livraison dépendent de la bibliothèque de file d’attente et de la conception des workers ; rendez donc les effets de bord idempotents.

Redis peut-il utiliser le réseau privé de Dockup ?

Oui. Activez le réseau du projet, effectuez le redeploy des services consommateurs pour récupérer les variables internes et, si nécessaire, rendez la base de données Redis accessible uniquement en privé.

Une sauvegarde Redis suffit-elle pour une file d’attente de tâches critique ?

Pas nécessairement. Elle représente un instant donné et peut ne pas inclure les tâches acceptées plus récemment. Conservez des enregistrements sources récupérables et définissez une procédure de récupération des tâches au niveau de l’application.