Server cloud per Redis in Europa: configurazione EU a bassa latenza
Redis e il data store in memoria che si trova davanti al tuo database, assorbe il traffico di lettura e riduce i tempi di risposta da millisecondi a microsecondi. Per le applicazioni che servono utenti europei, eseguire Redis su un server cloud EU non e solo una scelta di prestazioni - mantiene anche i dati di sessione, i token utente e le informazioni personali in cache sotto la giurisdizione UE come richiesto dal GDPR.
Perché la residenza dei dati in UE e importante per Redis
Redis memorizza comunemente token di sessione, preferenze utente e risposte API in cache - tutto ciò può costituire dati personali ai sensi del GDPR. L'hosting su un server EU gestito da un'azienda europea garantisce che questi dati non transitino mai attraverso la giurisdizione statunitense.
La latenza e anche critica per una cache. Un'istanza Redis a Praga o Francoforte aggiunge 0,1-0,5 ms di tempo di andata e ritorno al server delle applicazioni nello stesso data center. La stessa istanza in una regione statunitense aggiunge 80-100 ms.
Specifiche minime per Redis
Redis e interamente in memoria, quindi la RAM e la risorsa principale:
- Piccolo (cache di sessione, fino a 10 GB di dati) - 2 vCPU, 16 GB RAM, 50 GB NVMe SSD
- Medio (cache di pagine/oggetti, 10-50 GB) - 4 vCPU, 64 GB RAM, 100 GB NVMe SSD
- Grande (data store principale o pub/sub) - 8 vCPU, 128 GB RAM, 200 GB NVMe SSD
Configurazione DCXV raccomandata
I server cloud DCXV offrono configurazioni ad alta memoria con storage NVMe:
- 4 vCPU, 64 GB RAM, 100 GB NVMe - cache di produzione per un'applicazione SaaS
- 8 vCPU, 128 GB RAM, 200 GB NVMe - session store ad alto throughput
Contatta sales@dcxv.com per una raccomandazione di configurazione.
Comandi di configurazione rapida
# Installare Redis 7 su Ubuntu 22.04
sudo apt update && sudo apt install -y redis-server
sudo systemctl start redis-server && sudo systemctl enable redis-server
redis-cli ping
# Impostazioni chiave redis.conf per 64 GB RAM
bind 127.0.0.1 10.0.0.5
maxmemory 51gb
maxmemory-policy allkeys-lru
appendonly yes
appendfsync everysec
Quale modalità di persistenza scegliere
Questa è l'unica decisione di Redis che è davvero tua, ed è uno scambio fra durabilità e throughput, non un'impostazione con una risposta giusta:
| Modalità | Sopravvive a un crash | Costo in scrittura | Quando scegliere |
|---|---|---|---|
| Nessuna persistenza | Niente | Nessuno | Una cache pura che puoi ricostruire dal database |
| Snapshot RDB | Tutto fino all'ultimo snapshot | Un picco di fork a ogni salvataggio | Conta la ripartenza a caldo, non i minuti persi |
| AOF, everysec | Tutto tranne l'ultimo secondo | 10-15% | Sessioni, carrelli, tutto ciò la cui perdita si nota |
| AOF, always | Ogni scrittura | 50% o più | Quasi mai: usa un database |
| RDB più AOF | Tutto tranne l'ultimo secondo, e riparte veloce | 10-15% | Un archivio primario, non una cache |
Quello che la tabella non può dire per te: una riscrittura AOF forka il processo, e il fork ha bisogno di memoria. È questo il vero motivo per lasciare libero il 20-25% della RAM invece di riempirla di dati.
Prestazioni attese
Su un'istanza da 4 vCPU / 64 GB RAM con Redis 7:
- Throughput GET (senza pipelining) - 150.000-200.000 ops/s
- Throughput SET - 120.000-160.000 ops/s
- Latenza P99 (GET) - meno di 0,5 ms
Queste sono aspettative per hardware di questa classe, non misurazioni dal nostro laboratorio. Prendile come punto di partenza per il dimensionamento e misura il tuo carico: i numeri reali dipendono dai tuoi dati, dalle tue query e dal tuo tuning molto più che dal fornitore.
Conclusione
Redis su un server cloud EU offre prestazioni di cache sub-millisecondo mantenendo i dati di sessione sotto la giurisdizione UE.
