Las 5 principales cuellos de botella de rendimiento en Redis y cómo solucionarlos

Los problemas de rendimiento de Redis suelen parecer misteriosos hasta que recuerdas una cosa: Redis es rápido, pero no está exento de trabajo. Un comando que recorre un millón de claves sigue recorriendo un millón de claves. Un cliente que envía un comando por viaje de ida y vuelta en la red sigue pagando por cada viaje. Un servidor que se queda sin memoria aún tiene que desalojar, intercambiar, rechazar escrituras o fallar según la configuración.

Cuando Redis se ralentiza, no empieces cambiando ajustes al azar. Empieza con evidencia:

redis-cli INFO
redis-cli SLOWLOG GET 20
redis-cli LATENCY DOCTOR
redis-cli INFO commandstats
redis-cli INFO memory

Esos comandos suelen apuntar a uno de cinco cuellos de botella: comandos lentos, viajes de ida y vuelta en la red, presión de memoria, sobrecarga de persistencia o saturación de CPU.

1. Comandos lentos en datos grandes

Redis tiene muchas operaciones diminutas de tiempo constante, pero no todos los comandos son diminutos. Comandos como KEYS, LRANGE grande, SMEMBERS, HGETALL, ZRANGE sobre rangos enormes, SORT y scripts Lua largos pueden bloquear a otros clientes mientras se ejecutan.

El incidente clásico comienza con un comando de limpieza o depuración:

KEYS *

En una instancia de desarrollo pequeña, regresa de inmediato. En un espacio de claves de producción con millones de claves, puede detener el servidor el tiempo suficiente para que las solicitudes de la aplicación se acumulen. El mismo patrón ocurre con un hash que comenzó como "unos pocos campos por usuario" y silenciosamente se convirtió en un objeto gigante.

Encuentra la evidencia:

redis-cli SLOWLOG GET 20
redis-cli INFO commandstats
redis-cli LATENCY LATEST

SLOWLOG registra los comandos que superaron el umbral configurado. INFO commandstats muestra los recuentos de llamadas por comando y el tiempo acumulado. Si un comando domina el tiempo, empieza por ahí.

Arregla el patrón de acceso:

redis-cli --scan --pattern 'user:*'

Usa SCAN en lugar de KEYS para la iteración del espacio de claves. Usa HSCAN, SSCAN y ZSCAN para hashes, conjuntos y conjuntos ordenados grandes. Obtén páginas o rangos en lugar de estructuras completas:

LRANGE feed:user:42 0 49
ZRANGE leaderboard 0 99 WITHSCORES

Si un objeto ha crecido demasiado, divídelo según cómo lo lee la aplicación. Un solo hash user:42 con miles de campos no relacionados puede ser conveniente para escrituras, pero doloroso para lecturas que solo necesitan configuraciones de perfil. Claves separadas como user:42:profile, user:42:prefs y user:42:counters pueden reducir la cantidad de datos tocados por solicitud.

Para la eliminación, prefiere UNLINK cuando los valores puedan ser grandes:

UNLINK old:large:set

UNLINK elimina la clave del espacio de claves y libera memoria de forma asíncrona. Es más seguro que DEL para valores grandes, aunque la limpieza masiva aún necesita limitación.

2. Demasiados viajes de ida y vuelta en la red

Redis puede procesar un comando en microsegundos mientras tu aplicación pasa milisegundos esperando en la red. Si una ruta de solicitud envía 50 comandos secuenciales de Redis, la red puede dominar el tiempo total incluso cuando Redis está sano.

Esto es común en código como:

for user_id in user_ids:
    profile = redis.get(f"user:{user_id}:profile")

Cada GET espera su propia respuesta antes de que comience la siguiente. A través de una red, eso es costoso.

Usa pipelining:

pipe = redis.pipeline(transaction=False)
for user_id in user_ids:
    pipe.get(f"user:{user_id}:profile")
profiles = pipe.execute()

El pipelining envía múltiples comandos sin esperar cada respuesta individualmente. Redis aún ejecuta los comandos en orden, pero el cliente evita pagar un viaje de ida y vuelta por cada comando.

Usa comandos de múltiples claves donde encajen:

MGET user:1:profile user:2:profile user:3:profile

No conviertas cada solicitud en una tubería enorme. Las tuberías grandes pueden aumentar el uso de memoria y crear ráfagas de respuesta. Agrupa lo suficiente para eliminar el desperdicio obvio de viajes de ida y vuelta, luego mide.

Para rutas con muchas lecturas, también verifica si tu aplicación le pide repetidamente a Redis valores que podrían obtenerse una vez y reutilizarse durante la duración de una solicitud. Una pequeña caché de solicitudes local puede eliminar lecturas duplicadas accidentales sin cambiar Redis en absoluto.

3. Presión de memoria y desalojo constante

Redis está centrado en la memoria. Una vez que la memoria está ajustada, el rendimiento empeora de varias maneras: el desalojo consume CPU, las escrituras pueden fallar bajo noeviction, las bifurcaciones de persistencia pueden volverse más difíciles, las réplicas pueden retrasarse, y el sistema operativo puede intercambiar si el host está mal configurado o sobrecargado.

