Redis 8 : nouveautés et décisions de mise à niveau pour les hébergeurs

Bien situer Redis 8 dans son contexte

Redis 8 désigne une génération de plateforme, et non pas automatiquement une version cible adaptée à chaque environnement d’exploitation. Redis 8.0 était la version initiale publiée en mai 2025. Pour une mise à jour de Redis, les hébergeurs doivent toutefois sélectionner la version mineure et la version de correctif à utiliser concrètement, vérifier leur statut de prise en charge ainsi que leur compatibilité avec leur propre modèle de service.

Au 30 septembre 2026, le système de gestion des versions de Redis répertorie Redis 8.10 comme la version la plus récente Version standard de GA de la branche 8. Les versions 8.4, 8.6 et 8.8 figurent également dans la liste GA. La version mineure supérieure ne constitue toutefois pas un objectif absolu : le niveau de patch, les fonctionnalités utilisées, la compatibilité avec le client et la fenêtre de maintenance prévue restent des critères de sélection.

Redis 8.0 est une version standard dont le support, comprenant les correctifs de sécurité et les corrections de bogues critiques, prendra fin le 1er décembre 2026, selon la politique de gestion des versions. Redis 8.2, en revanche, est considéré comme Libération étendue jusqu'au 1er septembre 2030. Pour les offres gérées de type « conservateur », cette période de support clairement définie peut donc mieux correspondre au cycle de vie du produit ; elle ne remplace toutefois pas la vérification d'un niveau de correctifs approprié.

Redis Open Source 8 est la gamme de serveurs qui intègre les fonctionnalités open source abordées dans cet article. Il convient de distinguer cette gamme de Redis Software : une gamme de produits commerciaux destinée à d'autres modèles d'exploitation en cluster et en entreprise. Le fait que Redis Software 8.0.x prenne en charge plusieurs versions de la base de données Redis ne signifie pas pour autant que ses fonctionnalités supplémentaires font partie des caractéristiques d'une installation standard de Redis Open Source.

Valkey n'est pas non plus une variante de Redis 8, mais un fork indépendant, avec son propre développement et ses propres choix en matière de compatibilité et de licence. Quiconque évalue des alternatives devrait donc examiner séparément le comportement du protocole, l'étendue des fonctionnalités, la voie de migration et les conditions d'utilisation. Un changement de version au sein de Redis n'est pas assimilable à un passage à un fork.

Composants intégrés de la pile dans Redis 8

La modification majeure apportée à Redis 8 est la distribution intégrée Composants de la pile Redis existante. Redis Search, JSON, Time Series ainsi que des structures de données probabilistes telles que les filtres Bloom et Cuckoo, Count-Min Sketch, Top-K et t-digest font partie de Redis Open Source 8. Dans la version initiale Redis 8.0.0, Vector Set a également été intégré, mais y est expressément signalé comme étant en préversion.

Pour les fournisseurs, cela simplifie la gestion des produits lorsqu’un service a réellement besoin de données documentaires, d’une fonctionnalité de recherche ou de séries chronologiques. Les composants sont gérés et livrés en version commune avec Redis. Cela évite d’avoir à harmoniser les modules de la pile installés indépendamment avec la version du serveur ; dans le même temps, un module intégré ne peut pas être mis à jour indépendamment de la version de Redis.

Dans la documentation actuelle de Redis, les « Vector Sets » sont décrits comme un type de données à part entière, doté de commandes spécifiques, depuis la version 8.0 de Redis. Toutefois, comme l'indique la mention « Preview » de la version initiale, un fournisseur d'hébergement ne doit pas conclure, sur la seule base de la version Redis 8.0.0, que celle-ci est pleinement prête pour une utilisation en production. Ce sont les notes de mise à jour, l'état des correctifs et les tests fonctionnels de la version cible concrètement choisie qui font foi.

