En los servidores web, la alta disponibilidad se refiere al tiempo en el que se puede acceder normalmente al servidor, y la medida es cuánto tiempo se pueden prestar los servicios normales (99,9%, 99,99%, 99,999%, etc.).

Sin embargo, en el contexto de Redis, el significado de alta disponibilidad parece ser más amplio: además de garantizar la prestación de servicios normales (como separación maestro-esclavo, tecnología de recuperación rápida ante desastres), también es necesario considerar la expansión de capacidad de datos y seguridad de datos sin pérdida.

En Redis, las tecnologías para lograr alta disponibilidad incluyen principalmente persistencia, replicación maestro-esclavo, centinelas y clústeres, a continuación se describen sus funciones y qué problemas resuelven.

Persistencia: La persistencia es el método de alta disponibilidad más simple (a veces ni siquiera se clasifica como un método de alta disponibilidad). Su función principal es la copia de seguridad de datos, es decir, almacenar datos en el disco duro para garantizar que los datos no se perderán debido al proceso. salida.

Replicación maestro-esclavo: la replicación maestro-esclavo es la base de Redis de alta disponibilidad. Los centinelas y los clústeres se basan en la replicación maestro-esclavo para lograr una alta disponibilidad. La replicación maestro-esclavo implementa principalmente copias de seguridad de datos en varias máquinas, así como equilibrio de carga para operaciones de lectura y recuperación de fallas simple. Defectos: la recuperación de fallas no se puede automatizar; las operaciones de escritura no se pueden equilibrar en la carga; la capacidad de almacenamiento está limitada por una sola máquina.

Sentinel: basado en la replicación maestro-esclavo, Sentinel implementa la recuperación automática de fallas. Defectos: las operaciones de escritura no se pueden equilibrar en la carga; la capacidad de almacenamiento está limitada por una sola máquina.

Clúster: a través de la agrupación en clústeres, Redis resuelve el problema de que las operaciones de escritura no pueden equilibrarse con la carga y la capacidad de almacenamiento está limitada por una sola máquina, y realiza un método de alta disponibilidad relativamente completo.

2. Persistencia de Rdies

2.1 Función de persistencia

Redis es una base de datos en memoria, y los datos se almacenan en la memoria. Para evitar la pérdida permanente de datos después de que el proceso de Redis finaliza de manera anormal debido a una falla de energía del servidor y otras razones, es necesario guardar periódicamente los datos en Redis desde la memoria de alguna forma (datos o comandos) al disco duro; cuando Redis se reinicie la próxima vez, use el archivo persistente para lograr la recuperación de datos. Además, los archivos persistentes se pueden copiar a una ubicación remota para realizar copias de seguridad en caso de desastre.

2.2 Redis proporciona dos formas de persistencia

Persistencia de RDB (Redis DataBase): el principio es guardar los registros de la base de datos de Reids en la memoria en el disco con regularidad

Persistencia AOF (agregar solo archivo): el principio es escribir el registro de operaciones de Reids en el archivo de forma adjunta, similar al binlog de MySQL.

Resumen: dado que el rendimiento en tiempo real de la persistencia AOF es mejor, es decir, se pierden menos datos cuando el proceso finaliza inesperadamente, por lo que AOF es actualmente el método de persistencia principal, pero la persistencia RDB todavía tiene su lugar.

3. persistencia RDB

La persistencia de RDB se refiere a guardar la instantánea de los datos en el proceso actual en la memoria en el disco duro dentro de un intervalo de tiempo específico (por lo que también se denomina persistencia de instantánea), almacenada en compresión binaria, y el sufijo del archivo guardado es rdb ; cuando se reinicia Redis, puede leer el archivo de instantánea para restaurar los datos.

3.1 Condiciones de activación

El disparador de persistencia RDB se divide en disparador manual y disparador automático.

3.1.1 Activación manual

Tanto el comando save como el comando bgsave pueden generar archivos RDB.

El comando guardar bloqueará el proceso del servidor Redis hasta que se cree el archivo RDB.Durante el bloqueo del servidor Redis, el servidor no puede procesar ninguna solicitud de comando.

El comando bgsave creará un proceso secundario, y el proceso secundario será responsable de crear el archivo RDB, mientras que el proceso principal (es decir, el proceso principal de Redis) continuará procesando las solicitudes.

Durante la ejecución del comando bgsave, solo el proceso secundario de la bifurcación bloqueará el servidor, pero para el comando guardar, todo el proceso bloqueará el servidor, por lo que guardar se ha abandonado básicamente, y el uso de guardar debe ser prevenido en el entorno en línea

