Redis 8: novità e decisioni relative all'aggiornamento per i fornitori di servizi di hosting

Comprendere appieno Redis 8

Redis 8 indica una generazione di piattaforma, ma non implica automaticamente una versione di destinazione adeguata per ogni ambiente operativo. Redis 8.0 è stata la versione iniziale rilasciata nel maggio 2025. Per un aggiornamento di Redis, tuttavia, i fornitori di hosting devono selezionare la versione minore e la versione patch da utilizzare concretamente, verificarne lo stato di supporto e la compatibilità con il proprio modello di servizio.

Al 30 settembre 2026, il sistema di gestione delle versioni di Redis indica Redis 8.10 come la versione più recente elencata Versione standard GA della linea 8. Sono elencate come GA anche le versioni 8.4, 8.6 e 8.8. La versione minore più recente non costituisce tuttavia un obiettivo generale: lo stato delle patch, le funzionalità utilizzate, la compatibilità con il client e la finestra di manutenzione prevista rimangono fattori determinanti nella scelta.

Redis 8.0 è una versione standard per la quale, secondo la politica di gestione delle versioni, il supporto per le correzioni di sicurezza e dei bug critici terminerà il 1° dicembre 2026. Redis 8.2, invece, è considerato Rilascio esteso fino al 1° settembre 2030. Per le offerte di gestione conservativa, questa finestra di supporto fissata può quindi adattarsi meglio al ciclo di vita del prodotto; tuttavia, non sostituisce la verifica di uno stato di patch adeguato.

Redis Open Source 8 è la linea di server che include le funzionalità open source trattate in questo articolo. Da questa è distinta Redis Software: una linea di prodotti commerciali destinata ad altri modelli operativi di cluster e aziendali. Il fatto che Redis Software 8.0.x supporti diverse versioni del database Redis non rende le sue funzionalità aggiuntive caratteristiche di una normale installazione open source di Redis.

Anche Valkey non è una variante di Redis 8, bensì un fork indipendente con uno sviluppo autonomo e decisioni autonome in materia di compatibilità e licenza. Chi sta valutando delle alternative dovrebbe quindi esaminare separatamente il comportamento del protocollo, le funzionalità, il percorso di migrazione e le condizioni d’uso. Un cambio di versione all’interno di Redis non è equiparabile al passaggio a un fork.

Componenti dello stack integrati in Redis 8

La novità più significativa di Redis 8 è la distribuzione integrata Componenti dello stack Redis esistenti. Redis Search, JSON, Time Series e strutture di dati probabilistiche come i filtri Bloom e Cuckoo, Count-Min Sketch, Top-K e t-digest fanno parte di Redis Open Source 8. Nella versione iniziale Redis 8.0.0 è stato incluso anche Vector Set, sebbene in questa versione fosse espressamente contrassegnato come anteprima.

Per i fornitori, ciò semplifica la gestione dei prodotti quando un servizio richiede effettivamente dati documentali, funzionalità di ricerca o serie temporali. I componenti vengono versionati e distribuiti insieme a Redis. In questo modo si evita la necessità di allineare i moduli dello stack installati indipendentemente con la versione del server; allo stesso tempo, un singolo modulo integrato non può essere aggiornato separatamente dalla versione di Redis.

Nella documentazione attuale di Redis, i Vector Set sono descritti come un tipo di dati a sé stante, con comandi specifici, a partire da Redis 8.0. Tuttavia, dal fatto che la versione iniziale sia contrassegnata come "preview" si deduce che un'offerta di hosting non dovrebbe basarsi esclusivamente su Redis 8.0.0 per concludere che il sistema sia pronto per l'uso in produzione senza limitazioni. Sono determinanti le note di rilascio, lo stato delle patch e il test funzionale della versione di destinazione concretamente scelta.

Un'offerta gestita per i cataloghi di prodotti può fornire documenti JSON e indici di ricerca all'interno della stessa installazione di Redis 8. Per la telemetria, Time Series può fornire un modello di dati adeguato. Le strutture probabilistiche sono utili quando le applicazioni possono operare con approssimazioni controllate, ad esempio per identificare elementi presumibilmente già noti prima di eseguire una query backend più costosa.

Per una cache di oggetti classica, tuttavia, ciò non comporta la necessità di adottare nuovi modelli di dati. Le applicazioni WordPress, di e-commerce o PHP utilizzano spesso stringhe, hash e tempi di scadenza. L’integrazione può facilitare la standardizzazione della versione di Redis fornita, ma non giustifica l’uso di indici di ricerca, documenti JSON o dati vettoriali in assenza di requisiti applicativi concreti e di una pianificazione delle capacità.

