Este artículo explora las capacidades de Redis desde sus características básicas, detallando sus estructuras de datos y comandos principales, hasta sus funcionalidades avanzadas, incluyendo despliegue, mantenimiento y optimización de rendimiento. Está dirigido a desarrolladores que utilizan Redis y a arquitectos que participan en la selección, diseño de arquitectura y optimización de rendimiento de Redis.

Estructuras de Datos y Comandos Comunes

Redis opera bajo un modelo Clave-Valor. Cualquier secuencia binaria puede ser una clave (Key), pero se recomienda una longitud razonable y una nomenclatura coherente (ej. 'tipo-objeto:id:atributo') para mejorar la legibilidad y eficiencia. Los valores también tienen un límite de 512MB.

String

Es el tipo de dato fundamental. Redis trata todos los tipos primitivos como Strings. Soporta operaciones atómicas para operaciones aritméticas, lo que es útil en escenarios de alta concurrencia como el control de inventario o la generación de secuencias únicas.

• SET key value [EX seconds | PX milliseconds] [NX | XX]: Establece un valor para una clave con opciones de expiración y condicionales. O(1).
• GET key: Recupera el valor de una clave. O(1).
• INCR key: Incrementa el valor de una clave numérica en 1. O(1).
• DECRBY key increment: Decrementa el valor de una clave numérica. O(1).

Ejemplo: Control de Inventario

SET inventario:producto1 100
DECR inventario:producto1 

Si el valor devuelto por DECR es mayor o igual a 0, la operación es exitosa.

List

Representa una lista enlazada. Es ideal para implementar colas o pilas (colas de dos extremos). Operaciones en los extremos son eficientes (O(1)), mientras que las operaciones en el medio de la lista son costosas (O(N)).

• LPUSH key value [value ...]: Añade uno o más valores al principio de la lista. O(N) por elemento añadido.
• RPUSH key value [value ...]: Añade uno o más valores al final de la lista. O(N) por elemento añadido.
• LPOP key: Elimina y devuelve el primer elemento de la lista. O(1).
• RPOP key: Elimina y devuelve el último elemento de la lista. O(1).
• LRANGE key start stop: Devuelve un rango de eleemntos de la lista. O(N).

Se recomienda precaución con comandos como LINDEX, LSET y LINSERT debido a su complejidad O(N).

Hash

Permite almacenar pares campo-valor dentro de una clave. Es adecuado para representar objetos.

• HSET key field value: Establece un campo y su valor dentro de un hash. O(1).
• HGET key field: Obtiene el valor de un campo específico. O(1).
• HMSET key field value [field value ...]: Establece múltiples campos y valores. O(N).
• HGETALL key: Recupera todos los campos y valores de un hash. O(N).

Se desaconseja el uso de HGETALL, HKEYS y HVALS en hashes grandes; se prefiere HSCAN para iteración incremental.

Set

Colección de Strings no ordenados y sin duplicados. Útil para almacenar identificadores únicos.

• SADD key member [member ...]: Añade uno o más miembros a un set. O(N).
• SREM key member [member ...]: Elimina uno o más miembros. O(N).
• SCARD key: Devuelve el número de miembros. O(1).
• SISMEMBER key member: Comprueba si un miembro pertenece al set. O(1).

Comandos como SMEMBERS, SUNION, SINTER y SDIFF deben usarse con cuidado en sets grandes; SSCAN es la alternativa para la iteración.

Sorted Set

Colección de Strings ordenados por un "score" (puntuación). Ideal para rankings.

• ZADD key score member [score member ...]: Añade miembros con sus puntuaciones. O(M log N).
• ZRANGE key start stop [WITHSCORES]: Devuelve miembros en un rango de índices (ordenados por score ascendente). O(log N + M).
• ZRANGEBYSCORE key min max [WITHSCORES]: Devuelve miembros en un rango de scores. O(log N + M).
• ZCARD key: Devuelve el número de miembros. O(1).
• ZSCORE key member: Devuelve la puntuación de un miembro. O(1).

Similar a Set, se recomienda ZSCAN para iterar sobre Sorted Sets grandes en lugar de ZRANGE con rangos amplios.

Bitmap y HyperLogLog

• Bitmap: No es un tipo de dato propio, sino una forma de usar Strings como arrays de bits, muy eficiente para datos booleanos.
• HyperLogLog: Estructura para contar elementos únicos de forma aproximada y con muy bajo consumo de memoria.

Persistencia de Datos

Redis ofrece dos mecanismos principales para persistir datos en disco:

• RDB (Redis Database): Crea snapshots periódicos del dataset. Es rápido para la recuperación y tiene bajo impacto en el rendimiento, pero puede perder datos entre snapshots.
• AOF (Append Only File): Registra cada operación de escritura en un archivo de log. Ofrece mayor durabilidad (especialmente con appendfsync everysec) pero puede ser más lento y generar archivos más grandes.

