¿Qué debo hacer si la memoria de Redis está llena?
?
En el archivo de configuración de Redis redis.conf, el parámetro de tamaño de maxmemory se configura de la siguiente manera:
?
?
Si el almacenamiento real excede el tamaño de los parámetros de configuración de Redis, existe una estrategia de eliminación en Redis para eliminar las claves que deben eliminarse y crear una memoria limpia para los nuevos valores de clave.
?
Redis proporciona seis estrategias de eliminación, de las cuales la predeterminada es no desalojo. Las estrategias de eliminación entre estas seis estrategias son las siguientes:
?
?
?
LRU (usada menos recientemente) representa la clave utilizada menos recientemente, es decir, la clave a la que se accedió menos recientemente. Este algoritmo elimina datos en función de sus registros de acceso históricos.
?
La idea central es que si un valor clave rara vez se ha utilizado recientemente, rara vez se accederá a él en el futuro.
?
De hecho, el LRU implementado por Redis no es un algoritmo LRU real, es decir, nominalmente usamos el algoritmo LRU para eliminar claves, pero de hecho las claves que se eliminan no son necesariamente las más largas e inútiles. .
?
Redis utiliza un algoritmo LRU aproximado para eliminar claves mediante recopilación aleatoria, seleccionando aleatoriamente cinco claves cada vez y luego eliminando la clave utilizada menos recientemente.
?
Las cinco claves aquí son solo números predeterminados. Los números específicos también se pueden configurar en el archivo de configuración, como se muestra en la siguiente figura:
?
?
Cuando el algoritmo LRU aproximado sea mayor, estará más cerca del algoritmo LRU real. Se puede entender que cuanto mayor es el valor, más completos son los datos y más cerca están los datos eliminados de los datos utilizados menos recientemente.
?
Para implementar el algoritmo LRU por tiempo, Redis debe agregar un espacio de memoria adicional para cada clave para almacenar el tiempo de cada clave, con un tamaño de 3 bytes.
?
En Redis 3.0, el algoritmo LRU aproximado se ha optimizado y se mantendrá una memoria de un grupo de candidatos de tamaño 16 en Redis.
?
Cuando los datos de muestreo se seleccionan aleatoriamente por primera vez, los datos se colocan en el grupo de candidatos y los datos del grupo de candidatos se ordenan por tiempo.
?
Cuando se seleccionan datos por segunda vez, solo se incluirán en el grupo de candidatos los datos que hayan estado en el grupo de candidatos durante menos del tiempo mínimo.
?
Cuando el grupo de candidatos está lleno de datos en un momento determinado, la clave con el tiempo más largo será eliminada del grupo de candidatos. Durante la eliminación, la clave con el tiempo de acceso reciente más corto se selecciona directamente del grupo de candidatos para su eliminación.
?
El propósito de esto es seleccionar el valor clave que parece haber sido visitado menos recientemente, para que pueda eliminarse correctamente, ya que el tiempo mínimo en una muestra seleccionada al azar puede no ser el mínimo real. tiempo.
?
Sin embargo, el algoritmo LRU tiene una desventaja: si no se ha accedido a un valor clave antes, pero sí recientemente, se considerará dato activo y no se eliminará.
?
Sin embargo, se ha accedido con frecuencia a algunos datos antes, pero no recientemente, lo que puede hacer que estos datos se eliminen, lo que resulta en un error de juicio y la eliminación de datos calientes.
?
Entonces, en Redis 4.0, además del algoritmo LRU, se agrega un nuevo algoritmo LFU. Entonces, ¿qué es el algoritmo LFU?
?
?
LFU (menor frecuencia utilizada) se refiere a palabras clave que se han utilizado con frecuencia recientemente, es decir, palabras clave que se han visitado con frecuencia en el período reciente. Se basa en la frecuencia de visitas en el período reciente.
?
La idea central es: según la frecuencia de las visitas clave recientes, las claves con menos visitas se eliminarán primero y viceversa.
?
El algoritmo LFU refleja la popularidad de una clave y no se considerará datos populares sólo porque se acceda al algoritmo LRU de vez en cuando.
?
El algoritmo LFU admite la estrategia volatile-LFU y la estrategia allkeys-lfu.
?
?
Hay tres operaciones de eliminación en Redis. Esta estrategia es:
?
?
Hay dos formas de ceñirse a Redis: RDB y AOF.
?
En RDB, una copia de los datos en un momento determinado en la memoria se obtiene en forma de instantánea. Al crear un archivo RDB, puede crear el archivo RDB mediante los comandos guardar y bgsave.
?
Ambos comandos no guardarán claves caducadas en archivos RDB, lo que también puede lograr el efecto de eliminar claves caducadas.
?
Al cargar un archivo RDB al iniciar Redis, el servidor maestro no cargará claves caducadas, pero el servidor esclavo cargará claves caducadas.
?
En el modo AOF, Redis proporciona medidas de optimización para la reescritura y los comandos ejecutados son REWRITEAOF y BGREWRITEAOF. Ninguno de estos comandos escribirá claves caducadas en el archivo AOF y también pueden eliminar claves caducadas.
?
?
RDB es un método de persistencia de almacenamiento de instantáneas, que guarda específicamente los datos de la memoria de Redis en un momento determinado en un archivo en el disco duro. De forma predeterminada, el archivo guardado se llama dump.rdb. Cuando se inicia el servidor Redis, los datos del archivo dump.rdb se recargarán en la memoria para restaurarlos.
?
¿Activar el modo de persistencia RBD
?
El método para iniciar la persistencia de RDB es simple. El cliente puede enviar el comando save o bgsave al servidor Redis para permitir que el servidor genere un archivo RDB, o especificar las condiciones para activar RDB a través del archivo de configuración del servidor.
?
?
El comando de guardar es una operación síncrona.
?
?
?
Cuando el cliente envía un comando de guardar al servidor para su persistencia, el servidor bloquea otras solicitudes del cliente después del comando de guardar hasta que se completa la sincronización de datos.
?
?
A diferencia del comando guardar, el comando bgsave es una operación asincrónica.
?
?
?
?
?
?
?
Cuando el cliente envía el servicio para emitir el comando bgsave, el proceso principal del servidor Redis bifurcará un proceso secundario para resolver el problema de sincronización de datos. Después de guardar los datos en el archivo rdb, el subproceso saldrá.
?
Por lo tanto, en comparación con el comando guardar, el servidor Redis usa un subproceso secundario para escribir IO cuando procesa bgsave. El proceso principal aún puede recibir otras solicitudes, pero el proceso secundario de la bifurcación está sincronizado, por lo que el proceso secundario de la bifurcación. El proceso no puede recibir otras solicitudes, esto significa que si un proceso secundario de bifurcación tarda demasiado (generalmente muy rápido), el comando bgsave aún bloqueará otras solicitudes de clientes.
?
?
Además de enviar comandos a través del cliente, hay otra forma, que es guardar las condiciones especificadas que desencadenan la persistencia de RDB en el archivo de configuración de Redis, como comenzar cuando se alcanzan al menos varias operaciones de escritura dentro unos segundos.
?
Por ejemplo, podemos especificar las siguientes opciones en el archivo de configuración redis.conf:
?
?
El archivo de configuración se carga luego cuando se inicia el servidor.
?
?
Esta forma de activar rdb a través del archivo de configuración del servidor es similar al comando bgsave. Cuando se alcanza la condición de activación, el proceso hijo de las bifurcaciones sincronizará los datos. Pero es mejor no activar la persistencia RDB de esta manera, porque el tiempo de activación es demasiado corto y es fácil escribir archivos RDB con frecuencia, lo que afecta el rendimiento del servidor. Configurar un tiempo demasiado largo puede provocar la pérdida de datos.
?
?
Este artículo presenta tres formas en que el servidor genera archivos RDB, ya sea generados por el proceso principal o por el subproceso, el proceso es el siguiente:
?
?
?
?
?
Otro método de persistencia para Redis: AOF (solo agregar archivos).
?
A diferencia de RDB que almacena instantáneas en un momento determinado, la persistencia aof registra cada comando de operación de escritura del cliente al servidor y guarda estas operaciones de escritura en el archivo aof con el sufijo en el protocolo Redis. Cuando el servidor Redis se reinicie, cargará y ejecutará el comando de archivo AOF para restaurar los datos.
?
?
De forma predeterminada, Redis no habilita la persistencia de AOF. Podemos habilitarlo en el archivo de configuración y configurarlo con más detalle, como por ejemplo el siguiente archivo redis.conf:
?
?
?
En el archivo de configuración anterior, podemos especificar la estrategia de escritura a través de la opción appendfsync, que tiene tres opciones.
?
?
?
Esta estrategia es segura cuando cada operación de escritura del cliente se guarda en el archivo aof, pero cada solicitud de escritura tiene una operación IO, por lo que también es muy lenta.
?
?
La estrategia de escritura predeterminada de Appendfsync es escribir el archivo AOF una vez por segundo, por lo que se puede perder hasta 1 cantidad de datos.
?
?
El servidor Redis no es responsable de escribir el archivo aof, pero el sistema operativo controla cuándo escribir el archivo aof. Más rápido, pero también la opción menos segura y no recomendada.
?
?
AOF agrega cada operación de escritura realizada por el cliente al final del archivo aof, como ejecutar el comando incr de una determinada clave varias veces. En este momento, aof guarda cada comando en el archivo aof, y el archivo aof se volverá muy grande.
?
?
El archivo aof es demasiado grande. La carga del archivo aof para recuperar datos será muy lenta. Para resolver este problema, Redis admite la reescritura de muchos archivos. Al reescribir aof, se puede generar un conjunto mínimo de comandos para recuperar datos actuales, como muchos de los comandos del ejemplo anterior, que se pueden reescribir como:
?
?
?
Puedes configurar si deseas activar la reescritura a través de la opción no-appendfsync-on-rewrite en el archivo de configuración redis.conf. Este método se reescribirá cada vez que ocurra fsync, lo que afectará el rendimiento del servidor, por lo que el valor predeterminado es no, lo cual no se recomienda.
?
?
El cliente envía el comando bgrewriteaof al servidor, o puede pedirle al servidor que reescriba el comando aof.
?
?
La reescritura de Aof también es una operación asincrónica, es decir, si desea escribir un archivo AOF, el proceso principal de Redis será manejado por un proceso secundario de bifurcación, como se muestra a continuación:
?
?
?
?
?
?
Al escribir el archivo de registro de aof, si se cierra el servidor Redis, el archivo de registro de aof tendrá un error de formato. Cuando se reinicia el servidor Redis, el servidor Redis se negará a cargar este archivo aof. Puede reparar un problema y restaurar datos siguiendo los pasos a continuación.
?
?
?
AOF solo agrega archivos de registro, por lo que tiene poco impacto en el rendimiento del servidor, es más rápido que RDB y consume menos memoria.
?
?
?
Podemos comparar RDB y AOF desde varios aspectos. En las aplicaciones, debemos elegir RDB o AOF según nuestras necesidades reales.
De hecho, si desea que los datos sean lo suficientemente seguros, puede abrir ambos métodos, pero las operaciones IO simultáneas en dos métodos persistentes afectarán seriamente el rendimiento del servidor, por lo que a veces tenemos que elegir.
?
?
Cuando se abren RDB y AOF, Redis dará prioridad al uso del registro de AOF para recuperar datos, porque los archivos guardados por AOF son más completos que los archivos RDB.