3.1.2 Activación automática

Al activar automáticamente la persistencia de RDB, Redis también elegirá bgsave en lugar de guardar para la persistencia.
El caso más común de activación automática es pasar save mn en el archivo de configuración para especificar que bgsave se activará cuando se produzcan n cambios en m segundos.

vim /etc/redis/6379.conf
#---------219行以下三个save条件满足任意一个时，都会引起bgsave的调用-----
save 900 1 ：当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave
save 300 10 ：当时间到300秒时，如果redis数据发生了至少10次变化，则执行bgsave
save 60 10000 ：当时间到60秒时，如果redis数据发生了至少10000次变化，则执行bgsave
#---------242行是否开启RDB文件压缩---------------------------------------
rdbcompression yes
#---------254行指定RDB文件名----------------------------------------------
dbfilename dump.rdb
#---------264行指定RDB文件和AOF文件所在目录-------------------------------
dir /var/lib/redis/6379

3.1.3 Otros mecanismos de disparo automático

Además de savemn, existen otras situaciones que activan bgsave:

En el escenario de replicación maestro-esclavo, si el nodo esclavo realiza una operación de copia completa, el nodo maestro ejecutará el comando bgsave y enviará el archivo rdb al nodo esclavo.
Cuando se ejecuta el comando de apagado, la persistencia de RDB se ejecuta automáticamente.

3.1.4 Proceso de ejecución

El proceso principal de Redis primero juzga: si actualmente se está ejecutando save o el proceso secundario de bgsave/bgrewriteaof, si se está ejecutando, el comando bgsave devolverá directamente el proceso secundario de bgsave/bgrewriteaof y no se puede ejecutar al mismo tiempo. basado principalmente en consideraciones de rendimiento: dos concurrentes Los procesos secundarios realizan una gran cantidad de operaciones de escritura en disco al mismo tiempo, lo que puede causar serios problemas de rendimiento

El proceso principal ejecuta la operación de bifurcación para crear un proceso secundario. Durante este proceso, el proceso principal se bloquea y Redis no puede ejecutar ningún comando del cliente.

Después de 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.

El proceso secundario crea un archivo RDB, genera un archivo de instantánea temporal basado en la instantánea de memoria del proceso principal y reemplaza atómicamente el archivo original después de la finalización.

El proceso secundario envía una señal al proceso principal para indicar la finalización, y el proceso principal actualiza las estadísticas.

3.1.5 Cargando al inicio

La carga del archivo RDB se ejecuta automáticamente cuando se inicia el servidor y no hay ningún comando especial. Sin embargo, debido a que A0F tiene una prioridad más alta, cuando AOF está activado, Redis cargará primero el archivo AOF para restaurar los datos; solo cuando A0F está desactivado, el archivo RDB se detectará y cargará automáticamente cuando se inicie el servidor Redis. El servidor se bloquea mientras se carga el archivo RDB hasta que se completa la carga.

Cuando Redis carga el archivo RDB, lo verificará. Si el archivo está dañado, se imprimirá un error en el registro y Redis no podrá iniciarse.

4. Persistencia de AOF

La persistencia de RDB es escribir datos de proceso en archivos, mientras que la persistencia de AOF es registrar cada comando de escritura y eliminación ejecutado por Redis en un archivo de registro separado, y la operación de consulta no se registrará; cuando se reinicie Redis, ejecute el comando de archivo AOF nuevamente en para restaurar datos.
En comparación con RDB, AOF tiene un mejor rendimiento en tiempo real, por lo que se ha convertido en la principal solución de persistencia.

4.1 Activar AOF

El servidor Redis habilita RDB de forma predeterminada y deshabilita AOF. Para habilitar AOF, debe configurarse /etc/redis/6379.confen el archivo de configuración.

vim /etc/redis/6379.conf
--700行--修改，开启AOF
appendonly yes
--704行--指定A0F文件名称
appendfilename "appendonly.aof"
--796行--是否忽略最后一条可能存在问题的指令
aof-load-truncated yes
 
/etc/init.d/redis_6379 restart   重启服务

4.2 Proceso de ejecución

Dado que cada comando de escritura de Redis debe registrarse, no es necesario activar A0F. El proceso de ejecución de AOF es el siguiente

Comando agregar (agregar) : agregue el comando de escritura de Redis al búfer aof_buf;
Escritura de archivos (write) y sincronización de archivos (sync) : Sincronice el contenido en aof_buf con el disco duro de acuerdo con diferentes estrategias de sincronización;
Reescritura de archivos (reescritura): reescriba periódicamente el archivo AOF para lograr el propósito de la compresión.

