Tabla de contenido
2.1 Cómo activar una instantánea
Los parámetros de configuración se ejecutan regularmente
2.2 Proceso de ejecución de RDB (principio)
2.3 estructura de archivos RDB
2.4 Ventajas y desventajas de RDB
3.1 Implementación de persistencia AOF
3.2.3 Escritura y guardado de archivos
3.4 reescritura AOF, modo de disparo, persistencia híbrida
3.4.4 Carga y restauración de datos de archivos AOF
Persistencia de Redis
1. Por qué persistir
Redis es una base de datos en memoria y los datos desaparecerán después de un tiempo de inactividad. El acceso afectará a la base de datos, lo que provocará una avalancha de almacenamiento en caché (una gran cantidad de claves). Una vez que
Redis se reinicia, los datos se pueden restaurar rápidamente. Para proporcionar un mecanismo de persistencia, la
persistencia de Redis es restaurar rápidamente los datos en lugar de almacenarlos.
Redis tiene dos métodos de persistencia: RDB y AOF.
Nota: La persistencia de Redis no garantiza la integridad de los datos.
Cuando Redis se usa como una base de datos, los datos de la base de datos deben estar completos, por lo que debe haber una fuente de datos completa (archivo, mysql)
cuando se inicia el sistema, y los datos de esta fuente de datos completa se cargan en Redis. La
cantidad de datos es un cambio pequeño y no fácil, como: biblioteca de diccionarios (xml, tabla)
Puede ver información sobre la persistencia a través del comando info
# Persistencia
de carga: 0
rdb_changes_since_last_save: 1
rdb_bgsave_in_progress: 0
rdb_last_save_time: 1589363051
rdb_last_bgsave_status: ok
rdb_last_bgsave_time_sec: -1
rdb_current_bgsave_time_sec: -1
rdb_last_cow_size: 0
aof_enabled: 1
aof_rewrite_in_progress: 0
aof_rewrite_scheduled: 0
aof_last_rewrite_time_sec: -1
aof_current_rewrite_time_sec: -1
aof_last_bgrewrite_status: ok
aof_last_write_status: ok
aof_last_cow_size: 0
aof_current_size: 58
aof_base_size: 0
aof_pending_rewrite: 0
aof_buffer_length: 0
aof_rewrite_buffer_length: 0
aof_pending_bio_fsync: 0
aof_delayed_fsync: 0
2 RDB
RDB (Redis DataBase) es el método de almacenamiento predeterminado de redis, y el método RDB se completa mediante instantáneas .
Los datos en este momento
no prestan atención al proceso
2.1 Cómo activar una instantánea
1. Cumpla con las reglas de instantáneas de la configuración personalizada
2. Ejecute el comando save o bgsave
3. Ejecute el comando fluxhall
4. Ejecute la operación de copia maestro-esclavo (primera vez)
Los parámetros de configuración se ejecutan regularmente
Configurar en redis.conf: guardar <seconds> <changes> ¿Cuántos segundos han cambiado los datos?
save "" # 不使用RDB存储 不能主从
save 900 1 # 表示15分钟（900秒钟）内至少1个键被更改则进行快照。
save 300 10 # 表示5分钟（300秒）内至少10个键被更改则进行快照。
save 60 10000 # 表示1分钟内至少10000个键被更改则进行快照。El diseño del embudo proporciona rendimiento
Comando disparador explícito
Ingrese el comando bgsave en el cliente.
127.0.0.1:6379> bgsave
Background saving started
2.2 Proceso de ejecución de RDB (principio)
1. El proceso padre de Redis primero juzga si está actualmente ejecutando guardar, o el proceso hijo de bgsave / bgrewriteaof (comando de reescritura de archivo aof), si se está ejecutando, el comando bgsave regresa directamente.
2. El proceso principal ejecuta la operación fork (llamando a la función del SO para copiar el proceso principal) para crear un proceso secundario. Durante este proceso de copia, el proceso principal se bloquea y Redis no puede ejecutar ningún comando del cliente.
3. Una vez que el proceso principal se bifurca, el comando bgsave devuelve el mensaje "Se inició el guardado en segundo plano" y ya no bloquea el proceso principal y puede responder a otros comandos.
4. El proceso secundario crea un archivo RDB, genera un archivo de instantánea temporal basado en la instantánea de la memoria del proceso principal y reemplaza atómicamente el archivo original una vez completado. (RDB siempre está completo)
5. El proceso hijo envía una señal al proceso padre para indicar la finalización y el proceso padre actualiza las estadísticas.
6. Después de que el proceso padre bifurca el proceso hijo, continúe trabajando.
2.3 estructura de archivos RDB
1. Los 5 bytes del encabezado se fijan como la cadena
2 de "REDIS" y el número de versión de "RDB" de 4 bytes (no el número de versión de Redis), actualmente 9, y 0009 después del llenado.
3. Campo auxiliar, en la forma de clave-valor
4. Almacene el número de la base de datos
5. El tamaño del diccionario
6. La clave caducada
7. Los datos principales se almacenan en forma de clave-valor
8. La marca final
9. La suma de verificación es para ver si el archivo está dañado o modificado.
Puede abrir el archivo dump.rdb con winhex para verlo.
2.4 Ventajas y desventajas de RDB
Ventajas
RDB es un archivo binario comprimido, que ocupa un espacio pequeño y es conveniente para la transmisión (para esclavos). El
proceso principal bifurca el proceso hijo. Puede maximizar el rendimiento de Redis. El proceso principal no puede ser demasiado grande, la cantidad de Redis los datos no pueden ser demasiado grandes y el proceso principal se bloquea durante la copia
Desventajas
La integridad de los datos no está garantizada y todos los datos cambiados desde la última instantánea se perderán
3 AOF
AOF (adjuntar solo archivo) es otro método de persistencia de Redis. Redis no está activado de forma predeterminada. Después de habilitar la persistencia AOF
Redis registra todos los comandos (y sus parámetros ) (RESP) que se han escrito en la base de datos en el archivo AOF para lograr el propósito de registrar el estado de la base de datos.
De esta manera, cuando se reinicia Redis, siempre que estos comandos se reproduzcan en orden, se restaurará al estado original.
AOF registrará el proceso, RDB solo se preocupa por el resultado
3.1 Implementación de persistencia AOF
Configurar redis.conf
# 可以通过修改redis.conf配置文件中的appendonly参数开启
appendonly yes
# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的。
dir ./
# 默认的文件名是appendonly.aof，可以通过appendfilename参数修改
appendfilename appendonly.aof
3.2 Principio AOF
El archivo AOF almacena comandos redis. El proceso completo de sincronización de comandos con archivos AOF se puede dividir en tres etapas:
Propagación de comandos: Redis envía los comandos ejecutados, los parámetros de los comandos y el número de parámetros de los comandos al programa AOF.
Adición de caché: el programa AOF convierte el comando al formato del protocolo de comunicación de red de acuerdo con los datos de comando recibidos, y luego agrega el contenido del protocolo al caché AOF del servidor.
Escritura y guardado de archivos: el contenido de la caché AOF se escribe al final del archivo AOF. Si se cumple la condición de guardado AOF establecida, se llamará a la función fsync o fdatasync para guardar realmente el contenido escrito en el disco.
3.2.1 Propagación de comandos
Cuando un cliente de Redis necesita ejecutar un comando, envía el texto del protocolo al servidor de Redis a través de una conexión de red. Una vez que el servidor recibe la solicitud del cliente, seleccionará la función de comando adecuada de acuerdo con el contenido del texto del protocolo y convertirá cada parámetro del texto de cadena al objeto de cadena de Redis (StringObject). Siempre que la función de comando se ejecute con éxito, los parámetros de comando se propagarán al programa AOF.
3.2.2 Anexar caché
Una vez que el comando se propaga al programa AOF, el programa convertirá el comando del objeto de cadena de nuevo al texto del protocolo original de acuerdo con el comando y sus parámetros. Una vez generado el texto del protocolo, se agregará al final de aof_buf en la estructura redis.h / redisServer.
La estructura de redisServer mantiene el estado del servidor de Redis, y el campo aof_buf contiene todo el texto del protocolo (RESP) en espera de ser escrito en el archivo AOF.
3.2.3 Escritura y guardado de archivos
Siempre que se ejecute la función de tarea de rutina del servidor o se ejecute el controlador de eventos, se llamará a la función aof.c / flushAppendOnlyFile. Esta función realiza las dos tareas siguientes:
WRITE: De acuerdo con las condiciones, escribe el búfer en aof_buf en el archivo AOF .
GUARDAR: De acuerdo con las condiciones, llame a la función del sistema operativo de fsync o fdatasync para guardar el archivo AOF en el disco.
3.3 Modo de ahorro AOF
Actualmente, Redis admite tres modos de ahorro AOF, que son:
AOF_FSYNC_NO: No guardar.
AOF_FSYNC_EVERYSEC: guardar una vez por segundo. (defecto)
AOF_FSYNC_ALWAYS: Guardar cada vez que se ejecuta un comando. (No recomendado)
Las siguientes tres subsecciones discutirán estos tres modos de ahorro respectivamente.
No guardar
En este modo, se ejecutará WRITE cada vez que se llame a la función flushAppendOnlyFile, pero se omitirá GUARDAR.
SAVE solo se ejecutará en cualquiera de las siguientes situaciones:
Redis está cerrado
La función AOF está desactivada
La caché de escritura del sistema se actualiza (tal vez la caché esté llena o se ejecute la operación de guardado normal)
La operación SAVE en estos tres casos hará que se bloquee el proceso principal de Redis.
Guardar cada segundo (recomendado)
En este modo, SAVE se ejecutará cada segundo en principio, porque la operación SAVE es llamada por un subproceso secundario en segundo plano (fork), por lo que no provocará el bloqueo del proceso del servidor principal.
Guardar cada vez que se ejecuta un comando
En este modo, después de ejecutar cada comando, se ejecutarán WRITE y SAVE.
Además, debido a que SAVE es ejecutado por el proceso principal de Redis, el proceso principal se bloqueará durante la ejecución de SAVE y no puede aceptar solicitudes de comando.
El impacto del modo de ahorro AOF en el rendimiento y la seguridad
Para los tres modos de ahorro AOF, su bloqueo del proceso del servidor principal es el siguiente:
3.4 reescritura AOF, modo de disparo, persistencia híbrida
El proceso de cambio de los datos registrados AOF es cada vez más grande, y es necesario reescribirlo a "delgado"
Redis puede reescribir automáticamente AOF en segundo plano (subproceso Fork) cuando el volumen AOF se vuelve demasiado grande. El nuevo archivo AOF reescrito contiene el conjunto mínimo de comandos necesarios para restaurar el conjunto de datos actual. La llamada "reescritura" es en realidad un término ambiguo. De hecho, la reescritura AOF no requiere ninguna escritura o lectura del archivo AOF original, sino que tiene como objetivo el valor actual de la clave en la base de datos.
Un ejemplo es el siguiente:
set s1 11
set s1 22 -------> set s1 33
set s1 33
Sin optimización:
ajuste s1 11
ajuste s1 22
ajuste s1 33
Después de la optimización:
ajuste s1 33
lpush list1 1 2 3
lpush list1 4 5 6 --------> list1 1 2 3 4 5 6
Después de la optimización,
lpush list1 1 2 3 4 5 6
Redis no quiere que la reescritura de AOF haga que el servidor no pueda procesar la solicitud, por lo que Redis decidió poner el programa de reescritura de AOF en el subproceso (en segundo plano) para su ejecución. La mayor ventaja de este procesamiento es:
1. Durante la reescritura AOF del proceso hijo, el proceso principal puede continuar procesando solicitudes de comando.
2. El proceso hijo tiene una copia de los datos del proceso principal y se utiliza el proceso hijo en lugar del hilo para garantizar la seguridad de los datos y evitar bloqueos.
Sin embargo, hay un problema que debe resolverse cuando se usa un subproceso: debido a que el subproceso está realizando una reescritura AOF, el proceso principal aún necesita continuar procesando comandos, y los nuevos comandos pueden modificar los datos existentes, lo que hará que los datos de la base de datos actual y Los datos en el archivo AOF reescrito son inconsistentes.
Para resolver este problema, Redis ha agregado un caché de reescritura AOF. Este caché se habilita después de que se bifurca el proceso secundario. Después de recibir un nuevo comando de escritura, el proceso principal de Redis agregará el contenido del protocolo del comando de escritura a la entrada existente. Además del archivo AOF, también se agregará a esta caché.
3.4.1 Análisis del proceso de reescritura (toda la operación de reescritura es absolutamente segura):
En el proceso de creación de un nuevo archivo AOF, Redis continuará agregando comandos al archivo AOF existente. Incluso si se apaga durante el proceso de reescritura, el archivo AOF existente no se perderá. Una vez que se crea el nuevo archivo AOF, Redis cambiará del antiguo archivo AOF al nuevo archivo AOF y comenzará a agregar el nuevo archivo AOF.
Cuando el proceso hijo está realizando una reescritura AOF, el proceso principal debe realizar las siguientes tres tareas:
Procese la solicitud de comando.
Agregue el comando de escritura al archivo AOF existente.
Agregue el comando de escritura a la caché de reescritura de AOF.
De esta forma puedes garantizar:
La función AOF existente continuará ejecutándose, incluso si hay un tiempo de inactividad durante la reescritura de AOF, no habrá pérdida de datos. Todos los comandos para modificar la base de datos se registrarán en la caché de reescritura de AOF. Cuando el proceso hijo completa la reescritura AOF, enviará una señal de finalización al proceso padre. Después de recibir la señal de finalización, el proceso padre llamará a una función de procesamiento de señales y completará las siguientes tareas:
1. Escriba todo el contenido de la caché de reescritura de AOF en el nuevo archivo AOF.
2. Cambie el nombre del nuevo archivo AOF para sobrescribir el archivo AOF original.
El comando en el proceso de reescritura + AOF en la base de datos de Redis -------> nuevo archivo AOF ----> sobrescribe el anterior
Cuando se ejecuta el paso 1, el estado del archivo AOF existente, el nuevo archivo AOF y la base de datos son completamente consistentes.
Cuando se completa el paso 2, el programa completa la alternancia de los archivos AOF nuevos y antiguos.
Una vez que se ejecuta esta función de procesamiento de señales, el proceso principal puede continuar aceptando solicitudes de comando como de costumbre. En todo el proceso de reescritura en segundo plano de AOF, solo la caché de escritura final y la operación de cambio de nombre provocarán el bloqueo del proceso principal. En otras ocasiones, la reescritura en segundo plano de AOF no bloqueará el proceso principal, lo que provocará la reescritura de AOF en el rendimiento.
Lo anterior es la reescritura de fondo de AOF, es decir, el principio de funcionamiento del comando BGREWRITEAOF (reescritura de AOF).
3.4.2 Modo de disparo
1. Configure la configuración del disparador
en redis.conf
# 表示当前aof文件大小超过上一次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过，以启动时aof文件大小为准
auto-aof-rewrite-percentage 100
# 限制允许重写最小aof文件大小，也就是文件大小小于64mb的时候，不需要进行优化
auto-aof-rewrite-min-size 64mb2. Ejecute el comando bgrewriteaof
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started
3.4.3 Persistencia híbrida
RDB y AOF tienen sus propias ventajas y desventajas. Redis 4.0 comenzó a admitir la persistencia híbrida de RDB y AOF. Si la persistencia mixta está activada, el contenido del rdb se escribirá directamente al principio del archivo aof durante la reescritura de aof.
RDB head + AOF body ----> appendonly.aof
Activa la persistencia híbrida
aof-use-rdb-preamble yes 
Podemos ver que el archivo AOF es el encabezado del archivo RDB y el contenido del formato AOF. Al cargar, primero identificará si el archivo AOF comienza con la cadena REDIS. Si es así, cárguelo en formato RDB. Después cargando RDB, continúe presionando formato AOF Cargue el resto.
3.4.4 Carga y restauración de datos de archivos AOF
Debido a que el archivo AOF contiene todos los comandos de escritura necesarios para reconstruir el estado de la base de datos, el servidor solo necesita leer y volver a ejecutar los comandos de escritura guardados en el archivo AOF para restaurar el estado de la base de datos antes de que el servidor se apague. Redis lee el AOF archivo y restaura la base de datos. Los pasos detallados del estado son los siguientes:
1. Cree un cliente falso sin una conexión de red: debido a que los comandos de Redis solo se pueden ejecutar en el contexto del cliente, y los comandos que se usan al cargar el archivo AOF provienen directamente del archivo AOF en lugar de la conexión de red. Por lo tanto, el servidor usa un pseudo cliente sin una conexión de red para ejecutar el comando de escritura guardado en el archivo AOF. El efecto del pseudo cliente que ejecuta el comando es exactamente el mismo que el del cliente con una conexión de red
2. Analizar y leer un comando de escritura del archivo AOF
3. Utilice el pseudo cliente para ejecutar el comando de lectura
4. Continúe ejecutando los pasos 2 y 3 hasta que se hayan procesado todos los comandos de escritura en el archivo AOF.
Después de completar los pasos anteriores, el estado de la base de datos guardado en el archivo AOF se restaurará por completo. Todo el proceso se muestra en la siguiente figura:
4 Comparación de RDB y AOF
1. RDB almacena una instantánea de datos en un momento determinado, usando almacenamiento de compresión binaria, comandos de operación de almacenamiento AOF, usando almacenamiento de texto (híbrido)
2. El rendimiento de RDB es alto, el rendimiento de AOF es bajo
3. RDB perderá su estado de activación de configuración después la última instantánea Para todos los datos modificados, si AOF está configurado para guardar una vez por segundo, los datos se perderán como máximo 2 segundos.
4. Redis se ejecuta en modo de servidor maestro, RDB no guarda los datos de pares clave-valor caducados, Redis se ejecuta en modo de servidor esclavo, RDB guardará los pares clave-valor de datos caducados, cuando el servidor maestro se sincronice con el servidor esclavo, luego borrará los pares clave-valor caducados.
Cuando se escribe AOF en un archivo, se agregará un comando del a la clave caducada. Cuando se realiza la reescritura de AOF, se ignorarán la clave caducada y el comando del.
5 escenarios de aplicación
La base de datos en memoria rdb + aof no es fácil de perder
. Fuente de datos original: se inicializa desde la fuente de datos original cada vez que se inicia, por lo que no es necesario abrir la persistencia (pequeña cantidad de datos). El
servidor de caché RDB generalmente tiene un alto rendimiento
Cuando se restauran los datos, si
hay rdb + aof, entonces se restaurará aof, porque RDB provocará la pérdida de archivos y los datos relativos de AOF deben estar completos.
Solo rdb, restaurar rdb
Estrategia de configuración del gancho de tracción
Busque un alto rendimiento: restaure desde la fuente de datos sin tiempo de inactividad de Redis.
Biblioteca de diccionarios: no expulse, garantice la integridad de los datos sin persistencia
Usado como una base de datos, el volumen de datos principal
y subordinado no es pequeño, y el rendimiento de la caché es mayor: abra el RDB El
almacenamiento del volumen de datos de Redis es demasiado grande, el rendimiento cae repentinamente y el
tiempo de bifurcación es demasiado largo para bloquear el proceso principal ,
solo abre AOF