Condivisione delle sessioni (o altri valori) in database Key / Value con un Cluster KeyDB

Scalabilità orizzontale e sessioni condivise: un problema (non) banale

In ambienti ad alta disponibilità o che devono supportare carichi importanti e distribuiti, come i moderni eCommerce o portali web, è molto comune scalare l’infrastruttura orizzontalmente, distribuendo il carico su più application server. Questo implica una sfida cruciale: mantenere le sessioni utente coerenti, indipendentemente dal nodo su cui l’utente si ritrova durante la sua navigazione.

Immaginiamo, per esempio, un’architettura con tre server PHP-FPM dietro un bilanciatore di carico. Ogni volta che un utente fa una richiesta, potrebbe finire su un nodo diverso. Se le sessioni sono gestite localmente (su file), l’utente perderà il contesto appena il traffico sarà dirottato su un altro nodo. Ecco quindi che entra in gioco la necessità di centralizzare la gestione delle sessioni.

Una delle soluzioni più comuni è quella di usare un database Key / Value NoSQL per memorizzare sessioni o altri dati transitori e ad alta frequenza di accesso. Le tecnologie più utilizzate in questo ambito sono Memcached e Redis.

Redis vs Memcached: perché Redis è la scelta moderna

Redis (REmote DIctionary Server) è nato nel 2009 da un’idea di Salvatore Sanfilippo (alias antirez), sviluppatore italiano, che lo ha creato per risolvere problemi di performance nel suo progetto di startup. Inizialmente pensato come un semplice key-value store in memoria, si è rapidamente evoluto in un potente data structure server, grazie al supporto nativo per liste, set, hash, sorted set e altro ancora. Redis è stato adottato da migliaia di aziende in tutto il mondo per caching, sessioni, messaggistica e real-time analytics. Nel 2015 il progetto è stato donato alla comunità sotto licenza BSD, e nel 2020 Sanfilippo ha lasciato la guida del progetto. Oggi Redis è mantenuto da Redis Inc., che sviluppa sia la versione open source che quella enterprise, con funzionalità avanzate come la replica attiva-attiva e il supporto multi-region. Redis è diventato uno degli strumenti più utilizzati nell’ecosistema DevOps e cloud-native.

Sebbene Memcached sia ancora utilizzato, Redis ha ampiamente superato Memcached in molti contesti reali grazie alle sue funzionalità avanzate:

• Supporto a strutture dati complesse (liste, set, hash, ecc.) A differenza di Memcached, che lavora esclusivamente con stringhe in formato chiave/valore, Redis permette di utilizzare strutture dati molto più versatili. Tra queste troviamo liste (utili per gestire code FIFO e LIFO), set (insiemi non ordinati senza duplicati), sorted set (con punteggio associato, ideali per classifiche e ranking), hash (perfetti per rappresentare oggetti o array associativi), oltre a tipologie avanzate come bitmap, hyperloglog e stream. Questa varietà consente di modellare scenari applicativi complessi direttamente nel database, senza bisogno di trasformazioni intermedie nel codice.
• Persistenza opzionale su disco Redis può funzionare sia come database volatile, interamente in RAM, sia con meccanismi di persistenza per garantire la durabilità dei dati. Le due modalità principali sono RDB (che esegue snapshot a intervalli configurabili) e AOF (che registra tutte le operazioni svolte). Questo consente di trovare un equilibrio tra performance e affidabilità, offrendo la possibilità di ripristinare i dati anche dopo un riavvio del servizio. Memcached, invece, è completamente privo di persistenza: allo spegnimento del server, tutto ciò che era memorizzato viene perso.
• Operazioni atomiche native Redis garantisce che ogni operazione sia atomica, cioè eseguita in maniera isolata e completa senza possibilità di interferenze da parte di altri client. Questo è particolarmente importante per operazioni concorrenti su dati condivisi. Ad esempio, incrementare un contatore o modificare un hash avviene sempre in modo sicuro. Inoltre, Redis supporta le transazioni tramite MULTI/EXEC e l’uso di script Lua che permettono di eseguire più operazioni in blocco all’interno del server, senza rischi di race condition e con migliori performance rispetto alla logica lato client.
• Supporto a replica e clustering Redis offre una serie di funzionalità avanzate per la scalabilità e l’alta disponibilità. Si possono configurare repliche di sola lettura (replica master/slave) per distribuire il carico, o adottare Redis Cluster per ottenere una vera suddivisione orizzontale dei dati (sharding) tra più nodi. A ciò si aggiunge Redis Sentinel, il componente dedicato al monitoraggio, failover automatico e gestione dinamica dei master. Memcached, al contrario, non supporta nativamente né la replica né il clustering: ogni nodo è isolato e la coerenza deve essere gestita completamente dal livello applicativo.

