Persistencia de datos de alta disponibilidad de Redis

La alta disponibilidad de Redis está garantizada por los siguientes aspectos:

• Persistencia de datos
• Replicación maestro-esclavo
• Recuperación automática de fallas
• Racimo

El autor presentará los aspectos anteriores uno por uno. El artículo de hoy presentará primero la persistencia de datos de Redis.

1. ¿Por qué necesitamos perseverancia?

Redis es una base de datos en la memoria. Todos los datos se almacenan en la memoria. Si la instancia deja de funcionar, se perderán todos los datos. Redis proporciona un mecanismo completo de persistencia de datos, que puede conservar los datos en el disco, lo que nos resulta conveniente para hacer copias de seguridad y restaurarlos rápidamente. .

Dos, método de persistencia de datos de Redis

Redis proporciona dos métodos de persistencia de datos:

1. RDB: guarde los datos de la memoria en el disco duro en forma de instantánea y genere el archivo dump.rdb, que es un archivo binario. Debido a que el archivo RDB se almacena en el disco, incluso si el proceso del servidor Redis sale, el archivo RDB todavía está allí. El servidor Redis detecta la existencia del archivo RDB cuando se inicia, carga automáticamente el archivo RDB y lo usa para restaurar el estado de la base de datos.
2. AOF: la persistencia AOF registra el estado de la base de datos al guardar los comandos de escritura ejecutados por el servidor de Redis. El archivo AOF guarda el protocolo de solicitud de comando de escritura de Redis , que está en formato de texto sin formato. Puede abrir directamente el archivo AOF para ver el contenido del archivo.

Nota:
1. Redis activa la función de persistencia RDB de
forma predeterminada ; 2. AOF está desactivado de forma predeterminada. Si la función de persistencia AOF se activa manualmente, el archivo AOF se usará primero para restaurar el estado de la base de datos, porque la frecuencia de actualización del archivo AOF suele ser mayor que la frecuencia de actualización del archivo RDB alto.

1. Resistencia RDB

1.1 ¿Cuándo se activará la persistencia de RDB?

Las situaciones que activan la persistencia de RDB se dividen en activadores manuales y activadores automáticos.

1.1.1 Disparador manual

Comando de disparo manual:

1. guardar: Bloqueo Una instancia con una gran memoria provocará un bloqueo de tiempo prolongado durante la ejecución, durante el cual el proceso principal no puede procesar ninguna solicitud de comando.
2. bgsave: proceso secundario de la bifurcación, el proceso secundario es responsable de la creación de archivos RDB y el proceso principal puede continuar procesando solicitudes de comando. El bloqueo se produce en la fase de bifurcación y el tiempo es corto.

1.1.2 Disparador automático

Las condiciones para activar RDB automáticamente son:

1. Utilice guardar configuración;
   formato de configuración: guardar [segundos] [cambios]
   significa que cuando hay [cambios] cambios en el conjunto de datos en [segundos] segundos, bgsave se activa automáticamente.
   La configuración predeterminada es:

#只要以下3个条件中的任意一个满足，bgsave就会执行。
#服务器在900秒内，对数据库进行了至少1次修改
save 900 1
#服务器在300秒内，对数据库进行了至少10次修改
save 300 10
#服务器在60秒内，对数据库进行了至少10000次修改
save 60 10000

Principio de implementación:

#serverCron服务定时器每100ms执行一次检查
if(now()-rdb_last_save_time < m(指定秒数) and rdb_changes_since_last_save>n(修改次数)){
    
    
   bgsave();
}

2. Realice una operación de copia completa desde el nodo;
3. Cuando se ejecuta el comando de apagado, bgsave se ejecutará automáticamente si AOF no está encendido;
4. comando de recarga de depuración;

Nota :如果开启了自动RDB，flushall因涉及的操作较多，可能会触发自动RDB，新产生的RDB文件将为空。

1.2 Configuración relacionada con RDB en redis.conf

#RDB自动触发条件(满足任意一个就可以触发RDB)
save 900 1
save 300 10
save 60 10000
#bgsave创建快照的时候出错了（比如，fork子进程内存不足或rdb文件所在的文件夹没有写入权限），redis主进程将不再接受新的写入命令
stop-writes-on-bgsave-error yes
#对RDB文件进行压缩
rdbcompression yes 
#RDB文件名称
dbfilename dump.rdb
#对RDB进行校验
rdbchecksum yes
 #（保存目录，这里是相对目录，和redis.conf是同一个目录）
