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 hautement disponibles ou ceux qui doivent prendre en charge des charges importantes et distribuées, tels que le commerce électronique moderne ou les portails Web, il est très 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 cohérence des sessions utilisateur, quel que soit le nœud sur lequel se trouve l'utilisateur au cours de sa navigation.

Imaginons par exemple une architecture avec trois serveurs PHP-FPM derrière un équilibreur de charge. Chaque fois qu’un utilisateur fait une demande, il peut se retrouver sur un nœud différent. Si les sessions sont gérées localement (sur fichier), l'utilisateur perdra le contexte dès que le trafic sera redirigé vers un autre nœud. C'est là que le besoin entre en jeu centraliser la gestion des sessions.

L’une des solutions les plus courantes consiste à utiliser un Base de données clé/valeur NoSQL pour stocker des sessions ou d'autres données transitoires à haute fréquence. Les technologies les plus utilisées dans ce domaine sont Memcached e Redis.

Redis vs Memcached : pourquoi Redis est le choix moderne

Redis (REmote DIctionary Server) est né en 2009 d'une idée de Salvatore Sanfilippo (aka antirez), un développeur italien, qui l'a créé pour résoudre les problèmes de performances de son projet de startup. Initialement conçu comme un simple magasin de clés-valeurs en mémoire, il a rapidement évolué vers un puissant serveur de structure de données, avec un support natif pour les listes, les ensembles, les hachages, les ensembles triés, etc. Redis a été adopté par des milliers d'entreprises dans le monde entier pour la mise en cache, les sessions, la messagerie et les analyses en temps réel. En 2015, le projet a été donné à la communauté sous la licence BSD, et en 2020, Sanfilippo s'est retiré du projet. Aujourd'hui, Redis est maintenu par Redis Inc., qui développe à la fois des versions open source et d'entreprise, 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 natif.

Bien que Memcached soit toujours utilisé, Redis a largement dépassé Memcached 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 stocker des sessions partagées dans des environnements PHP, Node.js, Python, Ruby et d'autres technologies Web.

Cependant, lorsque vous entrez dans les détails de la mise en œuvre de Redis dans un contexte de cluster, des limitations non triviales émergent, surtout 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 dans un Maître d'esclave, Ie:

• 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 enregistrer la session sur un nœud Redis, nous ne pouvons pas nous attendre à ce qu'une telle session soit immédiatement disponible sur tous les autres nœuds. La réplication prend du temps et si un réseau ou un nœud tombe en panne, les écritures peuvent être perdues ou incohérentes.

De plus, dans une architecture où trois serveurs PHP doivent pouvoir écrire ou lire des sessions à tout moment, vous êtes souvent obligé de configurer plusieurs adresses Redis, ou d’utiliser un mécanisme de « nouvelle tentative » et de secours 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 sessions d'authentification, paniers, paiements ou pages personnalisées: toute perte ou incohérence peut entraîner de graves dommages UX 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 être capable de écrire la session utilisateur sur le nœud Redis le plus proche ou directement sur localhost, sans se soucier de savoir quel nœud est le « maître » ou si la session sera lue correctement par les autres serveurs. Le système backend devrait prendre soin de lui-même synchroniser les modifications en temps réel sur tous les autres nœuds du cluster, dans un tout transparent, efficace et tolérant aux pannes.

Cette architecture — connue sous le nom de Maître / Réplique du maître avec Active Sync o multi-écrivain actif-actif — représente le modèle idéal pour les environnements évolutifs et distribués : chaque nœud est simultanément un lecteur et un écrivain, toutes les modifications étant propagées via une synchronisation active aux autres homologues du cluster. Il en résulte de nombreux avantages : pas de point de défaillance unique, latences minimales, haute disponibilité e Simplification de la logique d'application, éliminant ainsi le besoin de gérer des mécanismes complexes de secours ou de nouvelle tentative.

Malheureusement, cette technologie Active Sync Il n'est pas pris en charge dans la version open source de Redis, qui est plutôt basé sur une architecture maître/esclave avec réplication asynchrone. La seule option Redis qui permet une véritable configuration Master/Master avec Active Sync est la Redis Entreprise, distribué commercialement par Redis Inc., qui inclut des fonctionnalités avancées telles que l'actif-actif avec CRDT (Conflict-free Replicated Data Types), mais dont l'utilisation est restreinte par licences coûteuses et des infrastructures contrôlées, souvent dans des fournisseurs de cloud spécifiques ou 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 limite technique et opérationnelle importante, en particulier dans l'architecture moderne où L'agilité et la résilience distribuée avec synchronisation active sont désormais des exigences clés.

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

C'est précisément à partir de ce besoin concret, c'est-à-dire de la possibilité de écrivez sur n'importe quel nœud et assurez une réplication immédiate et cohérente sur l'ensemble du cluster — une équipe d'ingénieurs de Snapchat il a décidé de s'attaquer au problème à la racine. Snapchat, en fait, n'est pas seulement une application sociale populaire, mais un véritable géant infrastructurel qui traite des milliards d'événements et d'interactions d'utilisateurs chaque jour, souvent en temps réel et avec des exigences très strictes en termes de latence et de disponibilité.

