Hola a todos, mi nombre es Xiaolin.
Aunque Redis es una base de datos en memoria, proporciona dos tecnologías para la persistencia de datos.
Son "registro AOF e instantánea RDB" respectivamente.
Ambas técnicas utilizan un archivo de registro cada una para registrar información, pero el contenido de los registros es diferente.
- El contenido del archivo AOF es el comando de operación;
- El contenido de un archivo RDB son datos binarios.
Ya introduje el principio de persistencia AOF en el último artículo, y hoy hablaré principalmente sobre las instantáneas RDB .
La llamada instantánea es para registrar un momento determinado, por ejemplo, cuando tomamos una fotografía de un paisaje, la imagen y la información de ese momento se registran en una foto.
Por lo tanto, la instantánea RDB es para registrar los datos de la memoria de un momento determinado, que registra los datos reales, y el archivo AOF registra el registro de la operación del comando, no los datos reales.
Por lo tanto, cuando Redis restaura datos, la eficiencia de la recuperación de datos RDB será mayor que la de AOF, porque el archivo RDB se puede leer directamente en la memoria y no es necesario realizar pasos adicionales para restaurar datos como AOF.
A continuación, hablemos en detalle de las instantáneas de RDB.
¿Cómo usar las instantáneas?
Para familiarizarse con algo, es una mejor manera de ver primero cómo usarlo.
Redis proporciona dos comandos para generar archivos RDB, a saber, savey bgsaveLa diferencia entre ellos es si se ejecutan en el "hilo principal":
- Después de ejecutar el comando de guardar, el archivo RDB se generará en el subproceso principal. Dado que el comando de operación se ejecuta en el mismo subproceso, si el tiempo para escribir el archivo RDB es demasiado largo, el subproceso principal se bloqueará ;
- Cuando se ejecuta el comando bgsava, se creará un proceso secundario para generar el archivo RDB, lo que puede evitar el bloqueo del hilo principal ;
La carga de archivos RDB se realiza automáticamente cuando se inicia el servidor y Redis no proporciona un comando específico para cargar archivos RDB.
Redis también puede ejecutar automáticamente el comando bgsava a intervalos regulares a través de las opciones del archivo de configuración.La siguiente configuración se proporciona de forma predeterminada:
save 900 1
save 300 10
save 60 10000
Aunque la opción se llama sava, en realidad ejecuta el comando bgsava, es decir, crea un subproceso para generar el archivo de instantánea RDB.
Siempre que se cumpla alguna de las condiciones anteriores, se ejecutará bgsava, y sus significados son:
- La base de datos se ha modificado al menos una vez en 900 segundos;
- Al menos 10 cambios en la base de datos en 300 segundos;
- En 60 segundos, se realizaron al menos 10.000 modificaciones en la base de datos.
Se menciona aquí que la instantánea de Redis es una instantánea completa , es decir, cada vez que se ejecuta una instantánea, "todos los datos" en la memoria se graban en el disco.
Por lo tanto, se puede considerar que realizar instantáneas es una operación relativamente pesada y, si la frecuencia es demasiado frecuente, puede tener un impacto en el rendimiento de Redis. Si la frecuencia es demasiado baja, se perderán más datos cuando falle el servidor.
Por lo general, es posible configurar una instantánea para que se guarde al menos una vez cada minutos 5. En este momento, si Redis se cae, significa que los datos pueden perderse hasta por minutos 5.
Esta es la desventaja de las instantáneas de RDB. Cuando el servidor falla, se perderán más datos que la persistencia de AOF. Debido a que las instantáneas de RDB son instantáneas completas, la frecuencia de ejecución no puede ser demasiado frecuente, de lo contrario, afectará el rendimiento de Redis y el registro de AOF puede Registre los comandos de operación en segundos, por lo que la pérdida de datos es relativamente menor.
¿Se pueden modificar los datos mientras se realiza una instantánea?
Aquí viene el problema. Durante la ejecución de bgsava, el subproceso principal puede continuar funcionando porque se entrega al proceso secundario para construir el archivo RDB. ¿Puede el subproceso principal modificar los datos en este momento?
Si no puede modificar los datos, el rendimiento se reducirá mucho. Si es posible modificar los datos, ¿cómo se puede hacer?
Solo digamos la conclusión, durante la ejecución de bgsava, Redis aún puede continuar procesando el comando de operación , es decir, los datos pueden modificarse.
Entonces, ¿cómo exactamente? La tecnología clave es la tecnología copy-on-write (*Copy-On-Write, COW*).
Al ejecutar el comando bgsava, se fork()creará . En este momento, el proceso secundario y el proceso principal comparten la misma pieza de datos de memoria, porque cuando se crea el proceso secundario, se copiará la tabla de páginas del proceso principal. , pero la memoria física a la que apunta la tabla de páginas sigue siendo Uno.
La memoria física solo se copia cuando se produce una modificación de los datos de la memoria.
El propósito de esto es reducir la pérdida de rendimiento al crear procesos secundarios, acelerando así la creación de procesos secundarios.Después de todo, el proceso de creación de procesos secundarios bloqueará el hilo principal.
Por lo tanto, después de crear el proceso secundario bgsave, dado que comparte todos los datos de memoria del proceso principal, puede leer directamente los datos de memoria en el subproceso principal y escribir los datos en el archivo RDB.
Cuando el subproceso principal también realiza operaciones de solo lectura en estos datos de memoria compartida, entonces el subproceso principal y el proceso secundario bgsave no se afectan entre sí.
Sin embargo, si el subproceso principal desea modificar una determinada pieza de datos (como un par clave-valor A) en los datos compartidos, se producirá una copia en escritura, por lo que se copiará la memoria física de esta pieza de datos (clave -valor par A') , y luego el principal El subproceso A'realiza operaciones de modificación en esta copia de datos (par clave-valor) . Al mismo tiempo, el proceso secundario bgsave puede continuar escribiendo los datos originales (pares clave-valor A) en el archivo RDB .
Eso es todo, Redis usa bgsave para tomar una instantánea de todos los datos en la memoria actual. Esta operación se realiza en segundo plano por el subproceso bgsave, y el subproceso principal no se bloquea durante la ejecución, lo que permite que el subproceso principal modifique los datos. al mismo tiempo.
Los estudiantes cuidadosos deben haber descubierto que durante el proceso de la instantánea bgsave, si el subproceso principal modifica los datos compartidos, después de que se produzca la copia en escritura, la instantánea RDB guarda los datos de la memoria original y los datos recién modificados por el subproceso principal se almacenan en el método en Qué está escrito en el archivo RDB en este momento solo se puede transferir a la siguiente instantánea de bgsave.
Por lo tanto, cuando Redis usa la instantánea bgsave, si el subproceso principal modifica los datos de la memoria, ya sea que se trate de datos de memoria compartida o no, la instantánea RDB no puede escribir los datos recién modificados por el subproceso principal, porque en este momento los datos de la memoria del El subproceso principal y la memoria del subproceso secundario no se pueden escribir en la instantánea de RDB. Los datos se han separado y los datos de memoria escritos en el archivo RDB por el subproceso secundario solo pueden ser los datos de memoria originales.
Si el sistema falla justo después de crear el archivo de instantánea RDB, Redis perderá los datos modificados por el subproceso principal durante la instantánea.
Además, existe un caso tan extremo cuando se produce la copia en escritura.
Cuando Redis realiza la persistencia de RDB, el proceso principal y el proceso secundario comparten la misma memoria física cuando solo se bifurcan, pero el proceso principal procesa la operación de escritura y modifica la memoria compartida en el camino, por lo que la memoria física de los datos modificados actualmente será copiado. .
En casos extremos, si se modifica toda la memoria compartida, el uso de memoria en este momento es el doble del original.
Por lo tanto, para escenarios con muchas operaciones de escritura, debemos prestar atención a los cambios de memoria durante el proceso de instantánea para evitar que la memoria se llene.
Combinación de RDB y AOF
Aunque la velocidad de recuperación de datos RDB es más rápida que AOF, la frecuencia de las instantáneas no es fácil de controlar:
- Si la frecuencia es demasiado baja, una vez que el servidor se cae entre dos instantáneas, se pueden perder más datos;
- Si la frecuencia es demasiado alta, las escrituras frecuentes en el disco y la creación de procesos secundarios generarán una sobrecarga de rendimiento adicional.
¿Hay algún método que no solo tenga las ventajas de la rápida velocidad de recuperación de RDB y las ventajas de AOF con menos pérdida de datos?
Por supuesto, eso es combinar RDB y AOF. Este método se propuso en Redis 4.0. Este método se llama uso mixto de registro AOF e instantánea de memoria , también llamado persistencia mixta.
Si desea habilitar la función de persistencia híbrida, puede establecer el siguiente elemento de configuración en sí en el archivo de configuración de Redis:
aof-use-rdb-preamble yes
La persistencia híbrida funciona en el proceso de reescritura del registro AOF .
Cuando la persistencia híbrida está habilitada, cuando AOF reescribe el registro, el forksubproceso de reescritura saliente primero escribirá los datos de memoria compartidos con el subproceso principal en el archivo AOF en modo RDB, y luego se registrarán los comandos de operación procesados por el subproceso principal. el búfer de reescritura, los comandos incrementales en el búfer de reescritura se escribirán en el archivo AOF en modo AOF. Una vez completada la escritura, se notificará al proceso principal para reemplazar el archivo AOF anterior con el nuevo archivo AOF que contiene formato RDB y AOF formato.documento.
Es decir, usando persistencia híbrida, la primera mitad del archivo AOF son datos completos en formato RDB y la segunda mitad son datos incrementales en formato AOF .
La ventaja de esto es que al reiniciar Redis para cargar datos, dado que la primera mitad es contenido RDB, la velocidad de carga será muy rápida .
Después de cargar el contenido del RDB, se cargará el contenido del AOF en la segunda mitad. El contenido aquí es el comando de operación procesado por el subproceso principal durante la reescritura del AOF por el proceso secundario en segundo plano de Redis, que puede reducir la pérdida . de datos