Ambos mecanismos pueden ser utilizados simultáneamente. Se recomienda habilitar RDB incluso si solo se usa Redis como caché.

Gestión de Memoria y Políticas de Evicción

Es crucial configurar un límite máximo de memoria (maxmemory) para evitar que Redis consuma toda la RAM disponible y cause problemas de rendimiento o inestabilidad (swapping).

Cuando se alcanza el límite de memoria, Redis puede eliminar claves basándose en una política de evicción configurada (maxmemory-policy). Las políticas comunes incluyen:

• volatile-lru: Elimina la clave menos recientemente usada (LRU) entre las que tienen expiración.
• allkeys-lru: Elimina la clave LRU entre todas las claves.
• volatile-random: Elimina una clave aleatoria entre las que tienen expiración.
• allkeys-random: Elimina una clave aleatoria entre todas las claves.
• volatile-ttl: Elimina la clave con el menor tiempo de vida restante.
• noeviction (default): No elimina claves; las escrituras fallan.

Pipelining

Permite enviar múltiples comandos a Redis en una sola solicitud y recibir todas las respuestas juntas. Reduce la latencia al minimizar el número de viajes de ida y vuelta (RTT) de red. No es aplicable si un comando depende del resultado del anterior.

# Ejemplo conceptual de Pipelining
# Enviar PING, PING, PING
# Recibir 3x PONG
redis-cli --pipe <<- EOF
PING
PING
PING
EOF

Transacciones y Scripting (Lua)

Transacciones (MULTI/EXEC) garantizan que un grupo de comandos se ejecute de forma atómica y secuencial, sin interrupciones de otros clientes. Sin embargo, Redis no soporta rollback automático en caso de errores no sintácticos.

Scripting Lua (EVAL/EVALSHA) es la forma recomendada por Redis para ejecutar operaciones complejas de manera atómica y eficiente en el servidor. Ofrece mayor flexibilidad y rendimiento que las transacciones y puede reemplazar la necesidad de ellas.

WATCH junto con transacciones permite implementar mecanismos CAS (Check-And-Set) para control de concurrencia optimista.

Optimización de Rendimiento

Claves para optimizar Redis:

• Evitar comandos de larga duración (ej. KEYS, HGETALL en colecciones grandes). Usar SCAN, HSCAN, SSCAN, ZSCAN para iteraciones incrementales.
• Utilizar Pipelining para operaciones secuenciales.
• Desactivar Transparent Huge Pages en Linux.
• Minimizar la latencia de red usando conexiones persistentes (pools) y pipelining.
• Ajustar las políticas de persistencia (appendfsync, save) y la frecuencia de BGSAVE/BGREWRITEAOF para equilibrar durabilidad y rendimiento.
• Monitorear el tiempo de fork (latest_fork_usec en INFO).
• Evitar el swapping configurando adecuadamente maxmemory y asegurando suficiente RAM física.
• Distribuir las cargas de lectura mediante replicación master-slave.
• Utilizar el Slow Log para identificar comandos lentos.

Replicación Master-Slave y Clustering

Replicación Master-Slave

Permite crear copias de un servidor Redis (slaves) que replican datos de un servidor principal (master). Útil para:

• Escalabilidad de lectura: Desviar consultas de lectura a los slaves.
• Alta Disponibilidad (HA): Con Redis Sentinel, se puede detectar la caída del master y promover automáticamente un slave a master.

Configuración básica en el slave: slaveof <masterip> <masterport>.

Clustering (Redis Cluster)

Solución oficial para particionar datos (sharding) a través de múltiples nodos Redis. Maneja automáticamente la distribución de datos y el rebalanceo de slots (16384 hash slots por clave). Proporciona alta disponibilidad y escalabilidad horizontal, reemplazando la necesidad de Sentinel para failover interno de cada shard.

• Ventajas: Escalabilidad de datos y rendimiento, tolerancia a fallos distribuida.
• Desventajas: Mayor complejidad de gestión, limitaciones en transacciones y scripting (requieren que todas las claves estén en el mismo shard, manejable con hash tags).

La elección entre replicación master-slave y clustering depende de las necesidades específicas de escalabilidad de datos, carga de escritura y complejidad de gestión.

Selección de Clientes Java para Redis

Clientes populares incluyen Jedis (ligero, síncrono) y Redisson (basado en Netty, asíncrono, más características avanzadas como soporte nativo para cluster y replicación con balanceo de carga de lectura).

• Jedis: Sencillo, fácil de integrar, soporta pools, pipelining, transacciones, scripting, Sentinel y Cluster. Requiere implementación manual para lectura-escritura separada.
• Redisson: Alto rendimiento, soporte asíncrono, pipelining, scripting, Sentinel y Cluster. Soporta lectura-escritura separada nativamente. No soporta transacciones directamente (recomienda scripting Lua).

La elección debe basarse en los requisitos del proyecto, considerando la complejidad y las características avanzadas necesarias.