Une offre gérée pour les catalogues de produits peut fournir des documents JSON et des index de recherche au sein d'une même installation de Redis 8. Pour la télémétrie, Time Series peut fournir un modèle de données adapté. Les structures probabilistes s’avèrent utiles lorsque les applications peuvent fonctionner avec des approximations contrôlées, par exemple pour identifier des éléments présumés déjà connus avant de lancer une requête backend plus coûteuse.

Pour un cache d'objets classique, cela n'impose toutefois pas de nouveaux modèles de données. Les applications WordPress, de boutique en ligne ou PHP y utilisent souvent des chaînes de caractères, des hachages et des durées d'expiration. Cette intégration peut faciliter la standardisation de la version Redis déployée, mais ne justifie pas l'utilisation d'index de recherche, de documents JSON ou de données vectorielles en l'absence d'exigences applicatives concrètes et d'une planification des capacités.

C'est donc la limite de service qui est déterminante : un système allégé Serveur de cache nécessite avant tout une gestion prévisible de la mémoire et des accès clairement délimités. Un service de données ou de recherche nécessite en outre un modèle de données, une structure d'index, un comportement de requête et un concept d'exploitation. Redis 8 fournit l'ensemble de ces éléments, mais ne prend pas en charge ce choix architectural.

La gestion commune des versions permet ainsi surtout de réduire la complexité de la gestion des versions. Elle ne remplace toutefois pas la vérification visant à s'assurer que les clients prennent en charge les commandes utilisées ou qu'un déploiement Redis Stack existant utilise des configurations et des index spécifiques. Avant toute migration, ces dépendances doivent être prises en compte dans l'état des lieux technique.

Évaluer les avantages en fonction du cas d'utilisation de Redis

La valeur ajoutée pratique de Redis 8 dépend davantage du cas d'utilisation que du numéro de version. Pour le cache d'objets, le stockage de sessions, les files d'attente, la limitation de débit et le cache d'application en général, les fonctionnalités de base de Redis restent essentielles. Les nouveaux types de données sont ici facultatifs ; l'application n'a pas besoin de les comprendre ni de les utiliser pour fonctionner sous Redis 8.

• Cache classique et sessions : les avantages découlent principalement d'un serveur bien entretenu et d'un fonctionnement contrôlé ; les fonctions de recherche ou vectorielles ne feraient généralement qu'ajouter une complexité supplémentaire inutile.
• Files d'attente et limitation de débit : les structures de données Redis et les opérations atomiques restent essentielles. Les structures probabilistes peuvent compléter certains cas particuliers, mais ne fournissent pas de comptage exact général.
• Recherche de produits et données documentaires : JSON et Redis Search peuvent prendre en charge une approche de service intégrée lorsque le modèle de données, les index et les requêtes sont réellement nécessaires.
• Télémétrie et analyses approximatives : les séries chronologiques, ainsi que les esquisses et les filtres, s'appliquent aux valeurs de mesure temporelles ou aux méthodes d'approximation, à condition que les applications tiennent compte des limites de leurs résultats.

Dans le cas d'un cache d'objets standard, la planification de l'exploitation devrait donc Limites de stockage et hiérarchiser les délais d'expiration. Sans limite fixe, un espace de clés croissant peut nuire à d'autres services sur l'hôte. Le choix de la stratégie d'éviction appropriée dépend du fait que l'instance contienne exclusivement des entrées de cache non essentielles ou également des données pertinentes sur le plan technique ; dans la mesure du possible, ces deux types de données ne devraient pas être mélangés.

Pour tous les cas de figure, la limite du réseau est plus fondamentale qu'une nouvelle commande. Redis recommande de ne pas rendre les instances directement accessibles depuis Internet et de limiter le port Redis aux clients de confiance. Le protocole TLS permet de sécuriser les connexions des clients, la réplication et le bus du cluster ; les listes de contrôle d'accès (ACL) restreignent en outre les commandes et les espaces de clés accessibles.