Per questi motivi, Redis è considerato lo standard de facto per la memorizzazione di sessioni condivise in ambienti PHP, Node.js, Python, Ruby e altre tecnologie web.

Tuttavia, quando si entra nel dettaglio dell’implementazione di Redis in un contesto cluster, emergono dei limiti non banali, soprattutto nella versione community (gratuita).

Il limite della versione Community di Redis: il problema della replica asincrona e dei cluster Master / Slave

La versione open source di Redis supporta il clustering, ma in modalità master/slave, ovvero:

• Ogni nodo accetta scritture solo per un sottoinsieme delle chiavi In un Redis Cluster, le chiavi vengono suddivise in 16.384 “hash slots”, distribuiti tra i vari nodi. Questo significa che ogni nodo è responsabile solo di una porzione del dataset totale e accetterà scritture solo per le chiavi che ricadono nei suoi slot. Di conseguenza, se un’applicazione tenta di scrivere una chiave in un nodo che non è responsabile di quella chiave, Redis restituirà un errore di tipo MOVED e il client dovrà riprovare sull’altro nodo. Questo aggiunge complessità lato applicazione o richiede client compatibili con il cluster.
• La replica avviene in modo asincrono I dati scritti su un nodo master vengono replicati sui relativi slave, ma il processo di replica non è sincrono: non c’è alcuna garanzia che un dato appena scritto sia già disponibile sugli slave nel momento in cui un failover viene attivato. Questo introduce il rischio di perdita temporanea di dati, specialmente in scenari con alta frequenza di scrittura. La mancanza di sincronia nella replica può rappresentare un problema per applicazioni che richiedono consistenza forte, come sistemi di pagamento, sessioni di login o dati utente volatili ma critici.
• Non esiste una replica Master / Master (multi-writer) trasparente Il cluster Redis open source non permette a più nodi di accettare scritture per le stesse chiavi contemporaneamente. Non è possibile avere una configurazione in cui ogni nodo sia attivo per scrittura e tutte le modifiche vengano propagate in tempo reale agli altri. Questo significa che non si può scrivere la sessione su un nodo qualsiasi e aspettarsi che essa venga replicata automaticamente su tutti gli altri, come accadrebbe in un cluster master/master. Questo limite diventa un collo di bottiglia nelle architetture distribuite dove ogni nodo applicativo ha il proprio Redis locale o vicino e si vuole evitare scritture cross-node complesse e lente.

Questo significa che, se vogliamo salvare la sessione su un nodo Redis, non possiamo pretendere che tale sessione sia immediatamente disponibile su tutti gli altri nodi. La replicazione richiede tempo e, in caso di fault di rete o di un nodo, la scrittura può essere persa o incoerente.

Inoltre, in un’architettura in cui tre server PHP devono poter scrivere o leggere le sessioni in qualsiasi momento, spesso si è costretti a configurare più indirizzi Redis, oppure a utilizzare un meccanismo di “retry” e di fallback complesso e inefficiente.

Esempio: Redis con PHP-FPM in un eCommerce ad alta disponibilità

Supponiamo di avere tre application server con PHP-FPM e Magento. Ogni nodo ha una configurazione di sessione Redis simile a questa:

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

Questo approccio ha dei problemi evidenti:

• Latenze variabili Ogni connessione TCP/IP introduce una latenza di rete, che può variare in base alla distanza fisica, al carico del nodo e alla qualità della rete. In un ambiente distribuito, non tutti i server Redis saranno equidistanti rispetto ai vari application server. Ne deriva che la velocità con cui una sessione viene scritta o letta può variare sensibilmente, causando tempi di risposta irregolari e un’esperienza utente meno fluida, soprattutto sotto carico.
• Problemi in caso di fault Se uno dei nodi Redis indicati nella lista è lento nel rispondere o completamente non disponibile, il processo PHP-FPM dovrà attendere il timeout TCP prima di tentare la connessione con il nodo successivo. Questo comportamento introduce ritardi significativi nel ciclo di risposta dell’applicazione. Inoltre, PHP non sempre gestisce in modo ottimale la fallibilità del backend Redis, soprattutto se non viene configurato un meccanismo di retry o failover efficace.
• Scritture incoerenti Una sessione utente potrebbe essere scritta su redis1, ma se la replica verso redis2 o redis3 non è ancora avvenuta — oppure è fallita —, i successivi tentativi di lettura da parte di altri nodi PHP connessi a questi Redis non troveranno la sessione aggiornata. Questo può portare a perdita di sessione, logout inaspettati o comportamenti erratici dell’applicazione. In pratica, l’applicazione finisce per comportarsi come se la sessione non fosse mai stata creata o fosse scaduta, con tutte le conseguenze del caso in termini di UX e continuità del servizio.

Questi scenari diventano ancora più critici quando si gestiscono sessioni di autenticazione, carrelli, checkout o pagine personalizzate: qualunque perdita o incoerenza può tradursi in un grave danno UX e, in ambito eCommerce, anche in una perdita economica diretta.

La soluzione ideale? Un cluster Master / Master trasparente con Active Sync

In un mondo ideale, ogni application server PHP dovrebbe poter scrivere la sessione utente sul nodo Redis più vicino o direttamente in localhost, senza preoccuparsi di quale nodo sia il “master” o se la sessione verrà letta correttamente dagli altri server. Il sistema di backend dovrebbe occuparsi in autonomia di sincronizzare in tempo reale le modifiche su tutti gli altri nodi del cluster, in modo completamente trasparente, efficiente e fault tolerant.

Questa architettura — nota come replica Master / Master con Active Sync o multi-writer active-active — rappresenta il modello ideale per ambienti scalabili e distribuiti: ogni nodo è simultaneamente lettore e scrittore, con tutte le modifiche propagate tramite sincronizzazione attiva agli altri peer del cluster. Ne derivano numerosi vantaggi: nessun punto singolo di fallimento, latenze minime, alta disponibilità e semplificazione della logica applicativa, eliminando la necessità di gestire complessi meccanismi di fallback o retry.

Sfortunatamente, questa tecnologia di Active Sync non è supportata nella versione open source di Redis, che si basa invece su un’architettura master/slave con replica asincrona. L’unica opzione Redis che consente una vera configurazione Master / Master con Active Sync è la Redis Enterprise, distribuita commercialmente da Redis Inc., che include funzionalità avanzate come active-active con CRDT (Conflict-free Replicated Data Types), ma il cui utilizzo è vincolato a licenze costose e a infrastrutture controllate, spesso in cloud provider specifici o in ambienti gestiti.

Per chi desidera restare nell’ecosistema open source, o evitare i costi ricorrenti delle versioni enterprise, questo rappresenta un limite tecnico e operativo importante, specialmente in architetture moderne dove l’agilità e la resilienza distribuita con sincronizzazione attiva sono ormai requisiti fondamentali.

Nasce il progetto KeyDB: da Snapchat al mondo open source

Proprio a partire da questa esigenza concreta — ovvero la possibilità di scrivere su qualsiasi nodo e garantire una replica immediata e coerente su tutto il cluster — un team di ingegneri di Snapchat ha deciso di affrontare il problema alla radice. Snapchat, infatti, non è solo un’applicazione social popolare, ma un vero e proprio colosso infrastrutturale che elabora miliardi di eventi e interazioni utente ogni giorno, spesso in tempo reale e con requisiti molto stringenti in termini di latenza e disponibilità.

Cos’è Snapchat?

Snapchat è un’app di messaggistica istantanea molto diffusa tra i giovani, che si distingue per la possibilità di inviare foto e video effimeri, cioè contenuti che si autodistruggono dopo essere stati visualizzati. È anche nota per le sue lenti AR, storie quotidiane e funzionalità di chat rapida. A livello tecnico, Snapchat si fonda su infrastrutture distribuite altamente performanti, in grado di scalare dinamicamente per rispondere a picchi di traffico globali — pensiamo ai weekend, agli eventi live o al semplice fuso orario che innesca flussi continui di utenti connessi.

