DÍA 71 Persistencia de alta disponibilidad de Redis

Alta disponibilidad de Redis

¿Qué es la alta disponibilidad?

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, etc.

Tecnología de alta disponibilidad de Redis

En Redis, las tecnologías para lograr una alta disponibilidad incluyen principalmente persistencia, replicación maestro-esclavo, centinela y clústeres de clúster, 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 realiza principalmente copias de seguridad (y sincronización) de datos en varias máquinas, así como equilibrio de carga y recuperación simple de fallas para operaciones de lectura.

  • 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. (El maestro está inactivo, encuentre un esclavo para convertirse en el nuevo maestro y el nodo centinela lo monitoreará)

  • 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 de clústeres: 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 una solución de alta disponibilidad relativamente completa. (6 juegos de inicio, en parejas, 3 maestros y 3 esclavos)

Redis persistencia

función persistente

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 finalice de manera anormal debido a una falla de energía del servidor y otras razones, es necesario guardar regularmente los datos en Redis de alguna forma (datos o comandos) desde la memoria 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.

Copia de seguridad ante desastres: generalmente realiza copias de seguridad fuera del sitio y cambia de nodo después de que ocurre un desastre. Por ejemplo, la base de datos utilizada originalmente en Shanghai ahora se cambia a la base de datos en Chongqing

Redis proporciona dos métodos para la persistencia:

• Persistencia de RDB: el principio es guardar los registros de la base de datos de Reids en la memoria en el disco con regularidad. (Periódicamente genere instantáneas de los datos en la memoria y guárdelas en el disco duro como archivos)
• 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. (similar al registro binario de Mysql) (los comandos de operación de escritura y eliminación se registran en el archivo AOF de manera adjunta)

Debido a 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. (Los RDB son más pequeños y más rápidos de restaurar. Menor impacto en el rendimiento).

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.

Condiciones desencadenantes

La activación de la persistencia de RDB se divide en activación manual y activación automática.

gatillo 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 crea un proceso secundario, que es responsable de crear el archivo RDB, y el proceso principal (es decir, el proceso principal de Redis) continúa 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 se debe evitar el uso de guardar en línea. ambiente.

gatillo automático

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 especificar en el archivo de configuración  save m n que cuando se produzcan n cambios en m segundos, se activará bgsave

 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  

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

proceso de ejecución bgsave

(1) El proceso principal de Redis primero juzga: si actualmente se está ejecutando save, o el proceso secundario de bgsave/bgrewriteaof, y si se está ejecutando, el comando bgsave regresará directamente.

• Los procesos secundarios de bgsave/bgrewriteaof no se pueden ejecutar al mismo tiempo, principalmente por consideraciones de rendimiento: dos procesos secundarios simultáneos realizan una gran cantidad de operaciones de escritura en disco al mismo tiempo, lo que puede causar problemas de rendimiento graves.

(2) 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.

(3) 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.

(4) 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 una vez finalizado. (reemplazo atómico: reemplace todo el archivo, ya sea todo o nada)