4.2.1 Adición de instrucciones (añadir)

Redis primero agrega el comando de escritura al búfer en lugar de escribir directamente el archivo, principalmente para evitar escribir el comando directamente en el disco duro cada vez, lo que hace que la E/S del disco duro se convierta en el cuello de botella de la carga de Redis.

El formato de comando adjunto es el formato de protocolo de la solicitud de comando de Redis. Es un formato de texto sin formato, que tiene las ventajas de una buena compatibilidad, gran legibilidad, fácil procesamiento, operación simple y evita la sobrecarga secundaria. En el archivo A0F, a excepción del comando de selección que se usa para especificar la base de datos (como select0 para seleccionar la base de datos 0), que agrega Redis, todos los demás son comandos de escritura enviados por el cliente.

4.2.2 Escritura de archivos (write) y sincronización de archivos (sync)

Redis proporciona una variedad de estrategias de archivo de sincronización para el área de caché AOF. La estrategia involucra la función de escritura y la función fsync del sistema operativo, de la siguiente manera:

Para mejorar la eficiencia de escritura de archivos, en los sistemas operativos modernos, cuando un usuario llama a la función de escritura para escribir datos en un archivo, el sistema operativo generalmente almacena temporalmente los datos en un búfer de memoria. el límite de tiempo, los datos en el búfer en realidad se escriben en el disco duro. Aunque este tipo de operación mejora la eficiencia, también trae problemas de seguridad: si la computadora se detiene, los datos en el búfer de memoria se perderán, por lo que el sistema también proporciona funciones de sincronización como fsync y fdatasync, que pueden obligar al sistema operativo a transferir inmediatamente los datos en el búfer Los datos se escriben en el disco duro para garantizar la seguridad de los datos.

Hay tres métodos de sincronización para la estrategia de archivo de sincronización del área de caché AOF, que son:

vim /etc/redis/6379.conf
 
---729---
● appendfsync always:
解释：命令写入aof_ buf后立即调用系统fsync操作同步到AOF文件，fsync完成后线程返回。
	 这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，
	 严重降低了Redis的性能；即便是使用固态硬盘(SSD)，每秒大约也只能处理几万个命令，而且会大大降低SSD的寿命。
 
● appendfsync no:
解释：命令写入aof_ buf后调用系统write操作，不对AOF文件做fsync同步;
	 同步由操作系统负责，通常同步周期为30秒。这种情况下，文件同步的时间不可控，
	 且缓冲区中堆积的数据会很多，数据安全性无法保证。
 
● appendfsynceverysec:
解释：命令写入aof_ buf后调用系统write操作，write完成后线程返回; 
	 fsync同步文件操作由专门的线程每秒调用一次。
	 everysec是前述两种策略的折中，是性能和数据安全性的平衡，
	 因此是Redis的默认配置，也是我们推荐的配置。

4.2.3 Reescritura de archivos (rewrite)

A medida que pasa el tiempo, el servidor Redis ejecuta más y más comandos de escritura, y el archivo AOF se vuelve cada vez más grande: un archivo AOF demasiado grande no solo afectará el funcionamiento normal del servidor, sino que también hará que la recuperación de datos tarde demasiado .

La reescritura de archivos se refiere a la reescritura periódica del archivo AOF para reducir el tamaño del archivo AOF. Cabe señalar que la reescritura de AOF consiste en convertir los datos en el proceso de Redis en comandos de escritura y sincronizarlos con el nuevo archivo AOF; ¡no realizará ninguna operación de lectura o escritura en el archivo AOF anterior!

Otro punto a tener en cuenta sobre la reescritura de archivos: para la persistencia de AOF, se recomienda encarecidamente la reescritura de archivos, pero no es necesaria; incluso sin la reescritura de archivos, los datos pueden conservarse e iniciarse en la importación de Redis Time: por lo tanto, en algunas implementaciones, se activará la reescritura automática de archivos. apagado, y luego las tareas programadas se ejecutarán a una hora determinada todos los días.

4.2.4 La razón por la que la reescritura de archivos puede comprimir archivos AOF

Los datos caducados ya no se escriben en el archivo

Los comandos no válidos ya no se escriben en el archivo, como que algunos datos se configuran repetidamente (set mykey v1, set mykey v2), algunos datos se eliminan (sadd myset v1, del myset), etc.

Se pueden combinar varios comandos en uno: por ejemplo, sadd myset v1, sadd myset v2, sadd myset v3 se pueden combinar en sadd myset v1 v2 v3.