In uno scenario del genere, affidarsi a Redis nella sua versione open source ha rappresentato ben presto un limite: la necessità di avere una replica asincrona master/slave era troppo debole per gestire contenuti effimeri e sessioni in tempo reale, senza il rischio di inconsistenza o perdita di dati. I costi della versione enterprise di Redis, inoltre, non erano compatibili con l’approccio open e controllato che Snapchat desiderava per la propria infrastruttura core.

È così che il team ha deciso di forkare Redis a partire dal codice della versione 5, mantenendo piena compatibilità con l’interfaccia e le API Redis già esistenti, ma introducendo una serie di innovazioni architetturali fondamentali. L’obiettivo era chiaro: creare un database key-value più moderno, più performante e soprattutto capace di supportare la replica multi-master attiva nativamente e senza licenze a pagamento.

Nasce così KeyDB, un database open source che conserva tutta la potenza e la semplicità di Redis, ma ne estende in modo radicale le capacità, rendendolo adatto a contesti mission-critical, a bassa latenza e a elevata disponibilità. Oggi KeyDB è adottato da numerose aziende in tutto il mondo che cercano un’alternativa realmente scalabile e gratuita a Redis Enterprise, pur restando all’interno dell’ecosistema Redis compatibile.

Breve storia di KeyDB

KeyDB è stato inizialmente rilasciato nel 2019 come un fork di Redis 5, con l’obiettivo di superare alcuni dei limiti strutturali della versione open source di Redis, pur mantenendone la compatibilità e la semplicità d’uso. Il progetto è nato all’interno di Snap Inc. (l’azienda madre di Snapchat) ed è oggi mantenuto attivamente da un team dedicato di sviluppatori, con aggiornamenti regolari, bugfix e nuove funzionalità.

Le principali innovazioni introdotte da KeyDB rispetto a Redis includono:

• Replica multi-master nativa A differenza di Redis OSS, che supporta solo configurazioni master/slave e replica unidirezionale, KeyDB permette a più nodi di accettare scritture simultaneamente, propagando in tempo reale le modifiche verso gli altri peer. Questo consente di realizzare cluster attivi-attivi realmente distribuiti, senza necessità di coordinatori esterni o soluzioni complesse per la gestione della consistenza.
• Threading multithread (Redis è single-threaded per le operazioni core) Redis, per progettazione, esegue tutte le operazioni principali su un singolo thread, il che rappresenta un limite su macchine moderne con CPU multicore. KeyDB rompe questa barriera, implementando un motore multithread per l’handling delle richieste, con significativi vantaggi in termini di throughput, parallelismo e utilizzo ottimale delle risorse hardware. In scenari ad alto volume di richieste, le differenze prestazionali diventano tangibili.
• Supporto completo ai comandi Redis esistenti Uno dei punti di forza di KeyDB è la sua totale compatibilità con la sintassi e i comandi Redis, rendendo possibile la sostituzione trasparente del backend Redis in una qualsiasi applicazione esistente, senza necessità di modificare codice o configurazioni client. Anche i comandi avanzati, le transazioni e gli script Lua sono supportati.
• Compatibilità drop-in con i client Redis Tutti i client Redis — per PHP, Python, Node.js, Go, Java, ecc. — funzionano nativamente con KeyDB, grazie al mantenimento del protocollo di rete RESP. Questo significa che sviluppatori e DevOps possono integrare KeyDB nelle loro infrastrutture esistenti in modo semplice e immediato, senza cambiamenti lato codice.
• Prestazioni superiori in scenari real-world Grazie al multithreading, alla replica sincrona e a ottimizzazioni interne, KeyDB ha dimostrato in numerosi benchmark di essere significativamente più veloce di Redis in scenari reali, soprattutto sotto carichi concorrenti o in presenza di molteplici client attivi. In particolare, il tempo medio di risposta alle richieste (latency) risulta più stabile e contenuto anche in condizioni di stress.
• Open source (licenza BSD 3-Clause) KeyDB è rilasciato sotto una licenza permissiva BSD 3-Clause, che consente l’uso anche commerciale senza vincoli. Questo rende il progetto particolarmente appetibile per aziende, startup e provider cloud che vogliono costruire soluzioni performanti e distribuite senza dover affrontare i costi ricorrenti delle licenze enterprise.