(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.

cargar 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 AOF tiene una prioridad más alta, cuando AOF está habilitado, Redis priorizará la carga de archivos AOF para restaurar datos; solo cuando AOF está deshabilitado, los archivos RDB se detectarán y cargarán 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.

Persistencia AOF (admite escritura de segundo nivel)

• La persistencia de RDB es para escribir datos de proceso en archivos, mientras que la persistencia de AOF es para registrar cada comando de escritura y eliminación ejecutado por Redis en un archivo de registro separado, y las operaciones de consulta no se registrarán.

• Cuando se reinicie Redis, ejecute los comandos en el archivo AOF nuevamente para restaurar los datos. (comando de reproducción para la recuperación)

• 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.

Habilitar 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行---指定AOF文件名称
 appendfilename "appendonly.aof"
 ----796行---是否忽略最后一条可能存在问题的指令
 aof-load-truncated yes   
 #Redis恢复时，发现AOF文件的末尾被截断了，会忽略最后一条可能存在问题的指令。默认值yes。即在aof写入时，可能发生redis机器运行崩溃，AOF文件的末尾被截断了，这种情况下，yes会继续执行并恢复尽量多的数据，而no会直接恢复失败报错退出。
 ​
 ​
 /etc/init.d/redis_6379 restart    #重启redis
 ls /var/lib/redis/6379/      #查看是否生成了aof文件

Proceso de implementación

Dado que es necesario registrar cada comando de escritura de Redis, no es necesario activar AOF. A continuación se describe el proceso de ejecución de AOF.

El proceso de ejecución de AOF incluye:

• 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 de aof_buf con el disco duro de acuerdo con diferentes estrategias de sincronización;

• Reescritura de archivo (reescritura) : reescriba periódicamente el archivo AOF para lograr el propósito de la compresión. (Comprimir o eliminar datos caducados, comandos no válidos y varios comandos)

Instrucción adjuntar (adjuntar)

• 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 AOF, a excepción del comando de selección que se usa para especificar la base de datos (como seleccionar 0 para seleccionar la base de datos 0), que agrega Redis, todos los demás son comandos de escritura enviados por el cliente.

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 tal 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 tanto, el sistema también proporciona funciones de sincronización como fsync y fdatasync, que pueden obligar al sistema operativo a escribir inmediatamente los datos del búfer en el disco duro, lo que garantiza 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:

• appendfsync always: después de escribir el comando en aof_buf, se llama inmediatamente a la operación fsync del sistema para sincronizar con el archivo AOF. Alta seguridad, bajo rendimiento.

• appendfsync no: cuando el búfer está lleno o supera el límite de tiempo especificado (30 segundos de forma predeterminada), los datos del búfer se escribirán en el disco duro. Alto rendimiento, pero baja seguridad.

• appendfsync everysec: Sincroniza una vez por segundo, que es un equilibrio entre el rendimiento y la seguridad de los datos, por lo que es la configuración predeterminada de Redis.

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

 Reescritura de archivos (reescritura)

• A medida que pasa el tiempo, el servidor Redis ejecuta más y más comandos de escritura, y el archivo AOF será cada vez más grande; los archivos AOF demasiado grandes no solo afectarán el funcionamiento normal del servidor, sino que también harán 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 el momento de la importación de Redis. Por lo tanto, en algunas realidades, la reescritura automática de archivos se desactivará y luego las tareas programadas se ejecutarán a una hora determinada todos los días.

Aviso:

La reescritura consume rendimiento y afecta al negocio, por lo que la reescritura no se puede realizar durante las horas pico de trabajo. Por lo tanto, la reescritura automática generalmente está desactivada y la tarea programada ejecuta la función de reescritura a una hora determinada todos los días.

La razón por la cual la reescritura de archivos puede comprimir archivos AOF es:

• Los datos caducados ya no se escriben en el archivo.
• Los comandos no válidos ya no se escriben en el archivo: por ejemplo, algunos datos se configuran repetidamente (set mykey v1, set mykey v2), algunos datos se eliminan (set myset vl, 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. (triste añadir colección)

Después de reescribir, el archivo aof guardará el estado final de las claves y borrará la redundancia anterior para reducir el tamaño del archivo.

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.

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

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

• Disparador manual: llame directamente al comando bgrewriteaof, 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.

• Disparador automático: 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行----
  771 auto-aof-rewrite-percentage 100
  772 auto-aof-rewrite-min-size 64mb
 ​
 -----------------------以下是注释--------------------------------
 ● auto-aof-rewrite-percentage 100  
 #文件的大小超过基准百分之多少后触发bgrewriteaof。默认这个值设置为100，意味着当前aof是基准大小的两倍的时候触发bgrewriteaof。把它设置为0可以禁用自动触发的功能。
 #即当前AOF文件大小(即aof_current_size)是上次日志重写时AOF文件大小(aof_base_size)两倍时，发生BGREWRITEAOF操作。
 #注意：例如上次文件达到100M进行重写，那么这次需要达到200M时才进行重写。文件需要越来越大，所以一般不使用自动重写。如果使用自动重写，需要定期手动重写干预一次，让文件要求恢复到100M。
 ​
 ● auto-aof-rewrite-min-size 64mb      #当文件大于64M时才会进行重写
 #当前aof文件大于多少字节后才触发。
 #当前AOF文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF

En cuanto al proceso de reescritura de archivos, hay dos puntos que necesitan especial atención:

1. La reescritura la realiza el proceso padre bifurcando el proceso hijo.
2. El comando de escritura ejecutado por Redis durante la reescritura debe agregarse al nuevo archivo AOF. Por esta razón, Redis introduce el caché aof_rewrite_buf.

El proceso de reescritura de archivos es el siguiente:

(1) El proceso principal de Redis primero juzga si hay un proceso secundario que esté ejecutando 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. (En circunstancias normales, cuando se usa AOF, se usará AOF para grabar y no se usará RDB. El comando bgsave se activará automáticamente durante la replicación maestro-esclavo)

(2) El proceso principal ejecuta la operación de bifurcación para crear un proceso secundario. Durante este proceso, el proceso principal está bloqueado (no puede aceptar ninguna solicitud del cliente).

(3.1) 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.

(3.2) 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. (para asegurarse de que los datos recién escritos no se perderán)

(4) De acuerdo con la instantánea de la memoria, el proceso secundario escribe en el nuevo archivo AOF de acuerdo con las reglas de combinación de comandos.

(5.1) 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.

(5.2) 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 consistente con el estado actual del servidor.

(5.3) Reemplace el archivo antiguo con el nuevo archivo AOF para completar la reescritura de AOF. (el reemplazo es atómico)

cargar 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 (como un apagado repentino de la máquina, es probable que el final del archivo esté incompleto) y el parámetro aof-load-truncado está habilitado, se generará una advertencia en el registro. y Redis ignorará el final del archivo AOF y el inicio se realizará correctamente. El parámetro aof-load-truncated está habilitado de forma predeterminada.

Ventajas y desventajas de RDB y AOF

Ventajas y desventajas de la persistencia de RDB

ventaja:

Los archivos RDB son compactos, de tamaño pequeño, rápidos en la transmisión de red y adecuados para una copia completa; 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.

(Tamaño pequeño, recuperación más rápida, menor impacto en el rendimiento).

defecto:

• La deficiencia fatal de los archivos RDB es que el método de persistencia de sus instantáneas de datos determina que no 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 tiene 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.

(Rendimiento deficiente en tiempo real, compatibilidad deficiente y bloqueará el proceso principal al bifurcar el proceso secundario).

Ventajas y desventajas de la persistencia AOF

• En correspondencia con la persistencia de RDB, la ventaja de AOF es que admite persistencia de segundo nivel, buen rendimiento en tiempo real y buena compatibilidad. Las desventajas son archivos grandes, velocidad de recuperación lenta y 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 de E/S 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.

Gestión del rendimiento de Redis

Ver el uso de la memoria de Redis

 方法一：进入redis数据库查看
 redis-cli
 127.0.0.1:6379> info memory
 ​
 方法二：命令行查看
 redis-cli info memory

fragmentación de la memoria

Cómo calcular la tasa de fragmentación de la memoria:

Tasa de fragmentación de memoria = memoria solicitada por Redis del sistema operativo / memoria ocupada por datos en Redis

mem_fragmentation_ratio = used_memory_rss / used_memory

• mem_fragmentation_ratio: tasa de fragmentación de la memoria.

• used_memory_rss: Es la memoria solicitada por Redis al sistema operativo.

• used_memory: es la memoria ocupada por los datos en Redis.

• used_memory_peak: el valor máximo del uso de memoria redis.

¿Cómo se produce la fragmentación de la memoria?

• Redis tiene su propio administrador de memoria interna para administrar la aplicación y la liberación de memoria con el fin de mejorar la eficiencia del uso de la memoria.

• Cuando se elimina el valor en Redis, la memoria no se libera directamente y se devuelve al sistema operativo, sino al administrador de memoria interna de Redis.

• Cuando solicite memoria en Redis, primero verifique si hay suficiente memoria disponible en su propio administrador de memoria.

• Este mecanismo de Redis mejora la tasa de utilización de la memoria, pero provocará que parte de la memoria en Redis no se use por sí sola pero no se libere, lo que provocará la fragmentación de la memoria.

rastrear la fragmentación de la memoria

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

• Es normal que la tasa de fragmentación de la memoria esté entre 1 y 1,5. Este valor indica que la tasa de fragmentación de la memoria es relativamente baja y también indica que Redis no intercambia memoria.

• Si la tasa de fragmentación de la memoria supera 1,5, significa que Redis consume el 150 % de la memoria física real requerida, de la cual el 50 % es la tasa de fragmentación de la memoria.

• 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 (usando memoria virtual, lo que reducirá el rendimiento). Necesita aumentar la memoria física disponible o reducir el uso de memoria de Redis.

Para resolver el problema de la alta tasa de fragmentación:

• Si su versión de Redis es inferior a 4.0, debe ingresar el comando de apagado y guardado en la herramienta redis-cli para permitir que la base de datos de Redis ejecute la operación de guardado y cierre el servicio de Redis, y luego reinicie el servidor. Después de reiniciar el servidor Redis, Redis devolverá la memoria inútil al sistema operativo y la tasa de fragmentación disminuirá.

• A partir de la versión 4.0 de Redis, puede desfragmentar la memoria en línea sin reiniciar y devolver la memoria no utilizada al sistema operativo

 config set activedefrag yes    #自动碎片清理
 memory purge                   #手动碎片清理

uso de memoria

Si el uso de memoria de la instancia de redis supera la memoria máxima disponible, 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

clave de reciclaje

La estrategia de limpieza de memoria garantiza una asignación razonable de los recursos de memoria limitados de Redis.

Cuando el uso de la memoria alcanza el umbral máximo establecido, se debe seleccionar una estrategia de reciclaje clave. De manera predeterminada, la estrategia de reciclaje es sin eliminación (no enviction).

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

 vim /etc/redis/6379.conf
 ---598行----
 maxmemory-policy noenviction   #修改max-memory-policy属性值
 ​
 ##回收策略有以下几种：##
 ●volatile-lru
 #使用LRU算法从已设置过期时间的数据集合中淘汰数据
 （移除最近最少使用的key，针对设置了TTL的key）
 ​
 ●volatile-ttl
 #从已设置过期时间的数据集合中挑选即将过期的数据淘汰
 （移除最近过期的key）
 ​
 ●volatile-random
 #从已设置过期时间的数据集合中随机挑选数据淘汰
 （在设置了TTL的key里随机移除）
 ​
 ●allkeys-lru
 #使用LRU算法 从所有数据集合中淘汰数据
 （移除最少使用的key，针对所有的key）
 ​
 ●allkeys-random
 #从数据集合中任意选择数据淘汰（随机移除key）
 ​
 ●noenviction
 #禁止淘汰数据（不删除直到写满时报错）

¿Cuáles son las optimizaciones de Redis?

Establezca el tiempo de espera de la conexión del cliente, la cantidad máxima de conexiones del cliente, la limpieza automática de desechos, el umbral máximo de memoria y la estrategia de recuperación de claves.

Establecer el período de tiempo de espera de la conexión del cliente Redis

 vim /etc/redis/6379.conf
 -----114行------
 114 timeout 0     
 #单位为秒（s），取值范围为0~100000。默认值为0，表示无限制，即Redis不会主动断开连接，即使这个客户端已经空闲了很长时间。
 #例如可设置为600，则客户端空闲10分钟后，Redis会主动断开连接。
 ​
 #注意：在实际运行中，为了提高性能，Redis不一定会精确地按照timeout的值规定的时间来断开符合条件的空闲连接，例如设置timeout为10s，但空闲连接可能在12s后，服务器中新增很多连接时才会被断开。

Establecer el número máximo de conexiones para el cliente redis

El número máximo de conexiones del cliente redis es 10000 por defecto.

 vim /etc/redis/6379.conf
 -----540行------
 540 # maxclients 10000     #若不设置，默认是10000

Ver el número actual de conexiones redis:

 [root@yuji ~]# redis-cli
 127.0.0.1:6379> info clients       #查看redis当前连接数
 # Clients
 connected_clients:1                 #redis当前连接数的为1   
 client_recent_max_input_buffer:2
 client_recent_max_output_buffer:0
 blocked_clients:0

Ver el número máximo de conexiones permitidas por redis:

 127.0.0.1:6379> config get maxclients
 1) "maxclients"     
 2) "10000"              #redis允许的最大连接数默认为10000

