Persistencia de Redis
- Primero, presenta el proceso de configuración y operación de RDB y AOF, así como los comandos relacionados para controlar la persistencia, como bgsave y bgrewriteaof.
- En segundo lugar, analizar, localizar y optimizar problemas de persistencia comunes.
- Finalmente, optimizaremos Redis para escenarios comunes de implementación de múltiples instancias en una sola máquina.
5.1 RDB
La persistencia de RDB es el proceso de generar una instantánea de los datos del proceso actual y guardarla en el disco duro. El proceso de activación de la persistencia de RDB se divide en activación manual y. disparo automático.
5.1.1 Mecanismo de activación
La activación manual corresponde a los comandos save y bgsave:
comando -save: bloquea el servidor Redis actual hasta que se complete el proceso RDB. completado. Esto puede causar que las instancias con mucha memoria se bloqueen durante largos períodos de tiempo y no se recomienda para entornos en línea. El registro de Redis correspondiente a la ejecución del comando guardar
es el siguiente:
* La base de datos se guarda en el disco
-comando bgsave: el proceso de Redis realiza una Operación de bifurcación para crear un proceso hijo Responsable del proceso de persistencia de RDB y finaliza automáticamente al finalizar. El bloqueo sólo se produce durante la fase de bifurcación, que suele ser muy corta. El registro de Redis correspondiente al comando bgsave es el siguiente:
* El guardado en segundo plano se inicia con el pid 3151
* La base de datos se guarda en el disco
* RDB : la copia en escritura utiliza 0 MB de memoria
* RDB: la copia en escritura utiliza 0 MB de memoria
* El guardado en segundo plano finaliza.
* El guardado en segundo plano finalizó exitosamente
Aparentemente, el comando bsave está optimizado para el problema de bloqueo de guardado. Por lo tanto, todas las operaciones que involucran RDB en Redis usan bgsave y el comando guardar ha quedado obsoleto.
Además de la activación manual mediante la ejecución de comandos, también existe un mecanismo de persistencia en Redis que activa automáticamente RDB, como los siguientes escenarios de aplicación:
1) Utilice configuraciones relacionadas con guardar , como "guardar m n". Esto significa que bgsave se activará automáticamente cuando el conjunto de datos tenga n modificaciones en m segundos.
2) Si el nodo esclavo realiza una operación de copia completa, el nodo maestro ejecutará automáticamente bgsave para generar un archivo RDB y lo enviará al nodo esclavo. Para obtener más información, consulte el principio de replicación descrito en. Sección 6.3.
3) Al ejecutar el comando debug reload para recargar Redis, la operación de guardar también se activará automáticamente.
4) De forma predeterminada, si la persistencia de AOF no está habilitada, bgsave se ejecutará automáticamente cuando se ejecute el comando de apagado.
5.1.2 Descripción del proceso
bgsave es la forma principal de activar la persistencia de RDB. Entendamos su principio de funcionamiento según la Figura 5-1.
1) Cuando se ejecuta el comando bgsave, el proceso principal de Redis determinará si hay un proceso secundario actualmente en ejecución, como un proceso secundario RDB/AOF. Si es así, regresará directamente a bgsave. dominio.
2) El proceso padre realiza una operación de bifurcación para crear un proceso hijo. Durante la operación de bifurcación, el proceso principal se bloqueará. Puede usar el comando info stats con la opción Latest_fork_usec para ver la última operación de bifurcación en microsegundos.
3) Después de que el proceso principal complete la bifurcación, el comando bgsave devolverá el mensaje "Se ha iniciado el guardado en segundo plano" y ya no bloqueará el proceso principal, por lo que el proceso principal puede continuar respondiendo a otros comandos. .
4) El proceso hijo crea un archivo RDB, genera un archivo de instantánea temporal basado en la memoria del proceso padre y luego reemplaza atómicamente el archivo original. Ejecute el comando lastsave para obtener la hora en que se generó por última vez el RDB, correspondiente a la opción rdb_last_save_time en las estadísticas de información.
5) El proceso envía una señal al proceso principal para indicar la finalización, y el proceso principal actualiza las estadísticas; consulte las opciones relacionadas con rdb_* en información Persistencia.
5.1.3 Procesamiento de archivos RDB
Guardar: los archivos RDB se guardan en el directorio especificado por la configuración del directorio y el nombre del archivo se especifica mediante la configuración del nombre del archivo db. Esto se puede hacer dinámicamente en tiempo de ejecución ejecutando config set dir{newDir} y config setdbfilename{newFileName} y el archivo RDB se guardará en el nuevo directorio la próxima vez que se ejecute.
Consejos de ejecución
Cuando encuentre daños en el disco o disco lleno, puede modificar la ruta del archivo a una ruta de disco disponible en línea a través de config set dir{newDir} y luego ejecutar bgsave Realizar disco conmutación, que también se aplica a los archivos persistentes AOF.
Compresión: De forma predeterminada, Redis utiliza el algoritmo LZF para comprimir los archivos RDB generados. El archivo comprimido es mucho más pequeño que el tamaño de la memoria. El tamaño de la memoria está habilitado de forma predeterminada y se puede modificar dinámicamente usando el conjunto de configuración de parámetros rdbcompression{yes|no}.
Consejos de funcionamiento
Aunque la compresión RDB consume CPU, puede reducir significativamente el tamaño del archivo y facilitar guardar el archivo en el disco duro o enviarlo al nodo esclavo a través del red, por lo que se recomienda usarlo en línea Ábrelo.
Verificación: si Redis se niega a iniciarse al cargar un archivo RDB corrupto e imprime el siguiente registro:
# Lectura corta o OOM cargando base de datos.
En En este punto, puede utilizar la herramienta redis -check-dump para detectar archivos RDB y obtener los informes de error correspondientes.
5.1.4 Ventajas y desventajas de RDB
Ventajas de RDB:
- RDB es un archivo binario compacto y comprimido que representa datos de Redis en un momento determinado Instantánea del punto. Muy adecuado para escenarios de aplicaciones como copia de seguridad y replicación completa. Por ejemplo, realice una copia de seguridad de bgsave cada 6 horas y copie los archivos RDB a una máquina o sistema de archivos remoto (como hdfs) para la recuperación ante desastres.
- Redis carga RDB para recuperar datos mucho más rápido que el método AOF.
Desventajas de RDB:
- La persistencia en tiempo real/segunda persistencia no es posible usando RDB. Debido a que bgsave debe realizar una operación de bifurcación para crear un proceso hijo cada vez que se ejecuta, esta es una operación pesada y demasiado costosa para realizarla con frecuencia.
: los archivos RDB se guardan en un formato binario específico y, con el desarrollo de las versiones de Redis, existen múltiples versiones de RDB, por lo que las versiones anteriores de los servicios de Redis no son compatibles con los formatos RDB más nuevos. Para resolver el problema de que RDB no es adecuado para la persistencia en tiempo real, Redis proporciona persistencia AOF para resolver este problema.
5.2 AOF
Persistencia de AOF (solo archivos adjuntos): la función principal de AOF es resolver el problema de la persistencia de datos en tiempo real, y siempre ha sido la persistencia principal. método de Redis. Comprender el mecanismo de persistencia de AOF nos resulta muy útil para equilibrar la seguridad y el rendimiento de los datos.
5.2.1 Uso de AOF
Para habilitar AOF, debe establecer la configuración: appendonly sí, que no está habilitada de forma predeterminada, el nombre del archivo AOF se establece a través de la configuración appendfilename; y el nombre de archivo predeterminado es appendonly.aof; guardar ruta Lo mismo que el método de persistencia RDB, especificado a través de la configuración del directorio. Operaciones de flujo de trabajo de AOF: escritura de comandos (añadir), sincronización de archivos (sincronización), reescritura de archivos (reescritura), reinicio de carga (cargar), como se muestra en la Figura 5-2.
1) Todos los comandos de escritura se adjuntan a aof_buf (búfer).
2) El búfer AOF realiza operaciones de sincronización en el disco duro de acuerdo con la política correspondiente.
3) A medida que los archivos AOF crecen, es necesario reescribirlos periódicamente para lograr la compresión.
4) Cuando se reinicia el servidor Redis, el archivo AOF se puede cargar para la recuperación de datos. Después de comprender el flujo de trabajo de AOF, cada paso se explica en detalle a continuación.
5.2.2 Escritura de comandos
El comando AOF escribe directamente en el formato de protocolo de texto. Por ejemplo, el comando set hello world agregará el siguiente texto al búfer AOF: *3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\ n
Para obtener una descripción detallada del formato del protocolo Redis, consulte la sección 4.1 Protocolo del cliente. No entraremos en detalles aquí. Lo explicaremos a continuación.
El comando AOF es. escrito en formato de protocolo de texto.
Presentamos dos dudas sobre AOF:
1) ¿Por qué AOF utiliza directamente el formato de protocolo de texto? Las posibles razones son las siguientes:
- El protocolo de texto tiene buena compatibilidad.
: después de abrir AOF, todos los comandos de escritura incluyen operaciones de adición, y las operaciones de adición utilizan directamente el formato de protocolo para evitar la sobrecarga del procesamiento secundario.
- Los protocolos de texto son legibles, fáciles de modificar y sencillos de procesar.
2) ¿Por qué AOF agrega comandos a aof_buf? Redis utiliza un único hilo para responder a los comandos. Si cada comando de escritura en el archivo AOF se agrega directamente al disco duro, el rendimiento dependerá completamente de la carga actual del disco duro. Escribir primero el búfer aof_buf tiene otro beneficio: Redis puede proporcionar múltiples estrategias para sincronizar el búfer con el disco duro para lograr un equilibrio entre rendimiento y seguridad.
5.2.3 Sincronización de archivos
Redis proporciona múltiples estrategias de archivos de sincronización de búfer AOF, que están controladas por el parámetro appendfsync. Los significados de diferentes valores se muestran en la Tabla 5-1. .
Tabla 5-1 Política de archivos de sincronización del buffer AOF
Descripción de las llamadas al sistema write y fsync:
- Las operaciones de escritura activarán el mecanismo de escritura retrasada. Linux proporciona un búfer de páginas en el kernel para mejorar el rendimiento de E/S del disco duro. La sincronización de las operaciones del disco duro depende de los mecanismos de programación del sistema, como que el espacio de la página del búfer esté lleno o alcance un período de tiempo específico. Si el sistema falla en este momento, los datos del búfer se perderán antes de que se sincronicen los archivos.
-fsync fuerza la sincronización del disco duro para operaciones de un solo archivo (como archivos AOF). fsync se bloquea hasta que se completa la escritura en el disco y luego regresa para garantizar la durabilidad de los datos. Además de escribir y fsync, Linux también proporciona operaciones de sincronización y fdatasync. Consulte la descripción de la API específica
Ver: Completo, esto puede reducir la velocidad de ejecución de Redis
2) Siempre que ocurra un evento de bloqueo adicional de AOF, se acumulará el indicador aof_delayed_fsync en las estadísticas de persistencia de información. Al ver este indicador, puede descubrir fácilmente el problema de bloqueo de AOF.
3) La sincronización AOF permite hasta 2 segundos de retraso. Cuando se produce el retraso, se producirán problemas de carga alta en el disco duro. Puede utilizar herramientas de monitoreo como iotop para localizar procesos que consumen IO del disco duro. recursos. La optimización del problema de bloqueo adicional de AOF es principalmente para optimizar la carga del disco duro del sistema. El método de optimización se presentó en la sección anterior.
5.4 Implementación de múltiples instancias
La arquitectura de un solo subproceso de Redis le impide hacer un uso completo de las características de múltiples núcleos de la CPU. La práctica común es implementar múltiples Redis. instancias en una máquina. Cuando varias instancias permiten la reescritura de AOF, compiten entre sí por CPU e IO. Esta sección se centrará en analizar y optimizar esta situación. La sección anterior presentó la sobrecarga del subproceso asociada con la persistencia. Para la implementación de múltiples Redis en una sola máquina, si se ejecutan varios procesos secundarios al mismo tiempo, el impacto en el sistema actual será muy obvio, por lo que debemos tomar medidas para aislar el trabajo de los procesos secundarios. Redis nos proporciona indicadores para monitorear el estado de ejecución de procesos secundarios en info Persistence, como se muestra en la Tabla 5-2.
Según los indicadores anteriores, podemos controlar la ejecución de la operación de reescritura de AOF a través del sondeo del programa externo. Todo el proceso se muestra en la Figura 5-6.
Descripción del proceso:
1) El programa externo sondea y monitorea periódicamente todas las instancias de Redis en la máquina.
2) Para instancias con AOF activado, mire (aof_current_size - aof_base_size)/aof_base_size para confirmar la tasa de crecimiento.
3) Cuando la tasa de crecimiento excede un umbral específico (por ejemplo, 100%), ejecute el comando bgrewriteaof para activar manualmente la reescritura AOF de la instancia actual.
4) Verifique los indicadores aof_rewrite_in_progress y aof_current_rewrite_time_sec en un bucle durante el proceso de ejecución hasta que se complete la reescritura de AOF.
5) Después de confirmar que la reescritura de la instancia AOF está completa, verifique otras instancias y repita los pasos 2) a 4). Esto garantizará que las reescrituras de AOF se realicen en serie para cada instancia de Redis en la máquina.
5.5 Revisión clave de este capítulo
1) Redis proporciona dos tipos de persistencia:
2) RDB utiliza un método de instantánea de memoria única para generar archivos Proporciona una mayor compacidad y relación de compresión, lo que resulta en tiempos de recuperación más rápidos para leer RDB. Debido a la gran sobrecarga de generar RDB cada vez, no se puede lograr la persistencia en tiempo real y generalmente se usa para el almacenamiento en frío de datos y la transmisión de copias.
3) El comando save bloqueará el hilo principal y no se recomienda. El comando bsave crea un subproceso para generar RDB a través de la operación fork para evitar el bloqueo.
4) AOF logra persistencia agregando comandos de escritura al archivo. Puede usar el parámetro appendfsync para controlar la persistencia en tiempo real/de segundo nivel. El tamaño del archivo AOF crece gradualmente debido a la necesidad de agregar constantemente comandos de escritura, por lo que es necesario realizar operaciones de reescritura periódicas para reducir el tamaño del archivo.
5) Puede activar automáticamente la reescritura de AOF controlando los parámetros auto-aof-rewrite-min-size y auto-aof-rewrite-percentage, o activar manualmente la reescritura de AOF usando el comando bgrewriteaof.
6) Utilice el mecanismo de copia en escritura para compartir memoria con el proceso principal para evitar duplicar el consumo de memoria durante la ejecución del proceso secundario y mantenga un búfer de reescritura durante la reescritura de AOF para guardar nuevas escrituras. el comando para evitar la pérdida de datos.
7) Escenario de hilo principal de bloqueo de persistencia: bloqueo de bifurcación y bloqueo de anexos AOF. El tiempo de bloqueo de la bifurcación está relacionado con la cantidad de memoria y el bloqueo de anexos de AOF significa que los recursos del disco duro son escasos.
8) Al implementar varias instancias en una máquina, para evitar que varios procesos secundarios realicen operaciones de reescritura, se recomienda implementar un control de aislamiento para evitar la competencia por los recursos de CPU y IO.