Qu'est-ce que Snapchat ?

Snapchat est une application de messagerie instantanée très populaire auprès des jeunes, qui se distingue par la possibilité d'envoyer photos et vidéos éphémères, c'est-à-dire un contenu qui s'autodétruit après avoir été visionné. Elle est également connue pour son Lentilles AR, des histoires quotidiennes et des fonctionnalités de chat rapide. Sur le plan technique, Snapchat est basé sur Infrastructures distribuées hautes performances, capable de s'adapter de manière dynamique pour répondre aux pics de trafic mondiaux — pensez aux week-ends, aux événements en direct ou aux fuseaux horaires simples qui déclenchent des flux continus d'utilisateurs connectés.

Dans un tel scénario, s'appuyer sur Redis dans sa version open source a rapidement représenté une limitation : la nécessité de disposer d'un réplication asynchrone maître/esclave Il était trop faible 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, les coûts de la version entreprise de Redis n’étaient pas compatibles avec l’approche ouverte et contrôlée que Snapchat souhaitait pour son infrastructure de base.

C'est ainsi que l'équipe a décidé de Forking Redis à partir du code de la version 5, en maintenant une compatibilité totale avec l'interface et les API Redis existantes, mais en introduisant une série de 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 la réplication multi-maître active de manière native et sans licences payantes.

Le résultat est Base de données de clés, une base de données open source qui conserve toute la puissance et la simplicité de Redis, mais étend radicalement ses capacités, le rendant adapté aux contextes mission critique, faible latence et hautement disponible. Aujourd'hui, KeyDB est adopté par de nombreuses entreprises à travers le monde qui recherchent une alternative véritablement évolutive et gratuite à Redis Enterprise, tout en restant dans l'écosystème Redis compatible.

Une brève histoire de KeyDB

Base de données de clés Il a été initialement publié en 2019 en tant que Fourchette Redis 5, dans le but de surmonter certaines des limitations structurelles de la version open source de Redis, tout en conservant sa compatibilité et sa facilité d'utilisation. Le projet est né au sein de Inc. logiciel enfichable (la société mère de Snapchat) et est aujourd'hui activement maintenu par une équipe dédiée des développeurs, avec 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 les plus fiables à Redis Enterprise, permettant conserver tous les avantages de l'écosystème Redismais avec un une plus grande flexibilité architecturale, des performances supérieures et surtout un modèle open source totalement exempt de frais de licence.

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

La force la plus significative de Base de données de clés est la possibilité de configurer un Cluster multi-écrivains, En ce qui chaque nœud est à la fois maître et réplique des autres, permettant à n'importe quel nœud d'accepter les écritures de manière indépendante. Contrairement au modèle Redis traditionnel, ici les modifications ne sont pas centralisées sur un seul nœud, mais sont propagé automatiquement en temps réel à tous les pairs du cluster, en maintenant la cohérence des données sans avoir besoin d'une logique d'application 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 un cycle de réplication actif, où chaque nœud est mis à jour en temps réel par les autres. Il est nativement pris 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 laissées par la version communautaire de Redis.

KeyDB est compatible avec tous les clients Redis et ne nécessite aucune modification de vos applications. Pour ceux qui travaillent dans le monde de PHP, Magento, WordPress ou Prestashop et gèrent des infrastructures évolutives, KeyDB permet performances supérieures, plus grande tolérance aux pannes et simplification architecturale.

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 est 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 traditionnellement le cas avec Redis. Cela élimine complètement le besoin de spécifier tous les nœuds Redis séparés par des virgules dans votre configuration PHP, simplifiant considérablement votre 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 orienté vers distribution, résilience et performance, la gestion des sessions (et des données volatiles en général) ne peut plus être basée sur des solutions conçues pour des contextes monolithiques ou centralisés. Redis a marqué un tournant dans la façon de penser les bases de données clé-valeur, mais sa version open source, bien que robuste et populaire, montre des limites claires dans les scénarios distribués complexes et critiques.

Base de données de clés est né précisément pour combler cette lacune, en offrant une plateforme open source, performant, compatible et véritablement orienté vers l'évolutivité moderne. Avec la possibilité d'écrire sur n'importe quel nœud, la réplication synchrone et bidirectionnelle, la prise en charge multithread et la compatibilité totale avec les clients et commandes Redis, KeyDB vous permet de créer des infrastructures simple à gérer, robuste et incroyablement rapide.

Pour ceux qui gèrent des environnements PHP, du commerce électronique hautement disponible, des microservices ou des systèmes à haute concurrence, KeyDB représente un choix stratégique permettant simplifier l'architecture, augmenter la disponibilité des services et réduire le risque de perte de session ou d'incohérence.

Sans licences à payer, 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 les plus fiables pour ceux qui veulent le meilleur de Redis, mais sans compromis.