Verifica la memoria:

redis-cli INFO memory
redis-cli INFO stats | grep evicted_keys
redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policy

Señales importantes:

used_memory está cerca de maxmemory.
evicted_keys está aumentando rápidamente.
El host está intercambiando.
Las claves grandes consumen más memoria de lo esperado.
Las claves de caché que expiran no tienen realmente TTL.

Encuentra claves grandes con cuidado. No ejecutes comandos amplios y costosos durante el tráfico pico. Muestrear con --bigkeys puede ayudar:

redis-cli --bigkeys

Para cachés, establece un límite de memoria y una política de desalojo que coincida con los datos:

maxmemory 4gb
maxmemory-policy allkeys-lru

allkeys-lru o allkeys-lfu pueden tener sentido cuando todas las claves son entradas de caché. volatile-lru solo desaloja claves con TTL, lo cual es útil cuando las claves persistentes comparten la instancia con las claves de caché. noeviction suele ser correcto para Redis utilizado como almacén de datos principal, porque desalojar silenciosamente datos de apariencia duradera sería peor que devolver un error.

Establece TTL en el momento de la escritura:

SET cache:product:123 "$json" EX 300

Para almacenes de sesiones, sé deliberado. Una clave de sesión sin vencimiento suele ser un error. Para limitadores de velocidad, los contadores deben expirar con la ventana. Para Streams, recorta entradas antiguas. Las fugas de memoria en Redis suelen ser datos de aplicación que nunca recibieron un ciclo de vida.

También reduce la sobrecarga de claves y valores donde sea importante. Miles de claves diminutas pueden costar más metadatos de lo esperado. A veces un hash compacto es mejor que muchas claves individuales; a veces lo contrario es cierto porque las lecturas solo necesitan un campo. Mide con patrones de acceso reales en lugar de asumir que una forma siempre es la mejor.

4. Persistencia y paradas de E/S de disco

La persistencia protege los datos, pero introduce comportamiento de bifurcación y disco que debes entender. Las instantáneas RDB y las reescrituras AOF son normalmente operaciones en segundo plano, pero aún pueden causar latencia a través del tiempo de bifurcación, la presión de memoria de copia en escritura y la E/S de disco.

Verifica el estado de persistencia:

redis-cli INFO persistence
redis-cli LATENCY LATEST
iostat -xz 1

Busca guardados en segundo plano fallidos, tiempos de bifurcación largos, actividad de reescritura AOF y saturación de disco. Si los picos de latencia coinciden con BGSAVE o BGREWRITEAOF, la sintonización de persistencia pertenece a la lista de prioridades.

Para AOF, la configuración principal de durabilidad/rendimiento es:

appendfsync everysec

everysec es la elección equilibrada habitual. always sincroniza cada escritura y puede ser muy lento. no deja la sincronización al sistema operativo y acepta más riesgo de pérdida de datos en caso de fallo.

Para RDB, evita reglas de instantánea que se activen constantemente en una carga de trabajo de escritura ocupada a menos que sea intencional:

save 900 1
save 300 10
save 60 10000

Esos valores predeterminados de ejemplo no son automáticamente correctos para cada carga de trabajo. Una instancia de Redis de alta escritura utilizada como caché desechable puede no necesitar persistencia en absoluto. Una instancia de Redis utilizada como cola de trabajos o almacén de sesiones probablemente sí, pero la ventana de pérdida aceptable debe ser clara.

Si la persistencia compite con el tráfico de la aplicación, considera:

Almacenamiento SSD local más rápido.
Separar la persistencia de Redis de otros servicios con uso intensivo de disco.
Ejecutar la persistencia en una réplica cuando el primario pueda tolerar ese diseño.
Mantener el tamaño del conjunto de datos por debajo de lo que el host puede bifurcar cómodamente.
Configurar Linux vm.overcommit_memory=1 donde Redis lo recomienda para guardados en segundo plano.

No desactives la persistencia a ciegas para "arreglar el rendimiento" a menos que los datos sean realmente desechables. Puede hacer que el gráfico se vea mejor mientras convierte un reinicio en pérdida de datos.

5. Saturación de CPU y ejecución de comandos de un solo hilo

La ejecución de comandos de Redis es en gran medida de un solo hilo, aunque Redis moderno usa hilos adicionales para algunas E/S y trabajo en segundo plano. Si un núcleo está saturado por Redis, agregar más núcleos inactivos en la misma instancia puede no ayudar a la ruta de comandos activa.

Verifica el host y la combinación de comandos de Redis:

top -H -p $(pgrep redis-server)
redis-cli INFO commandstats
redis-cli SLOWLOG GET 20
redis-cli INFO clients

Causas comunes de CPU:

Operaciones grandes en conjuntos, conjuntos ordenados, listas o hashes.
Scripts Lua pesados.
Sobrecarga de compresión o serialización en la aplicación que causa valores más grandes de lo esperado.
Fan-out muy alto de Pub/Sub.
Desalojo costoso bajo presión de memoria.
Demasiadas conexiones reconectándose constantemente o emitiendo comandos pequeños.