Une mise à jour de Redis est donc particulièrement intéressante dans le cas de caches purs, notamment dans le cadre d'une modernisation planifiée de la version, de la maintenance et du modèle d'exploitation. Pour les applications de recherche, de télémétrie ou vectorielles, l'éventail des fonctionnalités intégrées peut également s'avérer pertinent. Dans les deux cas, la question reste la même : quelles données, quelle charge et quelles limites de sécurité cette instance unique doit-elle réellement supporter ?

Nouvelles fonctionnalités et besoins en ressources

Redis Open Source 8 regroupe des fonctionnalités qui étaient auparavant généralement fournies par Redis Stack et ses composants : documents JSON, Redis Search, séries chronologiques et structures de données probabilistes. À cela s'ajoutent les Vector Sets, qui figuraient en avant-première dans la version initiale Redis 8.0.0. Pour les offres d'hébergement, cette distribution intégrée réduit le nombre de composants à gérer séparément.

Cependant, ce n’est qu’à partir d’un modèle de service concret que l’on peut en tirer des avantages. JSON et Redis Search conviennent par exemple aux catalogues de produits ou à la recherche de documents, tandis que Time Series est adapté aux valeurs de mesure basées sur le temps. En revanche, un cache d'objets classique ne nécessite souvent ni requêtes sur des documents ni index : pour lui, le quota de stockage, les délais d'expiration et un comportement d'éviction adapté restent des décisions opérationnelles fondamentales.

Dans le cas des filtres Bloom et Cuckoo, de Count-Min Sketch, de Top-K et de t-digest, la limite technique revêt une importance particulière : ils prennent en charge les estimations de probabilité, de fréquence, de rang ou de quantile, mais ne stockent pas nécessairement toutes les informations individuelles avec exactitude. Ils permettent ainsi de soulager les recherches en arrière-plan ou les analyses approfondies ; toutefois, ils ne conviennent pas, sans vérification supplémentaire, pour des valeurs individuelles pertinentes pour la facturation ou devant répondre à des exigences d'audit.

La limitation de débit classique nécessite en revanche une méthode choisie de manière réfléchie, comme un compteur, un « token bucket » ou une « sliding window », avec des structures Redis adaptées et des opérations atomiques. Les structures probabilistes peuvent tout au plus compléter un cas particulier spécialement conçu, basé sur des approximations. Elles ne constituent pas un substitut général à une logique de limitation exacte.

Les ensembles vectoriels répondent à un autre besoin. Redis stocke des représentations vectorielles et recherche des éléments similaires ; il est possible, en option, d'inclure des attributs JSON à des fins de filtrage. Redis ne génère pas les embeddings lui-même. Les applications doivent donc les récupérer à partir d’un modèle ou d’un service externe avant de pouvoir s’en servir pour la recherche sémantique, les recommandations ou la récupération de données.

Dimensionner de manière réaliste les ensembles de vecteurs

A Ensemble de vecteurs est destiné à des requêtes telles que „ produits similaires “, „ passages correspondants dans un document “ ou la recherche sémantique. La recherche en texte intégral classique et la similarité vectorielle constituent ici deux approches différentes : Redis Search permet de traiter des champs textuels et des requêtes, tandis que les ensembles de vecteurs (Vector Sets) déterminent les similitudes entre vecteurs. Un cache Web classique ne tire aucune valeur ajoutée fonctionnelle des vecteurs à eux seuls.

La planification fonctionnelle doit rester liée à la version. Redis 8.0.0 a introduit les Vector Sets en avant-première. La documentation actuelle décrit la structure de données et ses commandes, mais ne confirme pas rétroactivement que la version initiale était pleinement prête pour une utilisation en production. Avant toute mise en production, il convient donc de vérifier les notes de version et le comportement de la version Redis choisie avec les clients requis.

