Partage de sessions (ou d'autres valeurs) dans des bases de données clés/valeurs avec un cluster KeyDB

Évolutivité horizontale et sessions partagées : un problème (non) trivial

Dans les environnements à haute disponibilité ou devant supporter des charges importantes et distribuées, comme les sites de commerce électronique modernes ou les portails web, il est courant de faire évoluer l'infrastructure horizontalement, en répartissant la charge sur plusieurs serveurs d'applications. Cela pose un défi crucial : maintenir la continuité des sessions utilisateur , quel que soit le nœud sur lequel l'utilisateur navigue.

Prenons l'exemple d'une architecture avec trois serveurs PHP-FPM derrière un répartiteur de charge. Chaque requête utilisateur peut aboutir sur un nœud différent. Si les sessions sont gérées localement (dans des fichiers), l'utilisateur perd son contexte dès que le trafic est redirigé vers un autre nœud. C'est là que la nécessité de centraliser la gestion des sessions prend tout son sens.

L'une des solutions les plus courantes consiste à utiliser une base de données NoSQL clé/valeur pour stocker les sessions ou d'autres données transitoires et fréquemment consultées. Les technologies les plus couramment utilisées à cette fin sont Memcached et Redis.

Redis vs Memcached : pourquoi Redis est le choix moderne

Redis (REmote DIctionary Server) a vu le jour en 2009 grâce à une idée de Salvatore Sanfilippo (alias antirez), un développeur italien. Il l'a créé pour résoudre les problèmes de performance de son projet de startup. Conçu initialement comme un simple magasin de clés-valeurs en mémoire, il est rapidement devenu un serveur de structures de données puissant, grâce à sa prise en charge native des listes, des ensembles, des tables de hachage, des ensembles triés, et bien plus encore. Redis a été adopté par des milliers d'entreprises dans le monde entier pour la mise en cache, la gestion des sessions, la messagerie et l'analyse en temps réel. En 2015, le projet a été offert à la communauté sous licence BSD, et en 2020, Salvatore Sanfilippo a quitté son poste de chef de projet. Aujourd'hui, Redis est maintenu par Redis Inc. , qui développe des versions open source et des versions pour entreprises, avec des fonctionnalités avancées telles que la réplication active-active et la prise en charge multirégionale. Redis est devenu l'un des outils les plus utilisés dans l'écosystème DevOps et cloud-native.

Bien que Memcached soit encore utilisé, Redis l'a largement surpassé dans de nombreux contextes réels grâce à ses fonctionnalités avancées :

• Prise en charge des structures de données complexes (listes, ensembles, hachages, etc.) Contrairement à Memcached, qui fonctionne exclusivement avec des chaînes clé/valeur, Redis permet des structures de données beaucoup plus polyvalentes. Parmi ceux-ci, nous trouvons des listes (utiles pour gérer les files d'attente FIFO et LIFO), des ensembles (ensembles non ordonnés sans doublons), des ensembles triés (avec des scores associés, idéaux pour les classements), des hachages (parfaits pour représenter des objets ou des tableaux associatifs), ainsi que des types avancés tels que les bitmaps, les hyperloglogs et les flux. Cette variété permet de modéliser des scénarios d'application complexes directement dans la base de données, sans avoir besoin de transformations intermédiaires dans le code.
• Persistance facultative sur le disque Redis peut fonctionner soit comme une base de données volatile, entièrement en RAM, soit avec des mécanismes de persistance pour garantir la durabilité des données. Les deux principaux modes sont RDB (qui prend des instantanés à des intervalles configurables) et AOF (qui enregistre toutes les opérations effectuées). Cela vous permet de trouver un équilibre entre performances et fiabilité, offrant la possibilité de restaurer les données même après un redémarrage du service. Memcached, en revanche, est complètement non persistant : lorsque le serveur est arrêté, tout ce qui était stocké est perdu.
• Opérations atomiques autochtones Redis garantit que chaque opération est atomique, c'est-à-dire exécutée de manière isolée et complètement sans possibilité d'interférence d'autres clients. Ceci est particulièrement important pour les opérations simultanées sur des données partagées. Par exemple, l’incrémentation d’un compteur ou la modification d’un hachage s’effectue toujours en toute sécurité. De plus, Redis prend en charge les transactions via MULTI/EXEC et l'utilisation de scripts Lua qui vous permettent d'exécuter plusieurs opérations en masse au sein du serveur, sans risque de conditions de concurrence et avec de meilleures performances que la logique côté client.
• Prise en charge de la réplication et du clustering Redis offre un certain nombre de fonctionnalités avancées pour l'évolutivité et la haute disponibilité. Vous pouvez configurer des répliques en lecture seule (réplication maître/esclave) pour répartir la charge ou adopter Redis Cluster pour obtenir un véritable partitionnement horizontal des données sur plusieurs nœuds. A cela s'ajoute Redis Sentinel, le composant dédié au monitoring, au failover automatique et à la gestion dynamique des masters. Memcached, en revanche, ne prend pas en charge nativement la réplication ou le clustering : chaque nœud est isolé et la cohérence doit être entièrement gérée par la couche applicative.

Pour ces raisons, Redis est considéré comme la norme de facto pour le stockage des sessions partagées dans PHP, Node.js, Python, Ruby et d'autres technologies web.

Cependant, lorsqu'on examine en détail la mise en œuvre de Redis dans un contexte de cluster, certaines limitations non triviales apparaissent , notamment dans la version communautaire (gratuite).

Les limites de la version communautaire de Redis : le problème de la réplication asynchrone et des clusters maître/esclave

La version open source de Redis prend en charge le clustering, mais en mode maître/esclave , c'est-à-dire :

• Chaque nœud accepte les écritures uniquement pour un sous-ensemble des clés Dans un cluster Redis, les clés sont divisées en 16.384 XNUMX « emplacements de hachage », répartis entre les différents nœuds. Cela signifie que chaque nœud n'est responsable que d'une partie de l'ensemble de données total et n'acceptera que les écritures pour les clés qui tombent dans ses emplacements. Par conséquent, si une application tente d'écrire une clé sur un nœud qui n'est pas responsable de cette clé, Redis renverra une erreur de type MOVED et le client devra réessayer sur l'autre nœud. Cela ajoute de la complexité côté application ou nécessite des clients compatibles avec les clusters.
• La réplication se produit de manière asynchrone. Les données écrites sur un nœud maître sont répliquées sur ses esclaves, mais le processus de réplication n'est pas synchrone : il n'y a aucune garantie que les données nouvellement écrites seront déjà disponibles sur les esclaves lorsqu'un basculement est déclenché. Cela introduit le risque de perte temporaire de données, en particulier dans les scénarios à fréquence d'écriture élevée. La réplication désynchronisée peut être un problème pour les applications qui nécessitent une forte cohérence, telles que les systèmes de paiement, les sessions de connexion ou les données utilisateur volatiles mais critiques.
• Il n'y a pas de réplication transparente Maître/Maître (multi-écrivain) Le cluster Redis open source ne permet pas à plusieurs nœuds d'accepter des écritures pour les mêmes clés en même temps. Il n’est pas possible d’avoir une configuration dans laquelle chaque nœud est activé en écriture et toutes les modifications sont propagées en temps réel aux autres. Cela signifie que vous ne pouvez pas écrire la session sur un nœud et vous attendre à ce qu'elle soit automatiquement répliquée sur tous les autres, comme cela se produirait dans un cluster maître/maître. Cette limitation devient un goulot d'étranglement dans les architectures distribuées où chaque nœud d'application possède son propre Redis local ou proche et où vous souhaitez éviter les écritures inter-nœuds complexes et lentes.

Cela signifie que si nous voulons sauvegarder une session sur un nœud Redis, nous ne pouvons pas nous attendre à ce que cette session soit immédiatement disponible sur tous les autres nœuds . La réplication prend du temps, et en cas de panne du réseau ou d'un nœud, l'écriture peut être perdue ou incohérente.

De plus, dans une architecture où trois serveurs PHP doivent pouvoir écrire ou lire des sessions à tout moment, vous êtes souvent contraint de configurer plusieurs adresses Redis , ou d'utiliser un mécanisme de « nouvelle tentative » et de repli complexe et inefficace.

Exemple : Redis avec PHP-FPM dans un e-commerce à haute disponibilité

Disons que nous avons trois serveurs d’applications avec PHP-FPM et Magento. Chaque nœud possède une configuration de session Redis similaire à celle-ci :

session.save_handler = redis
session.save_path = "tcp://redis1:6379,tcp://redis2:6379,tcp://redis3:6379"

Cette approche présente quelques problèmes évidents :

• Latences variables Chaque connexion TCP/IP introduit une latence réseau, qui peut varier en fonction de la distance physique, de la charge des nœuds et de la qualité du réseau. Dans un environnement distribué, tous les serveurs Redis ne seront pas équidistants des différents serveurs d’applications. Cela signifie que la vitesse à laquelle une session est écrite ou lue peut varier considérablement, ce qui entraîne des temps de réponse incohérents et une expérience utilisateur moins fluide, en particulier sous charge.
• Problèmes en cas de panne Si l'un des nœuds Redis répertoriés est lent à répondre ou complètement indisponible, le processus PHP-FPM devra attendre Délai d'expiration TCP avant de tenter de se connecter au nœud suivant. Ce comportement introduit des retards importants dans le cycle de réponse de l'application. De plus, PHP ne gère pas toujours de manière optimale la faillibilité du backend Redis, en particulier si un mécanisme de nouvelle tentative ou de basculement efficace n'est pas configuré.
• Écrits incohérents Une session utilisateur pourrait être écrite sur redis1, mais si la réponse est vers redis2 o redis3 n'a pas encore eu lieu — ou a échoué —, les tentatives de lecture ultérieures par d'autres nœuds PHP connectés à ces Redis ne trouveront pas la session mise à jour. Cela peut conduire à perte de session, déconnexion inattendue ou comportement erratique de l'application. En pratique, l’application finit par se comporter comme si la session n’avait jamais été créée ou avait expiré, avec toutes les conséquences que cela implique en termes d’UX et de continuité de service.

Ces scénarios deviennent encore plus critiques lors de la gestion des sessions d'authentification, des paniers, des processus de paiement ou des pages personnalisées : toute perte ou incohérence peut entraîner de graves dommages à l'expérience utilisateur et, dans le secteur du commerce électronique, même une perte financière directe.

La solution idéale ? Un cluster Master/Master transparent avec Active Sync

Dans un monde idéal, chaque serveur d'application PHP devrait pouvoir écrire la session utilisateur sur le nœud Redis le plus proche ou directement sur localhost , sans se soucier du nœud « maître » ni de la lecture correcte de la session par les autres serveurs. Le système backend devrait gérer automatiquement la synchronisation des modifications en temps réel sur tous les nœuds du cluster , de manière totalement transparente, efficace et tolérante aux pannes.

Cette architecture, connue sous le nom de réplication maître/maître avec synchronisation active ou architecture multi-rédacteur actif-actif , est le modèle idéal pour les environnements distribués et évolutifs : chaque nœud est simultanément lecteur et rédacteur, et toutes les modifications sont propagées aux autres nœuds du cluster via une synchronisation active. Elle offre de nombreux avantages : absence de point de défaillance unique , latence minimale , haute disponibilité et simplification de la logique applicative , éliminant ainsi le besoin de gérer des mécanismes complexes de repli ou de nouvelle tentative.

Malheureusement, la technologie Active Sync n'est pas prise en charge par la version open source de Redis , qui repose sur une architecture maître/esclave avec réplication asynchrone. Seule la version commerciale de Redis, distribuée par Redis Inc., permet une véritable configuration maître/maître avec Active Sync. Elle inclut des fonctionnalités avancées telles que le mode actif-actif avec les types de données répliqués sans conflit (CRDT), mais son utilisation est soumise à des licences onéreuses et à une infrastructure contrôlée, souvent chez des fournisseurs de cloud spécifiques ou dans des environnements gérés.

Pour ceux qui souhaitent rester dans l'écosystème open source ou éviter les coûts récurrents des versions d'entreprise, cela représente une limitation technique et opérationnelle importante , notamment dans les architectures modernes où l'agilité et la résilience distribuée avec synchronisation active sont désormais des exigences fondamentales.

Le projet KeyDB est né : de Snapchat au monde de l'Open Source

Partant de ce besoin très précis – la possibilité d' écrire sur n'importe quel nœud et de garantir une réplication immédiate et cohérente sur l'ensemble du cluster – une équipe d' ingénieurs de Snapchat a décidé de s'attaquer au problème à la source. Snapchat n'est pas qu'une simple application de médias sociaux populaire ; c'est un véritable géant de l'infrastructure qui traite chaque jour des milliards d'événements et d'interactions utilisateur , souvent en temps réel et avec des exigences de latence et de disponibilité extrêmement strictes.

Qu'est-ce que Snapchat ?

Snapchat est une application de messagerie instantanée très populaire chez les jeunes, notamment grâce à sa capacité à envoyer des photos et des vidéos éphémères (qui disparaissent après visionnage). Elle est également connue pour ses filtres de réalité augmentée , ses stories quotidiennes et sa messagerie instantanée. Techniquement, Snapchat repose sur une infrastructure distribuée haute performance , capable de s'adapter dynamiquement aux pics de trafic mondiaux (week-ends, événements en direct ou simples changements de fuseaux horaires, par exemple), qui génèrent un flux constant d'utilisateurs connectés.

Dans ce contexte, le recours à la version open source de Redis s'est rapidement révélé problématique : le besoin de réplication maître/esclave asynchrone était insuffisant pour gérer le contenu éphémère et les sessions en temps réel sans risque d'incohérence ou de perte de données. De plus, le coût de la version entreprise de Redis était incompatible avec l'approche ouverte et contrôlée que Snapchat souhaitait adopter pour son infrastructure principale.

L'équipe a donc décidé de créer une branche de Redis à partir du code source de la version 5, en conservant une compatibilité totale avec l'interface et les API existantes, tout en introduisant une série d' innovations architecturales fondamentales . L'objectif était clair : créer une base de données clé-valeur plus moderne et plus performante, capable de prendre en charge nativement la réplication multi-maître active sans nécessiter de licence payante.

C’est ainsi qu’est née KeyDB , une base de données open source qui conserve toute la puissance et la simplicité de Redis, tout en étendant considérablement ses capacités, la rendant idéale pour les environnements critiques , à faible latence et à haute disponibilité. Aujourd’hui, KeyDB est adoptée par de nombreuses entreprises à travers le monde qui recherchent une alternative véritablement évolutive et gratuite à Redis Enterprise, tout en restant compatibles avec l’écosystème Redis.

Une brève histoire de KeyDB

KeyDB a été initialement lancé en 2019 comme une version dérivée de Redis 5 , visant à pallier certaines limitations structurelles de la version open source de Redis tout en conservant sa compatibilité et sa facilité d'utilisation. Ce projet, né au sein de Snap Inc. (la société mère de Snapchat), est désormais activement maintenu par une équipe de développeurs dédiée, qui propose des mises à jour régulières, des corrections de bugs et de nouvelles fonctionnalités.

Les principales innovations introduites par KeyDB par rapport à Redis incluent :

• Réplication multi-maître native Contrairement à Redis OSS, qui ne prend en charge que les configurations maître/esclave et la réplication unidirectionnelle, KeyDB permet à plusieurs nœuds de accepter les écritures simultanément, propageant les modifications à d’autres pairs en temps réel. Cela vous permet de créer clusters actifs-actifs véritablement distribué, sans nécessiter de coordinateurs externes ou de solutions complexes de gestion de la cohérence.
• Threading multithread (Redis est monothread pour les opérations de base) Redis, de par sa conception, effectue toutes les opérations principales sur un seul thread, ce qui constitue une limitation sur les machines modernes dotées de processeurs multicœurs. KeyDB brise cette barrière en implémentant un moteur de gestion des requêtes multithread, avec des avantages significatifs en termes de débit, de parallélisme et d'utilisation optimale des ressources matérielles. Dans les scénarios à volume élevé, les différences de performances deviennent tangibles.
• Prise en charge complète des commandes Redis existantes L’un des points forts de KeyDB est sa compatibilité totale avec la syntaxe et les commandes Redis, permettant de remplacer de manière transparente le backend Redis dans n'importe quelle application existante, sans avoir à modifier aucun code ni aucune configuration client. Les commandes avancées, les transactions et les scripts Lua sont également pris en charge.
• Compatibilité immédiate avec les clients Redis Tous les clients Redis — pour PHP, Python, Node.js, Go, Java, etc. — fonctionne nativement avec KeyDB, grâce au maintien du protocole réseau RESP. Cela signifie que les développeurs et DevOps peuvent intégrer KeyDB dans leurs infrastructures existantes facilement et immédiatement, sans aucune modification du code.
• Des performances supérieures dans des scénarios réels Grâce au multithreading, à la réplication synchrone et aux optimisations internes, KeyDB a démontré dans de nombreux benchmarks que être nettement plus rapide que Redis dans des scénarios réels, en particulier sous des charges simultanées ou avec plusieurs clients actifs. En particulier, le temps de réponse moyen aux demandes (latency) est plus stable et contenu même dans des conditions stressantes.
• Open source (licence BSD 3-Clause) KeyDB est publié sous une licence Licence permissive BSD à 3 clauses, qui permet également une utilisation commerciale sans restrictions. Cela rend le projet particulièrement attractif pour les entreprises, les startups et les fournisseurs de cloud qui souhaitent créer des solutions performantes et distribuées. sans avoir à faire face aux coûts récurrents des licences d'entreprise.

Grâce à ces fonctionnalités, KeyDB est rapidement devenu l'une des alternatives les plus sérieuses et fiables à Redis Enterprise , permettant de conserver tous les avantages de l'écosystème Redis , mais avec une plus grande flexibilité architecturale , des performances supérieures et surtout un modèle open source totalement exempt de coûts de licence.

KeyDB dans une perspective Maître/Maître et Active Sync : un nouveau paradigme

Le principal atout de KeyDB réside dans sa capacité à configurer un cluster multi-rédacteurs , où chaque nœud est à la fois maître et réplique des autres , permettant ainsi à chacun d'accepter des écritures indépendamment. Contrairement au modèle Redis traditionnel, les modifications ne sont pas centralisées sur un seul nœud, mais propagées automatiquement et en temps réel à tous les nœuds du cluster, garantissant ainsi la cohérence des données sans nécessiter de logique applicative complexe.

Comment ça marche?

• Chaque nœud KeyDB est capable d'accepter des écritures de manière autonome Il n’y a plus de « point central » pour l’écriture : chaque nœud du cluster peut recevoir et gérer les écritures en parallèle, permettant aux applications d’interagir toujours avec l’instance la plus proche, réduisant considérablement la latence et améliorant les performances.
• Les modifications sont immédiatement répliquées sur tous les autres nœuds. Lorsqu'un nœud reçoit une écriture (par exemple une mise à jour de session), il est diffusé en temps réel aux autres nœuds du cluster, garantissant que tout le monde maintient le même état de manière synchrone. Ce comportement élimine le besoin d’interrogation, de propagation asynchrone ou de mécanismes de secours d’application.
• Le protocole de réplication est synchrone et bidirectionnel, évitant les divergences La réplication active entre les nœuds est bidirectionnelle, ce qui signifie que chaque nœud non seulement envoie mais reçoit également des modifications. De plus, le mécanisme est conçu pour être synchrone, réduisant considérablement le risque d’incohérence des données. Tous les conflits sont traités automatiquement selon des règles déterministes, et il n’existe aucune fenêtre temporelle dans laquelle les données peuvent diverger.
• Il est possible de connecter plusieurs nœuds même dans des environnements géographiquement distribués KeyDB vous permet de créer des clusters qui s'étendent sur différents centres de données ou différentes régions cloud, en maintenant la cohérence des données même sur de longues distances. Cette fonctionnalité est particulièrement utile pour la mise en œuvre stratégies de reprise après sinistre, équilibrage de charge géographique ou haute disponibilité à l'échelle mondiale, tout en maintenant des temps de propagation acceptables.

Avantages concrets des sessions PHP

Lors de l'utilisation de KeyDB pour la gestion des sessions dans des environnements PHP (par exemple avec des piles LAMP ou LEMP distribuées), les avantages deviennent immédiatement apparents :

• Écriture unique : chaque serveur d'application écrit sur le nœud local Au lieu de devoir contacter un nœud Redis distant ou de distribuer manuellement les écritures sur plusieurs points de terminaison, chaque serveur d'applications peut écrire sur votre instance locale de KeyDB, obtenant ainsi des temps de réponse extrêmement rapides et réduisant la latence au minimum.
• Réplication automatique : KeyDB propage la session à d’autres nœuds Une fois les données de session enregistrées sur un nœud, La propagation au reste du cluster est automatique et immédiate. Cela signifie que même si la prochaine demande de l'utilisateur arrive sur un autre serveur d'applications, la session sera déjà disponible, sans qu'une synchronisation externe soit nécessaire.
• Basculement transparent : si un nœud tombe en panne, les autres sont déjà synchronisés En cas de défaillance d'un nœud KeyDB, l'application ne perd pas la session de l'utilisateur : les autres nœuds du cluster sont déjà aligné et prêt à répondre aux demandes. Cela garantit une grande disponibilité même en cas d'accident ou de maintenance imprévue.
• Aucune perte de session : cohérence et disponibilité garanties Grâce à la nature synchrone et multi-maître du cluster, Il n’y a pas de fenêtre d’incohérence entre les nœuds. Le risque qu'une session soit écrite sur un nœud et ne soit pas propagée à temps aux autres (comme cela se produit avec Redis classique) est complètement éliminé, ce qui fait de KeyDB une solution idéale pour les contextes hautement fiables tels que le commerce électronique, les portails avec authentification ou les applications en temps réel.

Exemple de configuration de cluster maître/maître

Imaginons trois nœuds KeyDB : keydb1, keydb2, keydb3.

Configuration activée keydb1.conf:

replicaof keydb2 6379
active-replica yes

Configuration activée keydb2.conf:

replicaof keydb3 6379
active-replica yes

Configuration activée keydb3.conf:

replicaof keydb1 6379
active-replica yes

Cette configuration crée une boucle de réplication active , où chaque nœud est mis à jour en temps réel par les autres. Elle est nativement prise en charge et stable dans KeyDB.

Pourquoi KeyDB est le bon choix aujourd'hui

Pour les architectures distribuées, évolutives et hautement fiables, KeyDB représente une solution moderne, robuste et open source qui comble les lacunes de la version communautaire de Redis.

KeyDB est compatible avec tous les clients Redis et ne nécessite aucune modification de l'application. Pour les développeurs travaillant avec PHP, Magento, WordPress ou PrestaShop et gérant des infrastructures évolutives, KeyDB offre des performances supérieures, une meilleure tolérance aux pannes et une architecture simplifiée.

Intégration PHP : qu'est-ce qui change ?

Côté PHP, absolument rien ne change : le code de l'application reste exactement le même, sans qu'il soit nécessaire de procéder à des modifications ou des adaptations. La seule différence sera dans la configuration du gestionnaire de session PHP-FPM, où vous n'aurez qu'à pointer vers un seul point de terminaison KeyDB, exactement comme vous le feriez avec Redis.

La véritable innovation réside dans le fait que, grâce à la réplication multi-maître de KeyDB, il n'est plus nécessaire de configurer plusieurs listes d'hôtes comme c'était le cas traditionnellement avec Redis . Cela élimine complètement la nécessité de spécifier tous les nœuds Redis séparés par des virgules dans la configuration PHP, simplifiant considérablement l'infrastructure et réduisant la complexité opérationnelle.

session.save_handler = redis
session.save_path = "tcp://keydb1:6379"

Ou encore plus simplement, vous pouvez pointer directement vers une instance sur localhost :

session.save_handler = redis
session.save_path = "tcp://localhost:6379"

Avec cette configuration minimaliste, chaque nœud PHP-FPM communique exclusivement avec sa propre KeyDB locale, qui se charge de répliquer automatiquement toutes les modifications en temps réel sur les autres nœuds du cluster. La couche applicative reste complètement isolée et ignore la complexité sous-jacente de la réplication distribuée, tout en bénéficiant de tous les avantages d'un système hautement disponible. Cette approche est incroyablement plus simple que la configuration multi-hôtes Redis traditionnelle :

# Configurazione tradizionale Redis (non più necessaria con KeyDB)
session.save_handler = redis
session.save_path = "tcp://redis1:6379,tcp://redis2:6379,tcp://redis3:6379"

Avec KeyDB, tout devient simple, élégant et efficace, en conservant une transparence totale pour l'application PHP.

Conclusion : KeyDB, la réponse moderne aux défis d'évolutivité

Dans un paysage technologique de plus en plus axé sur la distribution, la résilience et la performance , la gestion des sessions (et des données volatiles en général) ne peut plus s'appuyer sur des solutions conçues pour des environnements monolithiques ou centralisés. Redis a marqué un tournant dans la conception des bases de données clé-valeur, mais sa version open source, bien que robuste et populaire, présente des limitations évidentes dans les scénarios distribués complexes et critiques.

KeyDB a été créé pour combler ce manque, en offrant une plateforme open source, performante et compatible, véritablement orientée vers une évolutivité moderne . Grâce à la possibilité d'écrire sur n'importe quel nœud, à la réplication synchrone et bidirectionnelle, à la prise en charge du multithreading et à une compatibilité totale avec les clients et commandes Redis, KeyDB vous permet de construire des infrastructures simples à gérer, robustes et incroyablement rapides.

Pour ceux qui gèrent des environnements PHP, des plateformes e-commerce à haute disponibilité, des microservices ou des systèmes à forte concurrence, KeyDB représente un choix stratégique qui permet de simplifier l'architecture, d'accroître la disponibilité du service et de réduire le risque de perte ou d'incohérence de session.

Sans frais de licence, sans dépendance vis-à-vis d'un fournisseur et avec un contrôle total de l'infrastructure, KeyDB est aujourd'hui l'une des alternatives les plus concrètes et fiables pour ceux qui veulent le meilleur de Redis, sans compromis.