Redis es una base de datos avanzada clave-valor. Es similar a memcached, pero los datos pueden persistir y los tipos de datos son ricos. Hay cadenas, listas enlazadas, conjuntos y colecciones ordenadas. Soporta calcular la suma, intersección y complementación (diferencia) de colecciones en el lado del servidor, y también soporta una variedad de funciones de ordenación. Así que Redis también puede verse como un servidor de estructuras de datos.
Todos los datos de Redis se almacenan en memoria y luego se almacenan en disco de forma asíncrona de vez en cuando (esto se llama "modo semipersistente"); También puedes escribir cada cambio de datos en un archivo Append Only File (AOF) (esto se llama "modo de persistencia completa").
El primer método es el filesnapshotting: el redis por defecto persistirá los datos en el disco en forma de instantánea (un archivo binario, dump.rdb, este nombre de archivo puede especificarse), y el formato en el archivo de configuración es: save N M significa que en N segundos, redis tomará una instantánea al disco si al menos M modificaciones ocurren en redis. Por supuesto, también podemos realizar manualmente el save o bgsave (asíncrono) para tomar instantáneas.
Aquí tienes una breve introducción a cómo funciona: Cuando Redis necesita persistir, Redis bifurca un proceso hijo; El proceso hijo escribe los datos en un archivo RDB temporal en disco; Cuando el subproceso termina de escribir el archivo temporal, reemplaza al RDB original, que tiene la ventaja de copiar al escribir
También existe un método de persistencia: Append-only:filesnapshotting método. Cuando redis está anormalmente muerto, los datos recientes se perderán (la cantidad de datos perdidos depende de la configuración de tu política de guardado), así que este es su mayor inconveniente: cuando el volumen de negocio es grande, los datos perdidos son muchos. El método de solo añadir puede lograr toda la pérdida de datos, pero el rendimiento de Redis es peor. AOF puede persistir durante todo el proceso, solo necesita activarse en el archivo de configuración (por defecto es no), solo añade sí. Después de activar AOF, cada vez que Redis ejecuta un comando para modificar datos, se añadirá al archivo AOF, y cuando redis se reinicie, se leerá el archivo AOF para "reproducirse" y restaurarlo hasta el último momento antes de que se cierre Redis.
Reescritura LOG A medida que el archivo AOF se hace cada vez más grande a medida que se modifican los datos, muchos de los cuales registran cambios en una clave. Por lo tanto, redis tiene una característica interesante: reconstruir el archivo AOF en segundo plano sin afectar la operación del lado del cliente. Ejecutar el comando BGREWRITEAOF en cualquier momento escribirá la secuencia más corta de comandos en la memoria actual en disco, y estos comandos pueden construir completamente la situación de datos actual sin cambios innecesarios (como cambios de estado, cambios de contador, etc.), reduciendo el tamaño del archivo AOF. Así que al usar OF, redis recomienda usar también BGREWRITEAOF.
Hay tres formas de actualizar el archivo AAF, consulta el parámetro de configuración appendfsync: appendfsync siempre llama a fsync para vaciar el archivo AOF cada vez que se envía un comando de modificación, lo cual es muy, muy lento, pero también muy seguro; appendfsync cada segundo llama a fsync para vaciar rápidamente el archivo AOF, pero puede perder datos en un segundo; appendfsync no depende del sistema operativo para actualizar, redis no actualiza activamente el OV, que es lo más rápido, pero la seguridad es pobre. Se recomienda por defecto la actualización por segundo, para que se tengan en cuenta tanto la velocidad como la seguridad.
Puede deberse a razones del sistema que el AOF está corrupto, Redis ya no puede cargar este OF del OV, puedes seguir los pasos siguientes para solucionarlo: Primero, haz una copia de seguridad del archivo AOF y cópialo a otro lugar; Arreglar el archivo OF original, ejecutar: $redis-check-aof –fix; Puedes usar el comando diff –u para ver dónde los archivos son inconsistentes antes y después de la reparación. Reinicia el servicio Redis.
Cómo funciona LOG Rewrite: Lo mismo usa copy-on-write: el primer redis bifurca un proceso hijo; El proceso hijo escribe el último AOF en un archivo temporal; El proceso padre escribe incrementalmente los últimos cambios ejecutados en memoria (en este momento, el antiguo AOF sigue escrito y es seguro reescribirlo si falla); Cuando el proceso hijo termina de reescribir el archivo temporal, el proceso padre recibe una señal y escribe los cambios incrementales previos en memoria al final del archivo temporal. Redis renombra el archivo OF antiguo, cambia el nombre del archivo temporal y comienza a escribir en el nuevo OF.
Por último, por si acaso (la máquina se bloquea o se cierra el disco), recuerda hacer copias de seguridad regulares del archivo *rdb *.aof generado usando filesnapshotting o solo Append-only a la máquina remota. Uso un crontab para SCP cada media hora. No usé la función maestro-esclavo de Redis, porque una copia de seguridad de media hora debería estar bien, y siento que es un poco un desperdicio de la máquina si tienes un maestro-esclavo. Esto depende en última instancia de la aplicación.
|
Publicado en 24/8/2017 16:37:45
|
|
|
