Redis AOF - Cuándo se puede desactivar sin comprometer el rendimiento

Redis es un potente almacén de datos en memoria. Su velocidad es vital, pero debido a su naturaleza "en memoria", hay un riesgo de que todos los datos se pierdan si el servidor se reinicia. Para prevenir esto, Redis ofrece dos opciones de persistencia.

1. RDB (Snapshotting): Toma una instantánea completa de los datos en un momento determinado y la guarda en el disco.

2. AOF (Append Only File): Registra secuencialmente todos los comandos de escritura en un archivo de registro.

AOF asegura una durabilidad casi nula en la pérdida de datos en comparación con RDB (generalmente dentro de un segundo). Sin embargo, registrar todas las operaciones de escritura en un archivo conlleva un costo de rendimiento considerable.

"¿Es realmente necesario AOF en todos los casos de uso de Redis?"

Para resumir, "no, en absoluto".

Hoy, vamos a distinguir claramente entre los casos en que no es necesario utilizar la configuración de AOF y, en contraste, aquellos casos donde AOF es esencial.

Casos en los que no es necesario usar AOF

El valor central de AOF radica en su durabilidad de datos. Si la durabilidad no es importante para los datos, AOF puede convertirse en una 'cadena' que solo causa una degradación innecesaria del rendimiento.

1. Cuando se usa solo como caché

Este es el caso más representativo.

• Razón: Los datos de la caché no son el 'original'. Existe una 'fuente de verdad' aparte, como una base de datos (DB) u otra API.

• En caso de pérdida de datos: Si Redis se reinicia y la caché se vacía, la aplicación se ralentiza momentáneamente (Cache Miss), pero puede volver a leer los datos originales para rellenar la caché (Cache-Warm up). No es una pérdida permanente de datos.

• Conclusión: Para usos de caché, a menudo se desactiva no solo AOF, sino incluso RDB. El objetivo es eliminar completamente el I/O del disco para maximizar la velocidad pura de Redis en memoria.

2. Cuando se usa como corredor de Celery / backend de resultados (tareas de baja importancia)

Redis se usa a menudo junto con Celery. En la configuración de AOF de Redis como corredor y backend de resultados de Celery, se plantea la premisa de 'importancia de las tareas'.

• Razón: Si una tarea manejada por Celery puede 'fallar' sin repercusiones o 'reintentarse fácilmente', AOF no es necesario.

• Ejemplos:

  • Análisis de registros de usuario (una pérdida de algunos segundos de registros no es un gran problema)

  • Depuración de datos periódica (se puede volver a ejecutar en el siguiente ciclo)

  • Generación de imágenes en miniatura (se puede regenerar ya que se dispone de la imagen original)

• Conclusión: En este tipo de escenarios, si el servidor Redis se cae, las tareas o resultados en la cola pueden desaparecer. Sin embargo, si este tipo de pérdida puede ser 'asumido' en términos de negocio, es prudente apagar AOF y asegurar el rendimiento del corredor.

3. Datos estadísticos simples y datos en tiempo real (volátiles)

Esto se aplica cuando se observan tendencias a corto plazo o se manejan datos que se actualizan rápidamente.

• Razón: Si los datos se actualizan en ciclos muy cortos, o si una instantánea en un momento determinado no tiene mucha relevancia.

• Ejemplos:

  • Número de visitantes al sitio web en el último minuto

  • Clasificación de juegos en tiempo real (cambios por segundo)

  • Datos de sesión temporales (expiran en minutos)

• Conclusión: Los datos desaparecerán o se actualizarán rápidamente de todos modos. En lugar de perder algunos segundos de datos, es mucho más importante procesar rápidamente la gran cantidad de solicitudes de escritura. AOF no es adecuado para este tipo de entorno.

Casos en los que se recomienda encarecidamente usar AOF

Por el contrario, en casos donde la pérdida de datos de Redis causa problemas graves, AOF es una obligación, no una opción.

1. Cola de mensajes 'fiables' (Tareas críticas de Celery)

Esto es exactamente lo contrario del ejemplo de Celery anterior.

• Razón: La tarea en sí está vinculada a dinero o lógica empresarial clave.

• Ejemplos:

  • Solicitudes de procesamiento de pagos

  • Envío de correos electrónicos de verificación tras la finalización del registro

  • Procesamiento de pedidos

• Conclusión: Si un usuario presiona el botón de 'pago' y Redis se reinicia, lo que resulta en la desaparición de esa solicitud de tarea, esto constituye un grave problema. En tales escenarios, AOF debe activarse con la opción fsync everysec (predeterminada) para garantizar que las tareas se registren en el disco tan pronto como ingresen a la cola.

2. Cuando se utiliza Redis como base de datos principal

Esto se aplica cuando Redis no se usa simplemente como caché, sino como fuente de verdad.

• Razón: Si no hay otra base de datos y Redis almacena los datos originales, la pérdida de datos significaría una pérdida permanente.

• Ejemplos:

  • Información del perfil del usuario

  • Sesiones de usuario que deben conservarse permanentemente

  • Información sobre recursos del juego (oro, objetos)

• Conclusión: En este caso, AOF es obligatorio, y debe utilizarse junto con las instantáneas RDB para establecer una estrategia de respaldo y recuperación.

3. Datos de transacciones y agregaciones

Esto es crucial cuando la consistencia y precisión de los datos son muy importantes.

• Razón: RDB solo guarda un 'momento específico', lo que significa que todos los datos después de la última instantánea se perderán. AOF guarda 'todo el historial de cambios', lo que minimiza la pérdida de datos (máximo 1 segundo).

• Ejemplos:

  • Relaciones de seguir/dejar de seguir

  • Cálculo preciso del número de votos

  • Datos relacionados con finanzas (historial simple de depósitos y retiros)

• Conclusión: En casos donde la consistencia final de los datos es crucial, la característica 'Append-Only' de AOF es mucho más adecuada que RDB.

Conclusión: Compromiso entre durabilidad y rendimiento

AOF es una poderosa función que proporciona durabilidad a Redis. Sin embargo, esta característica viene a expensas del rendimiento.

Si dudas en activar o no AOF, los desarrolladores deben responder a la siguiente pregunta.

"Si el servidor Redis se cayera ahora sin previo aviso, ¿sería un problema grave para nuestro servicio que los datos de los últimos minutos (RDB) o un segundo (AOF) se perdieran?"

• "No, podemos recalcular (cache) los datos." -> Desactiva AOF.

• "Sí, los detalles de pago se perderían." -> Activa AOF sin falta.

Como todos los decisiones técnicas, no hay una respuesta correcta. Es importante comprender con precisión las características y requisitos de los datos de tu servicio y elegir el compromiso adecuado.