dir ./ 

1.3 Pasos de persistencia de RDB

1. Ejecute el comando bgsave, el proceso padre de Redis juzga si actualmente hay procesos secundarios en ejecución, como procesos secundarios RDB / AOF, si hay un comando bgsave, regresa directamente;
2. El proceso padre ejecuta una operación de bifurcación para crear un proceso hijo. El proceso padre se bloqueará durante la operación de bifurcación. Puede ver la opción latest_fork_usec a través del comando info stats para obtener el tiempo de la última operación de bifurcación en microsegundos;
3. Una vez completada la bifurcación del proceso principal, el comando bgsave devuelve el mensaje "Se inició el guardado en segundo plano" y ya no bloquea el proceso principal y puede continuar respondiendo a otros comandos;
4. El proceso secundario crea un archivo RDB, genera un archivo de instantánea temporal basado en la memoria del proceso principal y reemplaza atómicamente el archivo original una vez completado. Ejecute el comando lastsave para obtener la hora de la última generación de RDB, correspondiente a la opción rdb_last_save_time de las estadísticas de información.
5. El proceso envía una señal al proceso padre para indicar la finalización, y el proceso padre actualiza las estadísticas. Para obtener más detalles, consulte las opciones relacionadas con rdb_ * en info Persistencia.

Nota : fork子进程时，需要生成另外一份内存，如果原来内存占用比较大，会存在内存膨胀的问题。
Para el archivo RDB de formato incorrecto, puede usar una redis-check-rdbherramienta para repararlo.

2. Persistencia AOF

2.1 Configuración relacionada con AOF en redis.conf

#开启AOF，默认关闭
appendonly yes
#AOF文件名称
appendfilename appendonly.aof
 #（保存目录，这里是相对目录，和redis.conf是同一个目录）
dir ./ 

#AOF文件写入磁盘频率
appendfsync always  #每次收到写命令就立即强制写入磁盘，是最安全的。但该模式下速度也是最慢的，一般不推荐使用。
appendfsync everysec #默认方式，每秒钟强制写入磁盘一次，在性能和持久化方面做平衡，推荐该方式。
appendfsync no  #完全依赖操作系统的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不推荐。

/*AOF重写相关命令*/
#在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes
no-appendfsync-on-rewrite yes
#AOF重写触发条件
auto-aof-rewrite-percentage 100 #当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-min-size 64mb #当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。

2.2 Pasos de persistencia AOF

La implementación de la persistencia AOF se puede dividir en tres pasos: adición de comandos, escritura de archivos y sincronización de archivos.

1. Agregar nombre: después de que el servidor haya ejecutado un comando de escritura, agregará el comando de escritura ejecutado al final del búfer aof_buf en el estado del servidor en el formato de protocolo;
2. Escritura y sincronización de archivos: el servidor comprueba periódicamente si el contenido del área del búfer aof_buf debe escribirse y guardarse en el archivo AOF. Si se requiere escritura de archivos se establece de acuerdo con la opción appendfsync. Puede establecer el valor de la opción appendfsync en función de la eficiencia y seguridad de la persistencia AOF.

Nota : Para el archivo AOF en el formato incorrecto, primero haga una copia de seguridad y luego use el redis-check-aof --fixcomando para repararlo. Después de la reparación, use diff-u para comparar las diferencias de datos para averiguar los datos que faltan, y algunos se pueden modificar y completar manualmente.

2.3 reescritura de AOF

2.3.1 ¿Por qué se reescribe AOF?

Cuando el comando de escritura se agrega al archivo AOF, el AOF se hará cada vez más grande, ocupando demasiado espacio en el disco duro y la carga de datos después de reiniciar será muy lenta, por lo que se requiere reescritura de AOF.

2.3.2 Mecanismo disparador de reescritura AOF

Hay dos formas de activar la reescritura de AOF: activación manual y activación automática.

1. Disparador manual: ejecute manualmente el comando BGREWRITEAOF;

2. Auto: configurando redis.conf en auto-aof-rewrite-percentagey auto-aof-rewrite-min-sizepara darse cuenta de que estas dos condiciones se 同时满足activan cuando el AOF.