Il fattore determinante è quindi il limite di servizio: un sistema snello Server di cache richiede soprattutto una gestione prevedibile della memoria e accessi chiaramente limitati. Un servizio di dati o di ricerca necessita inoltre di un modello di dati, di una struttura di indici, di un comportamento di interrogazione e di un modello operativo. Redis 8 fornisce tutti questi elementi, ma non prende al posto dell’utente questa decisione architettonica.

La gestione congiunta delle versioni riduce quindi soprattutto la complessità nella gestione delle release. Non sostituisce tuttavia la verifica che i client supportino i comandi utilizzati o che un’implementazione esistente dello stack Redis utilizzi configurazioni e indici specifici. Prima di una migrazione, tali dipendenze devono essere incluse nell’analisi tecnica dello stato attuale.

Valutare i vantaggi in base al caso d’uso di Redis

Il fatto che Redis 8 offra un valore aggiunto concreto dipende più dal caso d’uso che dal numero di versione. Per la cache degli oggetti, la memoria di sessione, le code, il rate limiting e la cache generale delle applicazioni, le funzionalità di base di Redis rimangono fondamentali. I nuovi tipi di dati sono facoltativi in questo contesto; l’applicazione non deve né comprenderli né utilizzarli per funzionare con Redis 8.

• Cache classica e sessioni: i vantaggi derivano soprattutto da un server ben gestito e da un funzionamento controllato; le funzioni di ricerca o vettoriali rappresenterebbero nella maggior parte dei casi una complessità aggiuntiva e inutilizzata.
• Code e limitazione della frequenza: le strutture dati Redis e le operazioni atomiche rimangono fondamentali. Le strutture probabilistiche possono integrare casi particolari, ma non forniscono un conteggio esatto in generale.
• Ricerca dei prodotti e dati dei documenti: JSON e Redis Search possono supportare un approccio basato su servizi integrati quando sono effettivamente necessari modelli di dati, indici e query.
• Telemetria e analisi approssimative: le serie temporali, gli sketch e i filtri sono adatti a valori di misura basati sul tempo o a metodi di approssimazione, a condizione che le applicazioni tengano conto dei limiti dei loro risultati.

Nel caso di una normale cache degli oggetti, la pianificazione operativa dovrebbe quindi Limiti di memoria e dare priorità ai tempi di scadenza. Senza un limite fisso, uno spazio chiave in crescita può compromettere altri servizi sull'host. La strategia di eviction più adeguata dipende dal fatto che nella stessa istanza siano presenti esclusivamente voci di cache non essenziali o anche dati rilevanti dal punto di vista tecnico; per quanto possibile, questi due tipi di dati non dovrebbero essere mescolati.

Per tutti i casi d’uso, il limite di rete è più fondamentale di un nuovo comando. Redis raccomanda di non rendere le istanze accessibili direttamente da Internet e di limitare la porta Redis a client affidabili. Il protocollo TLS può proteggere le connessioni dei client, la replica e il bus del cluster; gli ACL limitano inoltre i comandi e gli spazi delle chiavi accessibili.

Un aggiornamento a Redis è quindi consigliabile, nel caso di cache pure, soprattutto come modernizzazione pianificata della versione, della manutenzione e del modello operativo. Nel caso di applicazioni di ricerca, telemetria o vettoriali, l’ampia gamma di funzionalità integrate può rivelarsi ulteriormente rilevante. In entrambi i casi, la domanda rimane la stessa: quali dati, carico e limiti di sicurezza deve effettivamente gestire questa singola istanza?

Nuove funzionalità e fabbisogno di risorse

Redis Open Source 8 riunisce funzionalità che in precedenza venivano tipicamente fornite tramite Redis Stack e i suoi componenti: documenti JSON, Redis Search, Time Series e strutture di dati probabilistiche. A queste si aggiungono i Vector Sets, che nella versione iniziale Redis 8.0.0 erano presenti in anteprima. Per le offerte di hosting, la distribuzione integrata riduce il numero di componenti da gestire separatamente.

Il vantaggio deriva tuttavia solo da un modello di servizio concreto. JSON e Redis Search, ad esempio, sono adatti ai cataloghi di prodotti o alla ricerca di documenti, mentre Time Series è indicato per i valori di misurazione basati sul tempo. Una cache a oggetti classica, al contrario, spesso non richiede né interrogazioni di documenti né indici: per essa, la quota di memoria, i tempi di scadenza e un comportamento di eviction adeguato rimangono decisioni operative fondamentali.

