Redis Cluster per PMI Italiane — Scalabilità Orizzontale e Sharding Senza Perdere il Controllo

Il tuo Redis instance unico non basta più. Le query impiegano secondi, la memoria è satura, e i clienti iniziano a lamentarsi di tempi di attesa. Hai provato ad aumentare RAM e CPU, ma i costi salgono e il problema si ripresenta. La soluzione si chiama Redis Cluster: sharding nativo e scalabilità orizzontale senza modificare il codice lato applicativo? Quasi. Ma attenzione: se non lo configuri bene, rischi di peggiorare la situazione.

Noi, di Meteora Web, abbiamo affrontato la scalabilità di un e-commerce con Redis Cluster durante una stagione di picco. Partivamo da un'istanza singola con 16 GB di RAM e CPU al 90%. Con il cluster abbiamo distribuito il carico su tre nodi e dimezzato la latenza. In questa guida ti spieghiamo come funziona lo sharding in Redis Cluster, quali rischi evitare e come configurarlo per applicazioni PHP/Laravel.

Cos'è il Redis Cluster e perché lo sharding cambia le regole del gioco?

Redis Cluster è una modalità distribuita in cui i dati vengono suddivisi automaticamente tra più nodi tramite hash slot (16384 slot totali). Ogni nodo gestisce un sottoinsieme di slot. Quando un client fa una richiesta, il cluster reindirizza la query al nodo corretto con un errore MOVED oppure, se usi un client smart, la risoluzione avviene lato client senza roundtrip extra.

Lo sharding orizzontale significa che puoi aggiungere nodi senza downtime per aumentare capacità e throughput. Non è replicazione: ogni chiave vive su un solo nodo master (con repliche opzionali per alta disponibilità). Questo cambia le regole perché non puoi più eseguire operazioni multi-chiave su slot diversi (come SUNION tra chiavi su nodi differenti). Devi progettare le chiavi in modo che quelle correlate cadano nello stesso slot, usando hash tag (es. {user:123}:cart).

Perché conviene a una PMI? Perché eviti di comprare un server mostruoso e puoi scalare con macchine economiche. Un cluster a 3 nodi da 8 GB e 4 vCPU ciascuno costa meno di un singolo nodo da 32 GB e 16 vCPU, e offre ridondanza.

Come funziona lo sharding in Redis Cluster rispetto a un'istanza singola?

In un'istanza singola, tutte le chiavi risiedono sullo stesso processo. Con Redis Cluster, la chiave viene mappata a uno slot usando CRC16(key) % 16384. Il cluster mantiene una mappa degli slot su ogni nodo. Quando un client (es. Predis o PhpRedis con supporto cluster) si connette, recupera la mappa e indirizza direttamente al nodo giusto. Se un nodo non è responsabile per quello slot, risponde con un errore MOVED e il client aggiorna la mappa.

Hash tag: come raggruppare chiavi correlate

Se le tue chiavi includono un identificatore comune tra parentesi graffe, Redis Cluster userà solo la parte tra { e } per calcolare lo slot. Esempio: {user:42}:session e {user:42}:cart finiranno sullo stesso slot, permettendo operazioni multi-chiave su quel sottoinsieme.

# Esempio di creazione cluster con redis-cli su 3 nodi (sviluppo)
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 --cluster-replicas 0

Attenzione: Se hai codice che esegue KEYS * o SCAN senza specificare lo slot, non funzionerà su cluster. Devi usare SCAN con l'opzione COUNT su ogni nodo separatamente.

Quanto è complesso configurare un Redis Cluster per un'applicazione PHP o Laravel?

Dipende dal client che usi. Con Predis, devi configurare la connessione come cluster:

$client = new Predis\Client([
    'tcp://127.0.0.1:7000',
    'tcp://127.0.0.1:7001',
    'tcp://127.0.0.1:7002'
], [
    'cluster' => 'redis'
]);