2.3.3 Reglas de reescritura de AOF

La reescritura de AOF no lee y analiza el archivo AOF existente, se logra leyendo el estado actual de la base de datos del servidor.
Por lo tanto, los datos caducados no se escribirán en el nuevo archivo AOF y varios comandos para la misma clave serán reemplazados por un comando debido a la lectura directa del estado de la base de datos. Además, para evitar el desbordamiento del búfer de entrada del cliente causado por demasiados datos contenidos en una clave, el programa de reescritura primero determinará la clave que contiene al procesar claves que pueden contener múltiples elementos como listas, conjuntos, conjuntos ordenados y hashes. Si el número de elementos supera el valor constante configurado (el valor predeterminado es 64), se dividirá en varios comandos.

2.3.4 Pasos de reescritura de AOF

1. Ejecute la solicitud de reescritura de AOF. Si el proceso actual está realizando una reescritura AOF, la operación de reescritura no se realiza. Si el proceso está ejecutando bgsave, esperará a que se complete la ejecución antes de ejecutarse.
2. El proceso padre ejecuta la bifurcación para crear un proceso hijo, y la sobrecarga es equivalente al proceso bgsave.
3. (1) Una vez completada la operación de la bifurcación del proceso principal, continúe respondiendo a otros comandos. Todos los comandos de modificación todavía se escriben en el búfer AOF y se sincronizan con el disco duro de acuerdo con la estrategia appendfsync para garantizar la corrección del mecanismo AOF original.
   (2) Dado que la operación de la bifurcación utiliza tecnología de copia en escritura, el proceso hijo solo puede compartir los datos de la memoria durante la operación de la bifurcación. Dado que el proceso principal todavía responde a los comandos, Redis utiliza el "búfer de reescritura de AOF" para guardar esta parte de los nuevos datos para evitar que esta parte de los datos se pierda durante la generación del nuevo archivo AOF.
4. El proceso hijo escribe en el nuevo archivo AOF de acuerdo con la instantánea de la memoria y las reglas de combinación de comandos. La cantidad de datos escritos en el disco duro en lotes cada vez se controla mediante la configuración aof-rewrite-incremental-fsync, el valor predeterminado es 32 MB, para evitar que el disco duro sea bloqueado por demasiados datos en un solo flash.
5. (1) Después de que se escribe el nuevo archivo AOF, el proceso hijo envía una señal al proceso padre y el proceso padre actualiza la información estadística. Para obtener más detalles, consulte las estadísticas relacionadas con aof_ * en la persistencia de información.
   (2) El proceso padre escribe los datos en el búfer de reescritura de AOF en el nuevo archivo AOF.
   (3) Reemplace el archivo antiguo con el nuevo archivo AOF para completar la reescritura de AOF.

3. Comparación de RDB y AOF

1. El rendimiento de RDB es superior al de AOF:
   ● Los datos se almacenan en modo binario, el archivo de datos es relativamente pequeño y la carga es rápida.
   ● Cuando se almacena, se almacena de acuerdo con la estrategia de guardado en la configuración, cada vez que se agregan y almacenan muchos datos en lotes, y la eficiencia de escritura es muy alta. Bueno, y AOF generalmente funciona en modo de almacenamiento en tiempo real o casi en tiempo real. En términos relativos, la frecuencia de almacenamiento es alta, pero la eficiencia es baja.
2. La seguridad de los datos AOF es mayor que la de RDB:
   ● El almacenamiento se basa en la idea de lotes acumulativos, es decir, si se permite, cuanto más datos acumulados, mayor es la eficiencia de escritura, pero la acumulación de datos se completa con la acumulación de tiempo. Sí, si los datos no se escriben en RDB durante mucho tiempo, pero Redis encuentra un bloqueo, entonces los datos que no se escriben no se pueden recuperar, pero el método AOF es por el contrario, según la estrategia de frecuencia de almacenamiento configurada por AOF, se puede lograr lo mínimo. Pérdida de datos y alta capacidad de recuperación de datos.
   La elección entre los dos es un compromiso entre rendimiento y seguridad de los datos.

3. Referencias

1. https://zhuanlan.zhihu.com/p/111306444
2. "Diseño e implementación de Redis"