Nel caso dei filtri Bloom e Cuckoo, di Count-Min Sketch, Top-K e t-digest, il limite tecnico è particolarmente importante: questi metodi supportano stime di probabilità, frequenza, rango o quantile, ma non memorizzano necessariamente tutte le singole informazioni in modo esatto. In questo modo possono alleggerire il carico delle ricerche nel backend o delle analisi approfondite; tuttavia, non sono adatti per valori singoli rilevanti ai fini contabili o a prova di revisione senza un'ulteriore verifica.

Il rate limiting classico richiede invece una procedura scelta in modo mirato, come contatori, token bucket o sliding window, con strutture Redis adeguate e operazioni atomiche. Le strutture probabilistiche possono al massimo integrare un caso particolare appositamente progettato e basato su approssimazioni. Non costituiscono un sostituto generale di una logica di limitazione esatta.

I Vector Sets rispondono a un'esigenza diversa. Redis memorizza rappresentazioni vettoriali e ricerca elementi simili; facoltativamente, è possibile includere attributi JSON per il filtraggio. Redis non genera autonomamente gli embedding. Le applicazioni devono quindi importarli da un modello o da un servizio esterno prima di poterli utilizzare per la ricerca semantica, i consigli o il recupero dei dati.

Dimensionare in modo realistico i set di vettori

A Set di vettori è pensato per questioni quali „prodotti simili“, „passaggi di testo corrispondenti“ o la ricerca semantica. La ricerca generale a testo pieno e la somiglianza vettoriale rappresentano approcci diversi: Redis Search può gestire campi testuali e query, mentre i Vector Sets determinano le somiglianze tra vettori. Una normale cache web non ottiene alcun valore aggiunto funzionale dai soli vettori.

La pianificazione delle funzionalità deve rimanere legata alla versione. Redis 8.0.0 ha introdotto i Vector Set in anteprima. La documentazione attuale descrive la struttura dei dati e i relativi comandi, ma non attesta retroattivamente che la versione iniziale fosse pienamente pronta per l’uso in produzione. Prima dell’utilizzo è quindi necessario verificare le note di rilascio e il comportamento della versione di Redis specificatamente scelta con i client richiesti.

Per la prima pianificazione della capacità, la documentazione indica, per 300 dimensioni, un valore calcolato di 1.200 byte per vettore FP32 o 300 byte per vettore Q8. Con 100.000 vettori FP32 si ottengono circa 120 MB di dati grezzi; con i vettori Q8 circa 30 MB. Questo calcolo descrive esclusivamente la componente vettoriale e non costituisce una garanzia del fabbisogno di memoria di un'istanza produttiva.

Inoltre, la struttura di ricerca basata su HNSW richiede memoria per i collegamenti del grafo. A ciò si aggiungono le etichette e gli attributi opzionali; anche la frammentazione, i duplicati e i dati persistenti possono modificare il fabbisogno effettivo di risorse. Chi pianifica un'implementazione ad alta disponibilità non deve quindi limitarsi a equiparare la dimensione lorda alla memoria disponibile su un singolo nodo.

La scelta tra FP32 e Q8 è quindi una decisione legata alla qualità e alle risorse, non un’ottimizzazione universale. È opportuno predisporre un ambiente di staging con vettori rappresentativi, attributi dei filtri e modelli di query. In questo modo è possibile valutare l’occupazione della memoria, i tempi di risposta e la qualità dei risultati per il caso specifico del cliente, prima di definire le capacità o i limiti dei mandanti.

Preparare in modo controllato l'aggiornamento di Redis

A Aggiornamento di Redis Il passaggio da Redis Open Source 7.x o Redis Stack a Redis 8 dovrebbe avvenire come aggiornamento pianificato, non come semplice aggiornamento del pacchetto senza supervisione su un sistema di produzione. In primo luogo, occorre selezionare una versione di destinazione specifica, compreso il periodo di supporto. Successivamente, un'istanza di staging riproduce il modello di dati, la persistenza, i client e i ruoli di accesso rilevanti nel modo più realistico possibile.

Prima dell’intervento, il team dovrebbe chiarire quali file di persistenza e backup appartengano effettivamente all’istanza e come avvenga il ripristino. Redis indica, per il processo di aggiornamento, il backup, l’esecuzione di test e le successive verifiche relative alla versione, all’accesso ai dati e alle connessioni dei client. Un rollback documentato richiede quindi non solo i vecchi pacchetti, ma anche un percorso di ritorno tracciabile per i dati e la configurazione.