Del contenido anterior, se puede ver que dado que los comandos ejecutados por AOF se reducen después de la reescritura, la reescritura de archivos no solo puede reducir el espacio ocupado por el archivo, sino también acelerar la velocidad de recuperación.

4.3 El disparador de la reescritura de archivos se divide en disparador manual y disparador automático

Disparador manual: llame al comando bgrewriteaof directamente, la ejecución de este comando es algo similar a bgsave: ambos subprocesos de bifurcación realizan un trabajo específico, y ambos se bloquean solo cuando se bifurca.

Activación automática: BGREWRITEAOF se ejecuta automáticamente configurando la opción auto-aof-rewrite-min-size y la opción auto-aof-rewrite-percentage. Solo cuando las dos opciones de auto-aof-rewrite-min-size y auto-aof-rewrite-percentage se satisfacen al mismo tiempo, se activará automáticamente la reescritura de AOF, es decir, la operación bgrewriteaof.

vim /etc/redis/6379.conf
----771----
auto-aof-rewrite-percentage 100
#当前AOF文件大小(即aof_current_size)是上次日志重写时AOF文件大小(aof_base_size)两倍时，发生BGREWRITEAOF操作
auto-aof-rewrite-min-size 64mb
#当前A0F文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWR ITEAOF

4.4 Proceso de reescritura de archivos

关于文件重写的流程，有两点需要特别注意：
1.重写由父进程fork子进程进行；
2.重写期间Redis执行的写命令，需要追加到新的AOF文件中，为此Redis引入了aof_rewrite_buf缓存。

El proceso principal de Redis primero juzga si hay un proceso secundario que actualmente ejecuta bgsave/bgrewriteaof. Si existe, el comando bgrewriteaof regresará directamente. Si hay un comando bgsave, espere a que se complete la ejecución de bgsave antes de ejecutarlo.

El proceso principal realiza una operación de bifurcación para crear un proceso secundario y el proceso principal se bloquea durante este proceso.

Después de que el proceso principal se bifurca, el comando bgrewriteaof devuelve el mensaje "Se inició la reescritura del archivo adjunto en segundo plano" y ya no bloquea el proceso principal y puede responder a otros comandos. Todos los comandos de escritura de Redis 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.

Dado que la operación de bifurcación utiliza la tecnología de copia en escritura, el proceso secundario solo puede compartir los datos de la memoria durante la operación de bifurcación. Dado que el proceso principal sigue respondiendo al comando, Redis usa el búfer de reescritura AOF (aof_rewrite_buf) para guardar esta parte de los datos y evitar la pérdida de esta parte de los datos durante la generación del nuevo archivo AOF. Es decir, durante la ejecución de bgrewriteaof, los comandos de escritura de Redis se agregan simultáneamente a dos búferes, aof_buf y aof_rewrite_buf.

El proceso secundario escribe en un nuevo archivo AOF de acuerdo con las reglas de combinación del comando de acuerdo con la instantánea de la memoria.

Después de que el proceso secundario escribe el nuevo archivo AOF, envía una señal al proceso principal, y el proceso principal actualiza la información estadística, que se puede ver a través de la persistencia de información.

El proceso principal escribe los datos en el búfer de reescritura AOF en el nuevo archivo AOF, lo que garantiza que el estado de la base de datos guardado en el nuevo archivo AOF sea coherente con el estado actual del servidor.

Reemplace el archivo anterior con el nuevo archivo AOF para completar la reescritura de AOF.

4.5 Cargando al inicio

Cuando AOF está activado, Redis primero cargará el archivo AOF para restaurar los datos cuando se inicie; solo cuando AOF esté desactivado, cargará el archivo RDB para restaurar los datos.

Cuando AOF está habilitado pero el archivo AOF no existe, no se cargará aunque exista el archivo RDB.

Cuando Redis carga el archivo AOF, lo verificará. Si el archivo está dañado, se imprimirá un error en el registro y Redis no podrá iniciarse. Sin embargo, si el final del archivo AOF está incompleto (el tiempo de inactividad repentino de la máquina puede causar fácilmente que el final del archivo esté incompleto) y el parámetro aof-load-truncado está habilitado, se generará una advertencia en el registro, Redis ignora el final del archivo AOF y el inicio es exitoso.
El parámetro aof-load-truncated está habilitado de forma predeterminada.

5. Ventajas y desventajas de RDB y AOF

5.1 Ventajas y desventajas de la persistencia de RDB