Pour la première planification des capacités, la documentation indique, pour 300 dimensions, un volume théorique de 1 200 octets par vecteur FP32 ou de 300 octets par vecteur Q8. Pour 100 000 vecteurs FP32, cela correspond à environ 120 Mo de données brutes ; pour les vecteurs Q8, à environ 30 Mo. Ce calcul porte exclusivement sur la composante vectorielle et ne constitue en aucun cas une garantie quant aux besoins en mémoire d'une instance en production.

De plus, la structure de recherche basée sur HNSW nécessite de la mémoire pour les connexions du graphe. À cela s’ajoutent les étiquettes et les attributs facultatifs ; de même, la fragmentation, les répliques et les données persistantes peuvent modifier les besoins réels en ressources. Quiconque prévoit un déploiement à haute disponibilité ne doit donc pas se contenter d'assimiler la taille brute à la mémoire vive disponible d'un seul nœud.

Le choix entre FP32 et Q8 relève donc d'une décision liée à la qualité et aux ressources, et non d'une optimisation universelle. Il est judicieux de mettre en place un environnement de test comprenant des vecteurs, des attributs de filtre et des modèles de requêtes représentatifs. Cela permet d’évaluer l’utilisation de la mémoire, les temps de réponse et la qualité des résultats pour le cas concret du client avant de définir les capacités ou les limites par mandant.

Préparer la mise à jour de Redis de manière contrôlée

A Mise à jour de Redis La migration de Redis Open Source 7.x ou de Redis Stack vers Redis 8 doit s'effectuer dans le cadre d'une transition planifiée, et non sous la forme d'un simple changement de version sans accompagnement sur un système de production. Il convient tout d'abord de choisir une version cible précise, ainsi que sa période de support. Ensuite, une instance de test reproduit de la manière la plus fidèle possible le modèle de données, la persistance, les clients et les rôles d'accès pertinents.

Avant l'intervention, l'équipe doit déterminer quels fichiers de persistance et quelles sauvegardes appartiennent effectivement à l'instance, et comment se déroule la restauration. Redis mentionne, pour le processus de mise à niveau, la sauvegarde, un test et des vérifications ultérieures de la version, de l'accès aux données et des connexions client. Une restauration documentée nécessite donc non seulement les anciens paquets, mais aussi un chemin de retour traçable pour les données et la configuration.

Pour un premier état des lieux, il convient de se pencher sur les informations relatives au serveur et à la persistance, ainsi que sur le chemin d'accès aux données configuré. Exécutez les requêtes suivantes à l'aide d'un compte disposant des autorisations nécessaires et conservez les résultats hors des tickets ou journaux accessibles au public s'ils contiennent des détails sur l'infrastructure.

redis-cli INFO server
redis-cli INFO persistence
redis-cli CONFIG GET dir
redis-cli INFO server | grep redis_version

La commande SAVE Elle est mentionnée dans la documentation relative à la mise à niveau pour un instantané, mais il ne s'agit pas d'une commande standard sans conséquence : en tant qu'opération synchrone, elle peut affecter le fonctionnement du système en fonction du volume de données et de la charge. Planifiez les sauvegardes et les fenêtres de maintenance en fonction du modèle de persistance utilisé. Pour des processus de staging et de rollback reproductibles, un workflow soumis à un contrôle de version avec des environnements clairement séparés s'avère utile ; l'article suivant aborde ce sujet : Hébergement web avec support Git.

Vérifier les ACL et la séparation des mandants

Un service Redis géré commence par une délimitation claire du réseau : le port Redis ne doit pas être accessible au public, mais uniquement aux serveurs d'applications ou aux réseaux d'administration de confiance. Le protocole TLS protège les connexions des clients, la réplication et le bus du cluster pendant le transfert. Ces mesures se complètent ; le protocole TLS ne remplace ni un pare-feu restrictif ni un contrôle d'accès rigoureux au niveau du serveur.