Per una prima analisi della situazione, è opportuno prendere in considerazione le informazioni relative al server e alla persistenza, nonché il percorso dei dati configurato. Esegui le seguenti query utilizzando un account autorizzato a tale scopo e salva i risultati al di fuori di ticket o log accessibili al pubblico, qualora contengano dettagli sull’infrastruttura.

redis-cli INFO server
redis-cli INFO persistence
redis-cli CONFIG GET dir
redis-cli INFO server | grep redis_version

Il comando SAVE È menzionato nella documentazione relativa all'aggiornamento per uno snapshot, ma non è un comando standard senza conseguenze: trattandosi di un'operazione sincrona, può influire sul funzionamento a seconda del volume di dati e del carico. Pianificare i backup e le finestre di manutenzione in base al modello di persistenza utilizzato. Per garantire la riproducibilità delle procedure di staging e rollback, è utile un flusso di lavoro sottoposto a controllo di versione con ambienti chiaramente separati; a questo proposito è utile l'articolo Web hosting con supporto Git.

Verificare gli ACL e la separazione dei clienti

Un servizio Redis gestito parte da un chiaro confine di rete: la porta Redis non dovrebbe essere accessibile pubblicamente, ma essere aperta esclusivamente a server applicativi affidabili o a reti di gestione. Il protocollo TLS protegge le connessioni dei client, la replica e il bus del cluster durante il trasporto. Queste misure si completano a vicenda; il TLS non sostituisce né un firewall restrittivo né un controllo degli accessi accurato all’interno del server.

Per più clienti o applicazioni è Separazione dei clienti più di un numero di database distinto. Le istanze dedicate sono le più semplici da delimitare. Se più clienti condividono un'istanza, gli ACL devono limitare i comandi consentiti e gli spazi delle chiavi; inoltre, i limiti di memoria impediscono che un singolo carico di lavoro esaurisca la capacità a disposizione degli altri clienti. I prefissi delle chiavi sono un elemento della regola, ma non costituiscono una misura di sicurezza a sé stante.

Nell'aggiornamento di Redis alla versione 8, occorre prestare particolare attenzione alla verifica ACL. I comandi dei componenti ora integrati riguardano categorie esistenti quali @read e @write assegnata. Un’autorizzazione finora formulata in modo generico può quindi consentire anche, ad esempio, le query di ricerca o gli accessi in scrittura JSON. Di conseguenza, un’ACL sintatticamente valida non garantisce automaticamente che l’autorizzazione sia ancora minimamente adeguata dal punto di vista tecnico.

In pratica, è consigliabile eseguire un confronto ACL (ACL-Diff): le regole esportate dall’istanza precedente vengono confrontate con quelle previste in Redis 8. Per ogni ruolo utente, il team dovrebbe verificare quali comandi siano effettivamente necessari, quali prefissi di chiave rimangano accessibili e se una nuova categoria ereditata includa diritti indesiderati. È fondamentale confrontare le autorizzazioni effettive, non solo il testo delle righe della configurazione.

Successivamente vengono creati test mirati per ciascun ruolo: un client di cache web, ad esempio, può leggere e scrivere le chiavi di cache a lui assegnate, ma non può utilizzare prefissi estranei né comandi di amministrazione. Per le applicazioni di ricerca o JSON valgono test specifici. Tali verifiche basate sui ruoli rendono le modifiche tracciabili, senza imporre un modello ACL universale per le diverse architetture dei clienti.

Funzionamento, monitoraggio e risoluzione dei problemi

Per il funzionamento, si raccomanda di monitorare separatamente l’utilizzo della memoria, gli eviction, le latenze, le connessioni dei client, la persistenza e la replica. Questi valori riflettono diversi colli di bottiglia e dovrebbero quindi essere valutati insieme al rispettivo modello di servizio. Un aumento delle espulsioni non indica automaticamente un errore di Redis, ma costituisce un motivo per verificare i limiti di memoria, i tempi di scadenza e il modello di dati.

Gli indici di ricerca e i set di vettori non devono essere inclusi in un unico contenitore di valori misurati insieme a una normale cache di oggetti. Oltre all’insieme delle chiavi, in tale contesto vengono considerati anche le memorie di indice e di grafo, gli attributi e il relativo carico di query. Nel caso dei vettori, al fabbisogno di dati grezzi si aggiungono etichette, connessioni, frammentazione, replica e persistenza. Dimensionare un’istanza basandosi esclusivamente sui valori vettoriali significa quindi sottovalutare il fabbisogno reale di risorse.