Con PhpRedis, se compilato con supporto cluster, puoi usare RedisCluster:

$cluster = new RedisCluster(null, ['127.0.0.1:7000', '127.0.0.1:7001', '127.0.0.1:7002']);

In Laravel, il file config/database.php supporta array di server con opzione cluster:

'redis' => [
    'client' => 'phpredis', // o 'predis'
    'options' => [
        'cluster' => 'redis',
    ],
    'clusters' => [
        'default' => [
            [
                'host' => '10.0.0.1',
                'port' => 7000,
                'database' => 0,
            ],
            [
                'host' => '10.0.0.2',
                'port' => 7001,
            ],
            [
                'host' => '10.0.0.3',
                'port' => 7002,
            ],
        ],
    ],
],

Checklist operativa per la configurazione:

• Usa versioni di Redis >= 3.0 per il cluster.
• Abilita il cluster in ogni nodo: cluster-enabled yes, cluster-config-file nodes.conf.
• Assicurati che i nodi possano comunicare sulle porte dati (es. 7000-7002) e sulle porte bus cluster (es. 17000-17002).
• Avvia i nodi, poi esegui redis-cli --cluster create per assemblare il cluster.
• Verifica con redis-cli --cluster check 127.0.0.1:7000.
• Testa il failover manuale spegnendo un master e osservando la promozione di una replica.

Quali sono i limiti e i rischi del Redis Cluster che ogni sviluppatore deve conoscere?

Redis Cluster non è una bacchetta magica. Ecco i principali ostacoli che abbiamo incontrato nei progetti reali:

• Operazioni multi-chiave cross-slot: comandi come SINTER, SUNION, RENAME falliscono se le chiavi appartengono a slot diversi. Soluzione: usa hash tag o riprogetta le chiavi.
• Transaction (MULTI/EXEC) su slot multipli: non supportate. Le transazioni sono atomiche solo per chiavi nello stesso slot.
• Lua script: gli script devono essere eseguiti su un singolo nodo oppure coinvolgere chiavi dello stesso slot.
• Resharding online: possibile ma non banale. Redis fornisce redis-cli --cluster reshard, ma durante il trasferimento le operazioni su slot in movimento possono fallire con ASK e MOVED. Il client deve gestire questi redirect.
• Numero massimo di nodi: teoricamente fino a 1000 nodi, ma oltre 100 la gestione degli slot diventa complessa.

Rischio concreto: un cliente ci ha chiamato perché dopo aver migrato a Redis Cluster le sessioni utente venivano perse casualmente. Il motivo? Le chiavi di sessione non avevano hash tag e finivano su slot diversi, ma il codice eseguiva DEL su chiavi di sessioni correlate con UNLINK che non garantiva atomicità cross-slot. Abbiamo risolto aggiungendo il prefisso {session} a tutte le chiavi di sessione.

Cosa fare adesso

1. Analizza il tuo carico attuale: usa INFO MEMORY e MONITOR per capire quali comandi multi-chiave usi. Se fai spesso KEYS o SMEMBERS su set grandi, devi ripensare la logica.
2. Progetta le hash key con hash tag: adotta una convenzione {entità}:id:campo per raggruppare dati correlati.
3. Configura un cluster di test: su Docker o su tre macchine virtuali con redis in modalità cluster, segui la checklist sopra.
4. Migra progressivamente: non buttare via l’istanza singola. Usa un proxy come Twemproxy o Redis Sentinel come ponte, poi passa al cluster quando la logica applicativa è pronta.
5. Monitora con strumenti ad hoc: redis-cli --cluster info, redis-cli --cluster check, e integra Grafana con il prometheus redis_exporter per vedere slot distribution, latenza e errori MOVED.

Se hai bisogno di una mano con la migrazione o la progettazione dello schema chiavi, contatta Meteora Web. Noi vediamo cluster Redis in produzione ogni giorno e possiamo evitarti i dolori dell'apprendimento sul campo.