Redis 8.8 : tableaux natifs et INCREX

Redis 8.8 est passé en disponibilité générale cette semaine, et deux des nouveautés comptent pour quiconque l’utilise derrière une API. La vedette est un type de données tableau natif, contribué par le créateur de Redis, Salvatore Sanfilippo. Pendant des années, les équipes ont simulé des collections ordonnées et indexables avec des listes ou des ensembles triés. Il existe désormais une structure dédiée pour cela, permettant d’effectuer des agrégations et des opérations positionnelles côté serveur plutôt que de rapatrier les données vers le client pour les traiter en boucle. L’autre nouveauté est INCREX, une commande de compteur fenêtré qui combine INCR, la vérification des limites et l’expiration en une seule opération atomique. En clair, « 100 requêtes par minute » se résume désormais à une seule commande plutôt qu’à un script Lua fait maison ou à une chorégraphie complexe de plusieurs commandes.

Il y a davantage sous le capot : des notifications de sous-clés pour les champs de hachage, une commande XNACK qui permet aux consommateurs de flux de renvoyer les messages bloqués, et un cycle d’améliorations des performances incluant le portage de certains chemins critiques vers Rust et l’activation de l’optimisation au moment de la liaison pour les builds x86_64. Sans oublier les correctifs de sécurité et de bugs habituels. Mais le type tableau et INCREX sont les changements que la plupart des équipes remarqueront en premier.

Voici notre avis. INCREX est la fonctionnalité à examiner de près. Nous avons passé en revue de nombreuses bases de code où la limitation de débit était un script Lua écrit à la hâte que personne n’avait touché depuis. Ces scripts fonctionnent bien… jusqu’au moment où ils ne fonctionnent plus : un décalage d’un dans le calcul de la fenêtre, un TTL qui n’est jamais défini au premier appel, une condition de course sous charge qui laisse passer un pic. Dans notre travail PHP et Docker de création d’API pour des clients entreprises, la limitation de débit est l’une de ces choses qui semble triviale et qui ne l’est pas vraiment. Une seule commande atomique qui gère le compteur, la limite et l’expiration élimine toute une catégorie de ces bugs.

Cela dit, ne supprimez pas du code fonctionnel dès le premier jour. Une commande native n’est utile que si vous passez réellement à la version 8.8 et lui faites confiance en production. Si vous êtes déjà sur Redis 8.x et que votre limitation de débit est en Lua personnalisé, prototypez INCREX en staging, soumettez-le à des formes de trafic réelles et comparez le comportement aux limites de fenêtre avant de basculer. Si vous êtes sur une version plus ancienne de Redis, considérez cela comme une raison de planifier la mise à jour, et non de la faire un vendredi après-midi.

Le type tableau est plus utile pour les charges de travail à lecture intensive et de type analytique. Quand nous développons des applications cloud-natives sur AWS, le principal tueur de latence est rarement Redis lui-même. Ce sont les allers-retours réseau. Chaque « récupérer la liste, filtrer côté client, en renvoyer une partie » représente un saut réseau que vous payez à chaque requête. Les opérations positionnelles côté serveur éliminent cela. Nous avons vu le même schéma nuire aux équipes mobiles : dans nos projets iOS et Android natifs, en particulier les applications offline-first dans les secteurs de la santé et de l’IoT, un backend bavard vide la batterie et rend la synchronisation lente sur les mauvais réseaux. Faire davantage en un seul appel côté serveur est un vrai gain quand le client est dans un train qui traverse un tunnel.

Une remarque du côté sécurité. Lors de nos missions de pentest, et quand nous configurons Cloudflare pour la protection DDoS, nous traitons la limitation de débit au niveau applicatif et la protection à la périphérie comme deux couches distinctes, et non des substituts l’une de l’autre. INCREX rend la couche applicative plus propre. Il ne remplace pas la limitation de débit à la périphérie devant votre origine. Si votre seul mécanisme de throttle réside dans Redis, un attaquant capable d’épuiser votre pool de connexions n’atteindra jamais le code qui l’appelle. Gardez les deux.

Que devriez-vous donc faire concrètement cette semaine ? Trouvez votre code de limitation de débit. Qu’il s’agisse d’un script Lua, d’un package middleware ou de quelques lignes copiées d’un article de blog il y a des années, relisez-le et confirmez qu’il fait ce que vous pensez sous charge concurrente. Que vous adoptiez INCREX ou non, cet audit vaut plus que la mise à jour elle-même. Une sortie de base de données est une bonne occasion de se pencher sur les choses qu’on a arrêté de vérifier.

Nous traitons la version 8.8 comme toute version mineure de base de données pour un client : lire le changelog, noter les correctifs de sécurité, tester les fonctionnalités qui nous intéressent en staging, et planifier la mise à jour délibérément. Le type tableau natif et INCREX sont réellement utiles. La rigueur dans leur adoption est ce qui maintient la production ennuyeuse, ce qui nous convient parfaitement.

Si une limitation de débit artisanale ou une couche Redis trop bavarde vous parle, parlons-en.