Arregla la CPU reduciendo el trabajo, dividiendo el trabajo o distribuyendo el trabajo.

Reduce el trabajo cambiando comandos y formas de datos. Si solo necesitas 50 elementos, no obtengas 5,000. Si cada solicitud analiza un blob JSON de 500 KB para leer una bandera, divide esa bandera en una clave o campo más pequeño.

Divide el trabajo moviendo bucles largos a clientes usando escaneos incrementales:

HSCAN big:hash 0 COUNT 100

Distribuye el trabajo con réplicas para lecturas o Redis Cluster para fragmentación. Las réplicas ayudan con el tráfico intensivo en lecturas, pero no hacen que las escrituras sean más baratas en el primario. Redis Cluster distribuye las claves entre los primarios, lo que puede aumentar la capacidad total de CPU y memoria, pero también agrega complejidad operativa y restricciones de ranuras de claves.

Para Pub/Sub, observa los búferes de salida y el fan-out:

redis-cli PUBSUB NUMSUB events:updates
redis-cli CLIENT LIST

Un suscriptor lento puede convertirse en presión de memoria. Miles de suscriptores pueden convertir una publicación en una gran cantidad de salida de red. Si Pub/Sub es pesado, considera aislarlo en una instancia separada de Redis.

Un flujo de trabajo de triaje rápido

Cuando la latencia de Redis aumenta, ejecuta estas comprobaciones en orden:

redis-cli --latency
redis-cli SLOWLOG GET 10
redis-cli LATENCY DOCTOR
redis-cli INFO memory
redis-cli INFO clients
redis-cli INFO persistence
redis-cli INFO commandstats

Luego pregúntate:

¿Apareció un comando lento?
¿La memoria alcanzó maxmemory o comenzó a desalojar?
¿La persistencia inició un guardado o reescritura?
¿Los clientes conectados o bloqueados saltaron?
¿El recuento de llamadas o el tiempo de un comando explotó?
¿Los despliegues de la aplicación cambiaron los patrones de acceso a Redis?

La mayoría de los cuellos de botella de Redis no se resuelven con una configuración mágica. Se resuelven haciendo que la carga de trabajo sea más pequeña, más incremental, más por lotes o mejor aislada. Las mejores implementaciones de Redis son aburridas: las claves expiran cuando deben, las operaciones grandes se paginan, los clientes utilizan pipelining sabiamente, la configuración de persistencia coincide con el valor de los datos, y la monitorización detecta la tendencia antes de que los usuarios la sientan.

Qué medir antes y después de una solución

Una solución de rendimiento solo es real si el gráfico cambia para la carga de trabajo que importa. Antes de cambiar código o configuración, captura una línea base pequeña:

redis-cli INFO stats
redis-cli INFO commandstats
redis-cli INFO memory
redis-cli INFO persistence
redis-cli SLOWLOG GET 20

A nivel del sistema, captura CPU, disco, memoria, intercambio y rendimiento de red. Si Redis se ejecuta en un contenedor, verifica tanto los límites del contenedor como la presión del host. Un proceso de Redis puede verse bien dentro de su propia vista de memoria mientras el host está bajo presión de disco o CPU de otro servicio.

Después del cambio, compara:

Latencia p50, p95 y p99 de la aplicación para solicitudes respaldadas por Redis.
Latencia de comandos de Redis, no solo latencia de solicitudes.
Entradas de Slowlog por comando.
Tasa de desalojo y margen de memoria.
Clientes conectados y conexiones rechazadas.
Tiempo de bifurcación de persistencia y estado de AOF/RDB.
Retraso de réplica si las réplicas sirven lecturas o protegen la durabilidad.

Desconfía de las soluciones que solo mueven el dolor. Por ejemplo, una tubería grande puede reducir la latencia de solicitud pero aumentar los picos de memoria. Deshabilitar AOF puede eliminar la latencia de disco pero debilitar la recuperación. Aumentar maxmemory puede retrasar los desalojos pero agotar el host si la máquina ya estaba compartida.

Una práctica útil es escribir una pequeña prueba de carga alrededor del patrón exacto de Redis que cambiaste. Si el código antiguo hacía 40 GETs secuenciales, prueba GETs secuenciales versus MGET o pipelining con tamaños de carga realistas. Si el código antiguo usaba HGETALL, prueba HGET para los campos realmente necesarios por la solicitud. La sintonización de Redis es mucho más fácil cuando comparas la forma que realmente ejecutas, no un número genérico de "operaciones de Redis por segundo".

Finalmente, mantén la reversión simple. Un cambio de rendimiento de Redis a menudo se encuentra en el código de la aplicación, la configuración del cliente y la configuración del servidor al mismo tiempo. Cambia una cosa cuando puedas. Si debes cambiar varias cosas, anota qué síntoma se supone que mejora cada cambio. Eso evita que el próximo ingeniero herede un montón de configuraciones misteriosas que nadie quiere eliminar.