Pour plusieurs clients ou applications, Séparation des mandants plus qu'un simple numéro de base de données distinct. Les instances dédiées sont les plus faciles à délimiter. Lorsque plusieurs clients partagent une instance, les listes de contrôle d'accès (ACL) doivent limiter les commandes autorisées et les espaces de clés ; de plus, des limites de mémoire empêchent qu'une charge de travail unique n'épuise la capacité destinée aux autres clients. Les préfixes de clés constituent un élément de cette règle, mais ne constituent pas une barrière de sécurité à part entière.

Lors de la mise à jour de Redis vers la version 8, il convient notamment d'accorder une attention particulière à la vérification des listes de contrôle d'accès (ACL). Les commandes des composants désormais intégrés s'ajoutent aux catégories existantes telles que @read et @write attribué. Une autorisation formulée jusqu’à présent de manière générale peut donc également autoriser, par exemple, des requêtes de recherche ou des accès en écriture JSON. Une ACL syntaxiquement valide ne garantit donc pas automatiquement qu’elle corresponde toujours au minimum des droits requis sur le plan fonctionnel.

D'un point de vue pratique, il est recommandé d'effectuer une comparaison ACL : les règles exportées de l'instance précédente sont comparées aux règles prévues dans Redis 8. Pour chaque rôle client, l’équipe doit vérifier quelles commandes sont réellement nécessaires, quels préfixes de clés restent accessibles et si une nouvelle catégorie héritée inclut des droits indésirables. Ce qui est déterminant, c’est la comparaison des autorisations effectives, et non pas uniquement le texte des lignes de configuration.

Des tests ciblés sont ensuite définis pour chaque rôle : un client de cache Web est par exemple autorisé à lire et à écrire les clés de cache qui lui sont attribuées, mais ne doit pas utiliser de préfixes étrangers ni de commandes d'administration. Des tests spécifiques s'appliquent aux applications de recherche ou JSON. Ces contrôles basés sur les rôles permettent de rendre les modifications traçables, sans imposer un modèle ACL universel aux différentes architectures des clients.

Exploitation, surveillance et dépannage

En production, il est recommandé de surveiller séparément l'utilisation de la mémoire, les évictions, les latences, les connexions client, la persistance et la réplication. Ces valeurs reflètent différents goulots d'étranglement et doivent donc être évaluées en fonction du modèle de service concerné. Une augmentation des évictions n'indique pas automatiquement une erreur de Redis, mais constitue une raison de vérifier la limite de mémoire, les délais d'expiration et le modèle de données.

Les index de recherche et les ensembles de vecteurs ne doivent pas être regroupés avec un cache d'objets classique dans un pool de mesures. Outre l’ensemble des clés, celui-ci comprend les mémoires d’index et de graphes, les attributs ainsi que la charge de requêtes correspondante. Dans le cas des vecteurs, les étiquettes, les connexions, la fragmentation, la réplication et la persistance s’ajoutent aux besoins en données brutes. Dimensionner une instance uniquement sur la base des valeurs vectorielles revient donc à sous-estimer les besoins réels en ressources.

Redis 8 introduit une nouvelle implémentation du threading d'E/S ; le paramètre io-threads ne constitue toutefois pas un levier de performance universel. De même, les améliorations apportées à la réplication ne constituent pas une garantie générale de débit. Les cœurs de processeur, le réseau, la persistance, la composition des requêtes et le comportement des clients déterminent en partie si une modification est bénéfique. C’est pourquoi les variantes de configuration doivent être testées dans un environnement de préproduction proche de la production, avec son propre profil de charge.

Après une mise à niveau, les problèmes non détectés au niveau des clients sont souvent plus révélateurs que les simples indicateurs du serveur. L'équipe doit vérifier les connexions, l'authentification, les commandes utilisées et les réponses d'erreur à l'aide des bibliothèques client réelles. Il est tout aussi important de disposer d'une procédure de restauration bien rodée : une sauvegarde existante ne réduit le risque que si le fonctionnement des données et de l'application est vérifié après la restauration.