Ventajas : los archivos RDB son compactos, pequeños en tamaño, rápidos en transmisión de red, adecuados para copias completas; la velocidad de recuperación es mucho más rápida que AOF. Por supuesto, una de las ventajas más importantes de RDB en comparación con AOF es el impacto relativamente pequeño en el rendimiento.

Desventajas : la desventaja fatal de los archivos RDB es que el método de persistencia de las instantáneas de datos determina que no se puede lograr la persistencia en tiempo real. Hoy en día, cuando los datos se vuelven cada vez más importantes, una gran cantidad de pérdida de datos a menudo es inaceptable, por lo que la persistencia AOF convertirse en la corriente principal. Además, los archivos RDB deben cumplir con un formato específico y tener poca compatibilidad (por ejemplo, las versiones antiguas de Redis no son compatibles con las nuevas versiones de los archivos RDB). Para la persistencia de RDB, por un lado, el proceso principal de Redis se bloqueará cuando bgsave realice la operación de bifurcación; por otro lado, la escritura de datos en el disco duro por parte del proceso secundario también generará presión de E/S.

5.2 Ventajas y desventajas de la persistencia AOF

Correspondiente a la persistencia RDB, la ventaja de AOF es que admite persistencia de segundo nivel y buena compatibilidad. La desventaja es que el archivo es grande, la velocidad de recuperación es lenta y tiene un gran impacto en el rendimiento.
Para la persistencia de AOF, la frecuencia de escritura de datos en el disco duro aumenta considerablemente (segundo nivel en la estrategia cada segundo), la presión de IO es mayor e incluso puede causar problemas adicionales de bloqueo de AOF.
La reescritura del archivo AOF es similar al bgsave de la RDB, y habrá bloqueo durante la bifurcación y la presión I0 del proceso secundario. En términos relativos, dado que AOF escribe datos en el disco duro con mayor frecuencia, tendrá un mayor impacto en el rendimiento del proceso principal de Redis.

Seis. Gestión del rendimiento de Redis

6.1 Ver el uso de la memoria de Redis

----- 查看Redis内存使用 -----
 
redis-cli -h 192.168.40.172 -p 6379
192.168.40.172:6379> info memory

6.2 Tasa de fragmentación de la memoria

El valor de memoria used_ memory_ rss asignado por el sistema operativo se divide por el valor de memoria used_ memory utilizado por Redis para calcular la fragmentación de la memoria causada por la asignación/recuperación ineficiente de la memoria física por parte del sistema operativo (asignación de memoria física discontinua)

El seguimiento de la tasa de fragmentación de la memoria es muy importante para comprender el rendimiento de los recursos de la instancia de Redis:

Es razonable que la tasa de fragmentación de la memoria sea ligeramente superior a 1. Este valor indica que la tasa de fragmentación de la memoria es relativamente baja

Si la tasa de fragmentación de la memoria supera 1,5, significa que Redis consume 150 números de memoria física real, de los cuales 50 es la tasa de fragmentación de la memoria. Debe ingresar el comando de apagado y guardado en la herramienta redis-cli y reiniciar el servidor Redis

Si la tasa de fragmentación de la memoria es inferior a 1, significa que la asignación de memoria de Redis supera la memoria física y el sistema operativo está intercambiando memoria. Necesita aumentar la memoria física disponible o reducir el uso de memoria Redis

6.3 Uso de memoria

El uso de memoria de la instancia de redis supera la memoria máxima disponible y el sistema operativo comenzará a intercambiar memoria y espacio de intercambio.

Formas de evitar el intercambio de memoria:

Elija instalar la instancia de Redis para el tamaño de los datos almacenados en caché

Utilice el almacenamiento de estructura de datos Hash tanto como sea posible

Establecer el tiempo de caducidad de la clave

Reciclar clave dentro de 6.4

Garantice una asignación razonable de los recursos de memoria limitados de redis

Cuando se alcanza el umbral máximo establecido, se debe seleccionar una estrategia de reciclaje clave. De forma predeterminada, la estrategia de reciclaje es prohibir la eliminación

Modifique el valor del atributo maxmemory-policy en el archivo de configuración:

vim /etc/redis/6379.conf
--598--
maxmemory-policy noenviction
●volatile-lru :使用LRU算法从已设置过期时间的数据集合中淘汰数据
●volatile-ttl :从已设置过期时间的数据集合中挑选即将过期的数据淘汰
●volatile-random :从已设置过期时间的数据集合中随机挑选数据淘汰
●allkeys-lru :使用LRU算法从所有数据集合中淘汰数据
●allkeys-random :从数据集合中任意选择数据淘汰
●noenviction :禁止淘汰数据

Optimización del servicio Redis

1. Rde alta disponibilidad