prefacio
Redis persistencia, una vieja pregunta, pero a los entrevistadores les gusta preguntar. Este también es un punto de conocimiento que debemos saber cuando aprendemos Redis. Redis es una base de datos en memoria. Cuando funciona, los datos se almacenan en la memoria, lo cual es una de las razones por las que es rápido. Pero almacenar en la memoria es definitivamente un riesgo de pérdida de datos, por lo que Redis está diseñado para ser persistente. Hay dos tipos de persistencia de Redis: RDB y AOF.
persistencia RDB
RDB (Redis DataBase) es el método de almacenamiento predeterminado de redis. La persistencia de RDB es en realidad hacer una instantánea de los datos en la memoria directamente en el disco. Las formas de activar la persistencia de RDB son:
Cumplir con las reglas configuradas para guardar instantáneas (la configuración al comienzo de guardar en el archivo de configuración);
Ejecute el comando save o bgsave;
Ejecute el comando flushall;
Realice una operación de replicación maestro-esclavo (por primera vez).
En el archivo de configuración redis.conf, la configuración que comienza con guardar está relacionada con la persistencia de RDB. La explicación específica es la siguiente:
guardar "" significa cerrar la persistencia de rdb;
save 3600 1 significa que al menos 1 clave cambia cada 1 hora, la activación de una persistencia puede escribir múltiples condiciones;
save 3600 1 300 100 60 10000 Aquí se definen tres estrategias, y están en una relación OR entre sí.
persistencia AOF
La persistencia AOF ( Append Only File ) consiste en registrar todas las instrucciones de escritura ejecutadas por Reids y guardarlas en el registro, de forma similar al bin-log de MySQL. El método de persistencia está deshabilitado en el archivo de configuración predeterminado y la configuración debe modificarse para:
appendonly yesDado que AOF escribe el registro de operaciones de escritura del servicio Redis en el archivo de registro, cuando la operación de escritura es muy frecuente, también ejerce mucha presión sobre el disco. Por lo tanto, el aterrizaje de datos del disco de AOF (función fsync) también tiene tres estrategias:
Siempre: indica que se llamará a la función fsync siempre que haya una escritura;
Everysec: indica que la función fsync se llama una vez por segundo;
No: significa que la función fscyn no se llamará y seguirá el sistema por completo;
Se recomienda elegir everysec, que es más conservador.
reescritura AOF
Si el archivo AOF no interviene, seguirá creciendo hasta que su disco esté lleno. Afortunadamente, Redis proporciona un mecanismo de reescritura para AOF. Podemos ejecutar directamente el siguiente comando para reescribir AOF:
bgrewriteaof;Después de ejecutar este comando, el archivo AOF se reorganizará de acuerdo con el archivo RDB persistente y el archivo AOF existente, y borrará el registro de escritura inútil y finalmente logrará el propósito de adelgazar.
Por supuesto, AOF también tiene una configuración reescrita con dos parámetros:
parámetro |
ilustrar |
auto-aof-rewrite-min-size |
El archivo AOF no debe ser inferior a este tamaño para activar la reescritura, y cada reescritura posterior no se basará en esta variable (según el tamaño después de que se complete la última reescritura). Esta variable solo es válida para inicializar e iniciar redis |
auto-aof-rewrite-percentage |
Si el valor se define como 80, significa que cuando el tamaño del archivo AOF crezca más del 80 % del último tamaño (se registrará el tamaño del archivo AOF después de la última reescritura), se activará la operación de reescritura. |
Cómo elegir RDB y AOF
En el entorno de producción real, existen varias estrategias de persistencia de acuerdo con diferentes situaciones, como el volumen de datos, los requisitos de seguridad de la aplicación para los datos y las restricciones presupuestarias.
Por ejemplo, no use ninguna persistencia en absoluto, use una de persistencia RDB o AOF, o habilite la persistencia de instantáneas y la persistencia AOF al mismo tiempo. Además, la elección de la persistencia debe considerarse junto con la estrategia maestro-esclavo de Redis, porque la replicación y la persistencia maestro-esclavo también tienen la función de respaldo de datos, y el maestro maestro y el esclavo esclavo pueden elegir independientemente el esquema de persistencia.
No importa si los datos en Redis se descartan por completo (por ejemplo, Redis se usa completamente como caché para los datos de la capa de base de datos), entonces no se requiere persistencia si se trata de una máquina independiente o una arquitectura maestro-esclavo.
En un entorno independiente (para desarrolladores individuales, esta situación puede ser más común), si puede aceptar una pérdida de datos de más de diez minutos o más, elegir la persistencia de RDB es más beneficioso para el rendimiento de Redis, si solo puede aceptar datos de segundo nivel perdidos, se debe seleccionar AOF.
Pero en la mayoría de los casos, configuraremos el entorno maestro-esclavo. La existencia de Esclavo no solo puede realizar una copia de seguridad en caliente de los datos, sino también realizar una separación de lectura y escritura para compartir las solicitudes de lectura de Redis y continuar brindando servicios después de que el Maestro se apague. . En este caso, un enfoque posible es:
Maestro: apague la persistencia por completo, para que el desempeño del Maestro pueda alcanzar lo mejor;
Esclavo: desactive la persistencia de RDB, active AOF (si los requisitos de seguridad de los datos no son altos, puede activar la persistencia de RDB y desactivar AOF) y haga una copia de seguridad de los archivos persistentes con regularidad (como una copia de seguridad en otras carpetas y marque el tiempo de respaldo). Luego desactive la reescritura automática de AOF, luego agregue una tarea programada y llame a bgrewriteaof cuando Redis esté inactivo todos los días (como a las 12 en punto de la mañana).