Establecer la desfragmentación automática de redis

 config set activedefrag yes    #自动碎片清理
 memory purge                   #手动碎片清理

Establecer el umbral máximo de memoria de redis

Si no se establece el umbral de memoria, no hay límite hasta que la memoria del servidor esté llena y luego se utilizará la partición de intercambio.

Después de establecer el umbral de memoria, no se utilizará la partición de intercambio. Y si se establece la política de recuperación de claves, cuando el uso de la memoria alcance el umbral máximo establecido, el sistema realizará la recuperación de claves.

 vim /etc/redis/6379.conf
 -----567行------
 567 # maxmemory <bytes>
 568 maxmemory 1gb           #例如设置最大内存阈值为1gb

Establecer la política de reciclaje de claves

Cuando el uso de la memoria alcanza el umbral máximo establecido, se debe seleccionar una estrategia de reciclaje clave. De manera predeterminada, la estrategia de reciclaje es sin eliminación (no enviction).

Una vez establecida la política de recuperación de claves, cuando el uso de la memoria redis alcance el umbral máximo establecido, el sistema realizará la recuperación de claves y liberará parte de la memoria.

 vim /etc/redis/6379.conf
 ---598行----
 maxmemory-policy noenviction   #需要修改max-memory-policy属性值
 ​
 ##回收策略有以下几种：##
 ●volatile-lru
 #使用LRU算法从已设置过期时间的数据集合中淘汰数据（移除最近最少使用的key，针对设置了TTL的key）
 ​
 ●volatile-ttl
 #从已设置过期时间的数据集合中挑选即将过期的数据淘汰（移除最近过期的key）
 ​
 ●volatile-random
 #从已设置过期时间的数据集合中随机挑选数据淘汰（在设置了TTL的key里随机移除）
 ​
 ●allkeys-lru
 #使用LRU算法 从所有数据集合中淘汰数据（移除最少使用的key，针对所有的key）
 ​
 ●allkeys-random
 #从数据集合中任意选择数据淘汰（随机移除key）
 ​
 ●noenviction
 #禁止淘汰数据（不删除直到写满时报错）