Redis 8 introduce una nuova implementazione del threading I/O; l'impostazione io-threads non è però un fattore determinante per le prestazioni in generale. Anche i miglioramenti nella replica non garantiscono un aumento generale della velocità di elaborazione. I core della CPU, la rete, la persistenza, il mix di comandi e il comportamento dei client contribuiscono a determinare se una modifica sia utile. Per questo motivo, le varianti di configurazione devono essere testate in un ambiente di staging simile a quello di produzione, con il proprio profilo di carico.

Dopo un aggiornamento, i problemi dei client non rilevati sono spesso più significativi delle semplici metriche del server. Il team dovrebbe verificare le connessioni, l’autenticazione, i comandi utilizzati e le risposte di errore utilizzando le librerie client effettive. Altrettanto importante è disporre di una procedura di ripristino ben collaudata: un backup esistente riduce il rischio solo se, dopo il ripristino, si verifica che i dati e l’applicazione funzionino correttamente.

Per la segnalazione degli allarmi sono utili soglie distinte in base alla classe di servizio. Una cache può tollerare consapevolmente gli eviction, mentre questi possono comportare una perdita di dati nel caso delle sessioni o delle code. I carichi di lavoro relativi alle ricerche e ai vettori richiedono inoltre un monitoraggio dell’andamento della memoria e delle latenze delle query. L’articolo fornisce informazioni di base su osservabilità, scalabilità e pianificazione delle risorse Tendenze nel settore dell'hosting 2026.

Ai fini della ricerca degli errori, le modifiche apportate al modello di dati, alla versione del client, al limite di memoria e alla configurazione della persistenza dovrebbero essere correlate temporalmente alle metriche. In questo modo è possibile distinguere se un picco di latenza, ad esempio, coincida con un nuovo carico di ricerca, un aumento delle connessioni o una fase di persistenza. Questa correlazione è più attendibile rispetto all’ipotesi che ogni anomalia sia una conseguenza dell’aggiornamento di Redis.

Il ripristino come verifica fiscale Un backup da solo non garantisce la capacità di ripristino. La guida all’aggiornamento raccomanda di eseguire prove controllate del backup e dell’aggiornamento e di verificare successivamente l’accessibilità dei dati e le connessioni dei client.

Scegliere la licenza e il prodotto

Con Redis 8, la scelta della licenza è una decisione relativa al prodotto, non semplicemente un punto delle istruzioni di installazione. Redis Open Source può essere utilizzato con licenze RSALv2, SSPLv1 o AGPLv3. L'opzione più adatta per un'istanza interna, un'infrastruttura di un cliente o un prodotto Managed Redis offerto al pubblico dipende dalla specifica modalità di distribuzione e dagli obblighi ad essa associati.

RSALv2 limita, tra l’altro, la commercializzazione o la fornitura delle funzionalità del software come servizio gestito (Managed Service) a terzi. SSPLv1 e AGPLv3 contengono requisiti di copyleft che possono diventare rilevanti in caso di fornitura di servizi o di accesso alla rete. La presente breve descrizione non sostituisce una consulenza legale: prima di definire i prezzi, stipulare un contratto o lanciare un prodotto, è opportuno sottoporre l’architettura concreta a una verifica giuridica.

Altrettanto importante è la differenziazione del prodotto. Redis Open Source 8 indica la linea di server con le relative strutture dati e funzioni di query integrate. Redis Software è invece una linea di prodotti commerciali con una propria documentazione relativa alle versioni e supporto per diverse versioni del database Redis. Da ciò non si deve dedurre che ogni funzione di clustering, gestione o alta disponibilità ivi descritta faccia parte di una normale installazione open source.

Anche Valkey o altri fork non sono varianti di Redis 8. Chi li considera un’alternativa deve verificare autonomamente i comandi supportati, il modello operativo, la licenza e il percorso di migrazione. Un’interfaccia di protocollo simile o un’origine storica comune non sono sufficienti per dedurre garanzie di funzionalità e compatibilità per le applicazioni o le offerte gestite.

Una decisione sostenibile tiene conto di cinque aspetti: quale versione specifica di Redis è adeguata al periodo di supporto previsto? Il carico di lavoro richiede effettivamente funzionalità di ricerca, serie temporali o vettori? Il modello operativo è coperto in termini di isolamento, backup e monitoraggio? Sono stati verificati gli ACL e i client? E la Esame di abilitazione per il tipo di servizio offerto? È solo la combinazione di questi elementi a trasformare un aggiornamento di Redis in un’offerta di hosting affidabile.