Grazie a queste caratteristiche, KeyDB è diventato rapidamente una delle alternative più serie e affidabili a Redis Enterprise, permettendo di mantenere tutti i vantaggi dell’ecosistema Redis, ma con una maggiore flessibilità architetturale, prestazioni superiori e soprattutto un modello open source completamente libero da costi di licenza.

KeyDB in ottica Master / Master e Active Sync : un nuovo paradigma

Il punto di forza più rilevante di KeyDB è la possibilità di configurare un cluster multi-writer, in cui ogni nodo è contemporaneamente master e replica degli altri, consentendo a qualsiasi nodo di accettare scritture in modo indipendente. A differenza del modello Redis tradizionale, qui le modifiche non vengono centralizzate su un solo nodo, ma sono propagate automaticamente e in tempo reale a tutti i peer del cluster, mantenendo la coerenza dei dati senza necessità di logiche applicative complesse.

Come funziona?

• Ogni nodo KeyDB è in grado di accettare scritture in autonomia Non esiste più un “punto centrale” per la scrittura: ogni nodo del cluster può ricevere e gestire scritture in parallelo, permettendo alle applicazioni di interagire sempre con l’istanza più vicina, riducendo drasticamente la latenza e migliorando le performance.
• Le modifiche vengono replicate immediatamente su tutti gli altri nodi Quando un nodo riceve una scrittura (es. un aggiornamento di sessione), questa viene trasmessa in tempo reale agli altri nodi del cluster, assicurando che tutti mantengano lo stesso stato in modo sincrono. Questo comportamento elimina la necessità di meccanismi di polling, propagazione asincrona o fallback applicativi.
• Il protocollo di replica è sincrono e bidirezionale, evitando divergenze La replica attiva tra i nodi è bidirezionale, il che significa che ogni nodo non solo invia ma anche riceve modifiche. Inoltre, il meccanismo è progettato per essere sincrono, riducendo sensibilmente il rischio di inconsistenza dei dati. Eventuali conflitti sono gestiti automaticamente secondo regole deterministiche, e non esistono finestre temporali in cui i dati possano divergere.
• È possibile collegare più nodi anche in ambienti geografici distribuiti KeyDB permette di realizzare cluster che si estendono su data center diversi o regioni cloud differenti, mantenendo la coerenza dei dati anche su lunghe distanze. Questa caratteristica è particolarmente utile per implementare strategie di disaster recovery, bilanciamento geografico del carico o alta disponibilità su scala globale, il tutto mantenendo tempi di propagazione accettabili.

Vantaggi concreti per le sessioni PHP

Quando si utilizza KeyDB per la gestione delle sessioni in ambienti PHP (ad esempio con stack LAMP o LEMP distribuiti), i benefici diventano immediatamente evidenti:

• Scrittura singola: ogni application server scrive sul nodo locale Invece di dover contattare un nodo Redis remoto o distribuire le scritture in modo manuale tra più endpoint, ogni application server può scrivere sulla propria istanza locale di KeyDB, ottenendo così tempi di risposta rapidissimi e riducendo la latenza al minimo.
• Replica automatica: KeyDB propaga la sessione agli altri nodi Una volta che il dato di sessione è stato salvato su un nodo, la propagazione verso il resto del cluster è automatica e immediata. Questo significa che, anche se la successiva richiesta dell’utente dovesse arrivare a un altro application server, la sessione sarà già disponibile, senza necessità di sincronizzazioni esterne.
• Failover trasparente: se un nodo fallisce, gli altri sono già sincronizzati In caso di guasto di un nodo KeyDB, l’applicazione non perde la sessione dell’utente: gli altri nodi del cluster sono già allineati e pronti a rispondere alle richieste. Questo garantisce un’elevata disponibilità anche in caso di incidenti o manutenzioni improvvise.
• Zero perdita di sessione: coerenza e disponibilità sono garantite Grazie alla natura sincrona e multi-master del cluster, non esiste alcuna finestra di inconsistenza tra i nodi. Il rischio che una sessione venga scritta su un nodo e non propagata in tempo agli altri (come avviene con Redis classico) viene completamente eliminato, rendendo KeyDB una soluzione ideale per contesti ad alta affidabilità come eCommerce, portali con autenticazione, o applicazioni real-time.

