En me basant sur les notes de version, je suppose que oui.Voici une petite information à partir de là :
Malgré la réputation bien méritée de Redis en matière de hautes performances, son architecture monothread a été controversée parmi les ingénieurs qui se demandaient si Redis pouvait être encore plus rapide. Redis 6 sonne dans une nouvelle ère :bien qu'il conserve une interface d'accès aux données monothread, les E/S sont désormais multithreads.
En déléguant le temps passé à lire et à écrire sur les sockets d'E/S à d'autres threads, le processus Redis peut consacrer plus de cycles à la manipulation, au stockage et à la récupération des données, ce qui améliore les performances globales. Cette amélioration conserve les caractéristiques transactionnelles des versions précédentes, vous n'avez donc pas à repenser vos applications pour profiter des performances accrues. De même, la commande DEL monothread de Redis peut désormais être configurée pour se comporter comme la commande UNLINK multithread disponible depuis la version 4 de Redis.
Les performances d'une variable locale sont presque toujours imbattables. Enfin, même une base de données aussi performante que Redis sera beaucoup plus lente que d'accéder à quelque chose à partir de la pile ou du tas. Redis 6 ajoute une nouvelle technique permettant aux bibliothèques clientes sophistiquées d'implémenter une couche de mise en cache côté client pour stocker un sous-ensemble de données dans votre propre processus. Cette mise en œuvre est suffisamment intelligente pour gérer plusieurs mises à jour des mêmes données et garder vos données aussi synchronisées que possible, tout en conservant les avantages de Redis avec la vitesse des variables locales.
Vous pouvez également le vérifier/le comparer avec le harnais redis-benchmark ou memtier pour votre profil d'instance/charge de travail.
