Categoria: Bases de dades
Redis i Valkey gestionats: memòria cau, cues i sessions sense perdre dades
La memòria cau, les cues de treballs i les sessions de la vostra aplicació en un Redis o un Valkey que no es queda sense memòria, que commuta sol si cau i que sap quines dades pot perdre i quines no.
- On es munta
- Al vostre compte, a nom vostre
- Còpies
- Amb restauració provada
- Actualitzacions
- Planificades i documentades
- Llicència
- Valkey: BSD 3-Clause. Redis 8: RSALv2, SSPLv1 o AGPLv3
En resum
Redis és una base de dades en memòria de clau i valor que es fa servir com a memòria cau, cua i magatzem de sessions; Valkey és la seua bifurcació de codi obert sota la Linux Foundation. Els instal·lem i els operem al vostre compte del núvol: persistència, rèpliques amb Sentinel o Cluster, límits de memòria, mètriques i actualitzacions, tot descrit en codi al vostre repositori.
De què ens encarreguem?
Redis sol entrar en un projecte com «la memòria cau» i acaba guardant sessions, cues de treballs, límits de peticions i bloquejos. Cada ús necessita una configuració diferent, i el problema apareix quan tots comparteixen la mateixa instància amb els ajustos per defecte.
Persistència
RDB, AOF o cap, segons el que passe si es perd el contingut.
Rèpliques
Rèplica asíncrona i commutació amb Sentinel o amb el mode clúster.
Memòria
maxmemory, política d’expulsió i fragmentació sota control.
Mètriques
redis_exporter en Prometheus: memòria, encerts, latència i rèplica.
Accessos
ACL per aplicació, TLS i ordres perilloses bloquejades.
En codi
Configuració en Terraform o Ansible, al vostre repositori i documentada.
Quina arquitectura recomanem?
La primera decisió és separar el que es pot perdre del que no. Una memòria cau pura va en una instància sense persistència i amb expulsió de les claus menys usades. Les sessions i les cues van en una altra, amb AOF i amb la política noeviction: si s’omple, Redis rebutja escriptures i salta una alerta, en lloc d’esborrar en silenci treballs pendents.
| Situació | El que muntem | Per què |
|---|---|---|
| Memòria cau que es pot reconstruir | Un node, sense persistència, allkeys-lru |
El més simple; si cau, l’aplicació torna a la base de dades |
| Sessions o cues en un sol servidor de dades | Principal, rèplica i tres Sentinel, amb AOF | Commutació automàtica i pèrdua limitada a un segon |
| Dades que no caben en un node | Redis Cluster o Valkey en mode clúster | Reparteix claus entre diversos principals amb les seues rèpliques |
| Proveïdor amb servei gestionat | ElastiCache, Memorystore, Azure Managed Redis o un altre | Menys peces; nosaltres ajustem, vigilem i provem |
La rèplica en Redis és asíncrona: una escriptura confirmada es pot perdre si el principal cau just després. Si una operació concreta no ho tolera, fem servir WAIT o la guardem a més en la base de dades principal.
Quins problemes trobem més sovint?
- Sense maxmemory: Redis creix fins que el sistema el mata per falta de memòria i es perd tot de colp.
- Política d’expulsió equivocada: una cua amb
allkeys-lruesborra treballs sense avisar quan s’omple. - Claus sense caducitat: la memòria cau creix sense límit perquè ningú no va posar temps de vida a les claus.
- Ordres que bloquegen: un
KEYS *en producció o claus enormes que aturen el servidor durant segons. - Exposat a internet: sense contrasenya i en el port per defecte, una de les fallades que més s’aprofiten.
- Sentinel en dues màquines: sense majoria possible, la commutació no es produeix o deixa dos principals.
Com fem les còpies i les actualitzacions?
Encara que feu servir AOF, guardem instantànies RDB periòdiques fora del servidor, xifrades, en un altre compte o en un altre proveïdor. La prova consisteix a arrancar una instància aïllada a partir d’aquesta còpia, comprovar el nombre de claus i llegir-ne algunes de control. El temps que tarda queda en l’informe.
Per a actualitzar, comencem per les rèpliques, fem una commutació controlada perquè una rèplica ja actualitzada passe a principal i acabem amb l’antic principal. Així el tall es queda en els segons de la commutació. Abans ho assagem amb una còpia i revisem els canvis de la versió nova, sobretot en ordres i en el format dels fitxers de persistència.
Què passa amb la llicència de Redis?
El 2024 Redis va passar de BSD a RSALv2 i SSPLv1, i d’aquest canvi va nàixer Valkey, amb llicència BSD; amb Redis 8 es va afegir l’opció AGPLv3, que sí que és de codi obert. La història completa i quan convé Valkey són a Valkey gestionat.
Per a la majoria d’empreses que fan servir Redis dins de la seua aplicació, qualsevol de les opcions serveix. Ho revisem amb vosaltres si oferireu Redis com a servei a tercers o si la vostra política interna exigeix llicències aprovades per l’OSI. Triem amb criteris pràctics: què ofereix el vostre proveïdor gestionat, quins mòduls necessiteu i quina versió suporten les vostres biblioteques client.
Com migrem d’un servei gestionat al vostre compte, o a l’inrevés?
Partim d’una còpia RDB exportada o copiem les claus en viu amb una eina de migració, segons la mida i el que tolere l’aplicació. Per a una memòria cau, moltes vegades n’hi ha prou amb apuntar l’aplicació a la instància nova i deixar que s’òmpliga sola. Per a cues i sessions planifiquem el tall en un moment tranquil. Les mètriques acaben en el monitoratge amb Grafana i Prometheus, i si Redis acompanya una base de dades relacional, la gestionem amb el mateix enfocament que el PostgreSQL gestionat.
I Memcached?
Memcached és només una memòria cau: no guarda res en disc, no té rèplica i el repartiment entre nodes el fa la mateixa aplicació. Per a guardar en memòria cau pàgines o resultats de consultes és senzill i ràpid, i si la vostra aplicació ja el fa servir no cal canviar-lo. El dimensionem per memòria, vigilem la taxa d’encerts i les expulsions, i no el tractem com a emmagatzematge: si es reinicia, es buida. Quan necessiteu que les dades sobrevisquen a un reinici, cues o estructures com llistes i conjunts, us recomanem Redis o Valkey. AWS i Google Cloud l’ofereixen gestionat; en la resta el muntem nosaltres.
On ho muntem?
Al vostre compte, al proveïdor que ja feu servir o al que encaixe millor. Si les dades s'han de quedar a la UE, Hetzner i OVHcloud són les opcions europees.
Proveïdors on ho muntem
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propi
| Proveïdor | Com ho muntem | A tindre en compte |
|---|---|---|
| Hetzner | Servidors cloud amb Redis o Valkey, Sentinel en tres màquines i xarxa privada. Còpies RDB a Object Storage de Hetzner, compatible amb S3. | Hetzner no ofereix memòria cau gestionada: la rèplica, la commutació i les còpies les muntem nosaltres. |
| AWS | ElastiCache per a Valkey o Redis OSS, o MemoryDB quan Redis és la base de dades principal i no n'hi ha prou amb una memòria cau. | Revisem la mida del node, la política d'expulsió, les rèpliques entre zones i que la còpia es restaura. |
| Google Cloud | Memorystore for Valkey o Memorystore for Redis, amb mode clúster si cal repartir dades. | Accés privat des de la vostra VPC; res exposat a internet. |
| Azure | Azure Managed Redis, que substitueix Azure Cache for Redis, o màquines virtuals amb Valkey i Sentinel. | Si ja feu servir Azure Cache for Redis, planifiquem la migració que Microsoft indica abans de la retirada. |
| DigitalOcean | Managed Caching for Valkey, que ha substituït el seu antic Redis gestionat, o Droplets amb Sentinel. | |
| OVH | Valkey gestionat d'OVHcloud Public Cloud, o instàncies amb Valkey i Sentinel muntats per nosaltres. | |
| Servidor propi | Redis o Valkey en els vostres servidors o màquines virtuals, amb Sentinel i còpies RDB a un emmagatzematge S3 extern. | Tres màquines per a Sentinel; amb dues, una caiguda de xarxa pot deixar dos principals alhora. |
Què inclou
- Redis o Valkey al vostre compte del núvol o en els vostres servidors, o el servei gestionat del vostre proveïdor si encaixa millor.
- Persistència triada segons l'ús: sense persistència per a memòria cau pura, RDB, AOF o totes dues per a cues i sessions.
- Rèplica i commutació automàtica amb Sentinel, o Redis Cluster quan les dades no caben en un node.
- maxmemory i política d'expulsió ajustades a cada instància, separant la memòria cau de les dades que no es poden perdre.
- Usuaris amb ACL per aplicació, TLS i accés només des de la xarxa privada.
- Mètriques amb redis_exporter i alertes de memòria, expulsions, connexions rebutjades i rèplica endarrerida.
- Còpies RDB fora del servidor i restauració de prova amb el temps mesurat.
- Actualitzacions assajades, rèplica a rèplica, i la configuració en Terraform o Ansible al vostre repositori.
Preguntes freqüents
Triem Redis o Valkey?
Per a memòria cau, cues i sessions tots dos funcionen igual: Valkey va nàixer de Redis 7.2.4 i parla el mateix protocol, així que les biblioteques client serveixen. Valkey té llicència BSD i el manté la Linux Foundation. Redis 8 es pot fer servir sota AGPLv3, que és codi obert, o sota RSALv2 o SSPLv1. Si el vostre proveïdor ofereix un dels dos gestionat, acostumem a partir d'aquest.
Podem perdre dades si Redis es reinicia?
Depén de la persistència. Sense, es perd tot, cosa que està bé per a una memòria cau. Amb RDB perdeu el que s'ha escrit des de l'última instantània; amb AOF i escriptura a disc cada segon, com a molt un segon. Per a cues i sessions configurem AOF i deixem escrit quant es pot perdre.
Sentinel o Redis Cluster?
Sentinel quan les dades caben en la memòria d'un servidor: un principal, rèpliques i commutació automàtica. Cluster quan no hi caben o quan un sol node no aguanta les escriptures. Cluster reparteix les claus i obliga que les operacions amb diverses claus estiguen en el mateix slot, així que l'aplicació ha d'estar preparada.
El munteu dins de Kubernetes?
Sí, amb un operador o un StatefulSet, volums persistents i regles perquè les rèpliques no caiguen en el mateix node. Si la memòria cau és crítica i el proveïdor té servei gestionat, moltes vegades us recomanem traure-la del clúster.
Expliqueu-nos el vostre cas
En una trucada gratuïta de 20 minuts veiem on sou i per on començar. Sense compromís.
Documentació oficial consultada
Les dades tècniques d'aquesta pàgina es basen en:
Revisat el