Esempio di setup per cluster Master / Master

Immaginiamo tre nodi KeyDB: keydb1, keydb2, keydb3.

Configurazione su keydb1.conf:

replicaof keydb2 6379
active-replica yes

Configurazione su keydb2.conf:

replicaof keydb3 6379
active-replica yes

Configurazione su keydb3.conf:

replicaof keydb1 6379
active-replica yes

Questo setup crea un ciclo di replica attiva, in cui ogni nodo è aggiornato in tempo reale dagli altri. È supportato nativamente e stabile in KeyDB.

Perché KeyDB è oggi la scelta giusta

Per architetture distribuite, scalabili e ad alta affidabilità, KeyDB rappresenta una soluzione moderna, solida e open source che colma le lacune lasciate dalla versione community di Redis.

KeyDB è compatibile con tutti i client Redis e non richiede modifiche alle applicazioni. Per chi lavora nel mondo PHP, Magento, WordPress o Prestashop e gestisce infrastrutture scalabili, KeyDB permette performance superiori, maggiore tolleranza ai guasti e semplificazione architetturale.

Integrazione con PHP: cosa cambia?

Lato PHP non cambia assolutamente nulla: il codice applicativo rimane esattamente identico, senza necessità di modifiche o adattamenti. L’unica differenza sarà nella configurazione dell’handler di sessione PHP-FPM, dove basterà puntare su un singolo endpoint KeyDB, esattamente come si farebbe con Redis.

La vera innovazione è che, grazie alla replica multi-master di KeyDB, non serve più configurare liste di host multipli come si faceva tradizionalmente con Redis. Si elimina completamente la necessità di specificare tutti i nodi Redis separati da virgole nella configurazione di PHP, semplificando drasticamente l’infrastruttura e riducendo la complessità operativa.

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

O ancora più semplicemente, si può puntare direttamente a un’istanza in localhost:

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

Con questa configurazione minimalista, ogni nodo PHP-FPM comunica esclusivamente con il proprio KeyDB locale, che si occupa autonomamente di replicare in tempo reale tutte le modifiche verso gli altri nodi del cluster. Il livello applicativo rimane completamente isolato e ignaro della complessità sottostante della replica distribuita, ottenendo comunque tutti i benefici di un sistema altamente disponibile. Questo approccio è incredibilmente più semplice rispetto alla configurazione multi-host tradizionale di Redis:

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

Con KeyDB, tutto diventa semplice, elegante ed efficace, mantenendo totale trasparenza per l’applicazione PHP.

Conclusione: KeyDB, la risposta moderna alle sfide della scalabilità

In un panorama tecnologico sempre più orientato alla distribuzione, alla resilienza e alle performance, la gestione delle sessioni (e in generale dei dati volatili) non può più basarsi su soluzioni pensate per contesti monolitici o centralizzati. Redis ha segnato una svolta nel modo di concepire i database key-value, ma la sua versione open source, per quanto solida e popolare, mostra dei limiti evidenti in scenari distribuiti complessi e mission-critical.

KeyDB nasce proprio per colmare questo vuoto, offrendo una piattaforma open source, performante, compatibile e realmente orientata alla scalabilità moderna. Con la possibilità di scrivere su qualsiasi nodo, una replica sincrona e bidirezionale, supporto multithread e compatibilità completa con client e comandi Redis, KeyDB permette di costruire infrastrutture semplici da gestire, robuste, e incredibilmente veloci.

Per chi gestisce ambienti PHP, eCommerce in alta disponibilità, microservizi, o sistemi ad alta concorrenza, KeyDB rappresenta una scelta strategica che consente di semplificare l’architettura, aumentare la disponibilità dei servizi e ridurre i rischi di perdita o inconsistenza delle sessioni.

Senza licenze da pagare, senza vendor lock-in e con il pieno controllo dell’infrastruttura, KeyDB è oggi una delle alternative più concrete e affidabili per chi vuole il meglio di Redis, ma senza compromessi.