Pour la gestion des alertes, il est utile de définir des seuils distincts en fonction de la classe de service. Un cache peut tolérer délibérément les évictions, alors que celles-ci peuvent entraîner une perte de données dans le cas des sessions ou des files d’attente. Les charges de travail liées à la recherche et aux vecteurs nécessitent en outre une surveillance de l’évolution de leur mémoire et des latences de requête. L’article suivant fournit des informations générales sur l’observabilité, la scalabilité et la planification des ressources : Tendances en matière d'hébergement pour 2026.

Pour le dépannage, les modifications apportées au modèle de données, à la version du client, à la limite de mémoire et à la configuration de persistance doivent être mises en corrélation temporelle avec les métriques. Cela permet de déterminer si un pic de latence coïncide, par exemple, avec une nouvelle charge de recherche, une augmentation du nombre de connexions ou une phase de persistance. Cette mise en correspondance est plus fiable que l'hypothèse selon laquelle chaque anomalie serait la conséquence de la mise à jour de Redis.

Restauration dans le cadre d'un contrôle fiscal Une sauvegarde ne suffit pas à elle seule à garantir la capacité de reprise. Le guide de mise à niveau recommande de s'entraîner de manière contrôlée à la sauvegarde et à la mise à niveau, puis de vérifier l'accès aux données et les connexions des clients.

Choisir une licence et un produit

Avec Redis 8, le choix de la licence relève d'une décision relative au produit, et non d'une simple étape dans la procédure d'installation. Redis Open Source peut être utilisé sous licence RSALv2, SSPLv1 ou AGPLv3. Le choix de l'option la mieux adaptée à une instance interne, à l'environnement d'un client ou à un produit Managed Redis proposé au public dépend du mode de déploiement concret et des obligations qui y sont associées.

La licence RSALv2 restreint notamment la commercialisation ou la mise à disposition des fonctionnalités du logiciel sous forme de service géré pour des tiers. Les licences SSPLv1 et AGPLv3 contiennent des exigences de « copyleft » qui peuvent s'avérer pertinentes en cas de fourniture de services ou d'accès au réseau. Cette brève description ne remplace en aucun cas un conseil juridique : avant de fixer les prix, de conclure un contrat ou de lancer un produit, l'architecture concrète doit faire l'objet d'un examen juridique.

La différenciation des produits revêt une importance tout aussi grande. Redis Open Source 8 désigne la gamme de serveurs avec ses structures de données et ses fonctions de requête intégrées. Redis Software est en revanche une gamme de produits commerciaux disposant de sa propre documentation de version et prenant en charge plusieurs versions de la base de données Redis. Il ne faut pas en déduire pour autant que toutes les fonctionnalités de cluster, d’administration ou de haute disponibilité qui y sont décrites font partie d’une installation open source standard.

Valkey ou d'autres forks ne constituent pas non plus des variantes de Redis 8. Quiconque les considère comme des alternatives doit vérifier par lui-même les commandes prises en charge, le modèle d'exploitation, la licence et la procédure de migration. Une interface de protocole similaire ou une origine historique commune ne suffit pas pour en déduire des garanties de fonctionnalité et de compatibilité pour les applications ou les offres gérées.

Une décision viable repose sur cinq questions : quelle version concrète de Redis correspond à la période de support prévue ? La charge de travail nécessite-t-elle réellement des fonctionnalités de recherche, de séries chronologiques ou de vecteurs ? Le modèle d'exploitation est-il couvert en termes d'isolation, de sauvegardes et de surveillance ? Les ACL et les clients ont-ils été vérifiés ? Et la Examen de licence pour le type de service proposé ? Ce n'est que la combinaison de ces éléments qui fait d'une mise à jour Redis une offre d'hébergement fiable.