Redis conserva valores organizados por claves y ofrece operaciones sobre distintas estructuras de datos. Puede servir una caché, contadores, sesiones, colecciones o flujos de eventos. El papel de una instancia depende del contrato de los datos y de cómo se configura y opera; Redis no convierte todo su contenido en una copia descartable.
La clave decide qué objeto se identifica. La estructura decide qué operaciones pueden hacerse sobre su valor. En Redis Cluster, otra decisión conecta esa clave con un slot y con su primario. Separar identidad, operación y ubicación evita resolver un problema de carga cambiando accidentalmente el significado de los datos.
Nombres de claves e identidad
Una convención como user:42:profile o cart:42:items expresa entidad, identificador y propósito. Hace más fácil reconocer qué representa una entrada y quién la administra. El separador es una convención de la aplicación: no crea carpetas ni relaciones por sí mismo.
Los prefijos tampoco crean índices de consulta. Conocer user:42:profile permite pedir esa clave; buscar todos los usuarios por ciudad necesita otra estructura, un índice explícito o un almacén apropiado. Recorrer claves por patrón no equivale a una consulta indexada y puede costar trabajo proporcional al conjunto examinado.
La identidad debe ser estable y compartida por los participantes. Si cada petición añade un sufijo aleatorio a un contador, ya no actualiza el mismo contador. Si se crean varias claves para una entidad, el diseño debe explicar cómo se consultan, actualizan y retiran juntas.
Elegir una estructura y sus operaciones
El valor de una clave puede representar más que un texto. La documentación de tipos de datos describe estructuras con operaciones y costes diferentes. Algunos ejemplos permiten elegir según el acceso:
| Estructura | Uso posible | Operaciones orientativas |
|---|---|---|
| String | Un valor, contador o representación serializada. | GET, SET, INCR. |
| Hash | Campos de un objeto identificado por una clave. | HGET, HSET. |
| List | Secuencia con inserción y extracción por sus extremos. | LPUSH, LPOP. |
| Set | Miembros únicos sin orden de consulta garantizado. | SADD, SISMEMBER. |
| Sorted set | Miembros con un score para ordenar o consultar rangos. | ZADD, ZRANGE. |
| Stream | Entradas de un log con mecanismos de consumo. | XADD, XREADGROUP. |
Los nombres de comandos ilustran accesos, no una receta completa. Un stream o una list no establecen por sí solos el contrato de entrega y recuperación de una cola: acknowledgements, reintentos, pendientes y persistencia siguen importando.
Se revisa el coste del comando concreto y el tamaño de sus entradas y resultados. Una lectura puntual y recuperar toda una colección no hacen el mismo trabajo. Bytes transferidos, serialización y operaciones sobre valores grandes pueden dominar la latencia aunque una operación tenga una complejidad favorable respecto del número de elementos.
Una clave que contiene una colección enorme también concentra memoria y trabajo. Conviene definir tamaños y accesos esperados antes de elegir una estructura; añadir nodos no divide automáticamente ese objeto.
Redis Cluster: clave, slot y primario
Redis Cluster distribuye 16,384 slots fijos, numerados de 0 a 16,383. La especificación de Cluster define el cálculo CRC16(clave) % 16384, salvo la regla de hash tags. Un mapa asigna cada slot a su primario.
Esto no es un anillo de consistent hashing. Al incorporar nodos se pueden reasignar slots y mover sus claves, sin cambiar el número de slots ni el cálculo de una clave estable. La distinción entre partición lógica y propietario físico es parte del diseño de sharding. No implica que la migración ocurra sin coste o coordinación.
Para utilizar un hash tag, Redis busca el primer { y el primer } situado a su derecha. Si el interior no está vacío, calcula el hash con ese contenido; si no hay una pareja válida o está vacía, utiliza la clave completa. No busca otra pareja después de un primer par vacío.
cart:{user:42}:items y cart:{user:42}:meta utilizan user:42 como entrada al hash. En este ejemplo ambas resultan en el slot 15880. El mapa ilustrativo asigna ese slot al primario C; otro mapa puede elegir un propietario distinto sin cambiar el hash.
Las flechas muestran decisiones lógicas de enrutamiento de esas dos claves; el hash, el slot y el mapa no representan servicios de red separados. El primario C es una asignación del ejemplo, no una identidad incorporada a la clave ni una réplica.
--- config: look: handDrawn --- flowchart TD keys["cart:{user:42}:items<br/>cart:{user:42}:meta"] --> hash["Hash tag: user:42<br/>CRC16 % 16384"] hash --> slot["Slot 15880<br/>partición lógica"] slot --> routing["Mapa de slots<br/>topología vigente"] routing --> primary["Primario C<br/>propietario ilustrativo"]
Colocación y operaciones multiclave
Muchas operaciones multiclave compatibles con Cluster requieren que todas las claves estén en el mismo slot. Estar en el mismo nodo no basta: ese nodo puede poseer numerosos slots. El hash tag permite expresar colocación cuando la operación lo necesita; no convierte todo un grupo de usuarios en una unidad que deba compartir ubicación.
Una operación sobre items y metadata del mismo carrito puede justificar un tag común. Usar un tag fijo para todos los carritos concentra sus claves en un único slot y reduce la capacidad de repartirlos. La unidad se elige por la operación que necesita coordinarse y por el trabajo que puede sostener su propietario.
Una actualización atómica de un comando no hace atómica una secuencia arbitraria de llamadas. Scripts y mecanismos transaccionales tienen restricciones propias, incluido el alcance de claves permitido en Cluster. La atomicidad local que usa un Rate Limiter debe distinguirse de una decisión global entre primarios o de un efecto externo.
Los clientes deben entender la topología y las respuestas de enrutamiento. MOVED y ASK pueden señalar otro destino o una transición; durante una migración, ciertas operaciones multiclave pueden recibir TRYAGAIN. Compartir slot no elimina todas las condiciones de fallo, y los reintentos de mutaciones necesitan preservar su significado.
Hot key y shard caliente
Una hot key recibe mucho trabajo sobre un único objeto. Un shard caliente puede acumular carga de muchas claves o de una clave dominante. Redistribuir slots puede aliviar un propietario sobrecargado, pero mover el slot no divide el trabajo de una sola clave entre varios primarios.
Añadir sufijos aleatorios no es una solución universal. Crear counter:42:a y counter:42:b, sin hash tags, divide la identidad y puede repartir las claves, pero obliga a definir actualización, lectura y agregación. En cambio, counter:{user:42}:a y counter:{user:42}:b conservan el mismo tag y siguen en el mismo slot. Los sufijos cambian el modelo; no hacen transparente esa distribución.
Las mitigaciones dependen del acceso. Lecturas repetidas pueden admitir una caché local, agrupamiento de peticiones y una política de frescura. Una réplica puede servir lecturas compatibles con su retraso, pero no elimina la carga de una escritura que debe decidir el primario. Dividir una colección o contador sólo encaja cuando el contrato admite agregar partes y resolver concurrencia.
Se observan peticiones, bytes, latencia y trabajo por clave y por propietario. Un reparto parecido del número de claves no demuestra balance de memoria o tráfico. El objetivo es identificar qué recurso se concentra y qué parte del acceso puede repartirse sin romper la operación.
TTL, eviction y límites de memoria
El TTL define cuándo vence una clave según el mecanismo de expiración. La eviction retira claves para cumplir una política de memoria. Son decisiones distintas: una entrada con TTL vigente puede ser expulsada si la política la incluye, y una entrada sin TTL puede permanecer o ser candidata según la configuración.
Las políticas de eviction se eligen por el uso de la instancia. Una política que elimina entradas reconstruibles no sirve automáticamente para inventario autoritativo. Redis utiliza aproximaciones para políticas como LRU; no debe describirse como una clasificación exacta e infalible de toda la carga.
maxmemory guía la política del servidor, pero no equivale al consumo total de memoria del proceso: overhead y buffers de replicación o persistencia pueden requerir margen adicional. Tamaño de claves y valores, crecimiento, límites y comportamiento al quedarse sin capacidad deben verificarse juntos.
Vencer o retirar una entrada tampoco demuestra que una operación de negocio terminó. Las reservas de boletaje necesitan comprobar autoridad, propietario y vigencia al confirmar una venta. El TTL no sustituye esa decisión. Las mutaciones pueden alterar la expiración según el comando; renovarla o conservarla debe ser explícito.
Persistencia, fallos y contrato de los datos
Redis trabaja con datos en memoria y ofrece opciones de persistencia RDB y AOF. Un snapshot conserva un punto del tiempo; un log y su política de sincronización cambian la ventana de pérdida y los costes de operación. Elegir una opción no garantiza sobrevivir a cualquier fallo sin perder datos.
Replicación y alta disponibilidad son decisiones adicionales. La replicación asíncrona puede dejar una réplica retrasada y perder escrituras ya reconocidas al promoverla. Backups, restauración y recuperación siguen necesitando un contrato. No se deduce exactly-once ni ausencia de pérdida por utilizar Redis Cluster.
Un timeout puede dejar incierto si una mutación se aplicó. Repetir un incremento o una decisión de cobro puede producir un efecto adicional si la operación no está diseñada para tolerarlo. Conocer la clave y su propietario no reemplaza la identidad y coordinación de la operación.
Si Redis conserva una caché, una caída puede trasladar demanda al almacén de origen: el fallback necesita límites para no saturarlo. Si conserva estado autoritativo, la pérdida o indisponibilidad debe resolverse según su durabilidad y reglas de recuperación, no como si todos los valores fueran reconstruibles.
Un diseño útil explica qué identifica cada clave, qué comandos actúan sobre ella, dónde se ubica y qué puede perderse o retrasarse. Slots, estructuras, TTL y réplicas ayudan a implementar ese contrato; no lo definen por sí solos.