La dirección del texto original se actualiza y el efecto de lectura es mejor.
https://www.codermast.com/database/redis/redis-advance-persistence.htmlEl problema con Redis de punto único
- Problema de pérdida de datos: Redis es un almacenamiento en memoria y los datos pueden perderse cuando se reinicia el servicio. Resuelto implementando la persistencia de datos de Redis.
- Problema de simultaneidad: aunque la capacidad de simultaneidad de Redis de un solo nodo es buena, no puede satisfacer escenarios de alta simultaneidad como 618. Cree un clúster maestro-esclavo para lograr la separación de lectura y escritura.
- Problema de recuperación de fallas: si Redis deja de funcionar, el servicio no está disponible y se necesita un método automático de recuperación de fallas. Aproveche Redis Sentinel para la detección del estado y la recuperación automática.
- Problema de capacidad de almacenamiento: Redis se basa en la memoria, y la cantidad de datos que se pueden almacenar en un solo punto es difícil de satisfacer la demanda de datos masivos. Cree un clúster fragmentado y use el mecanismo de ranura para lograr una expansión dinámica.
# persistencia RDB
El nombre completo de RDB es Archivo de copia de seguridad de la base de datos de Redis (archivo de copia de seguridad de datos de Redis), también conocido como instantánea de datos de Redis. En pocas palabras, todos los datos en la memoria se graban en el disco. Cuando la instancia de Redis falla y se reinicia, lea el archivo de instantánea del disco y restaure los datos.
Los archivos de instantáneas se denominan archivos RDB, que se guardan en el directorio en ejecución actual de forma predeterminada.
saveComando: Cree una instantánea RDB, ejecutada por el proceso principal de Redis, que bloqueará todos los comandos. RDB debe escribirse en el disco y las operaciones de E/S son lentas.bgsaveComando: Inicie el proceso secundario para ejecutar RDB para evitar que el proceso principal se vea afectado.
RDB se ejecutará una vez cuando Redis esté inactivo.
De forma predeterminada, se generará un archivo dump.rdb en el directorio actual. Cuando se inicie Redis la próxima vez, este archivo se cargará de forma predeterminada para restaurar los datos de Redis.
Redis tiene un mecanismo interno para activar RDB, que se puede encontrar en el archivo redis.conf en el siguiente formato:
<span style="color:#2c3e50"><code>save 900 1 // 900 秒内，如果至少有 1 个 key 被修改，则执行 bgsave
save 300 10 // 300 秒内，如果至少有 10 个 key 被修改，则执行 bgsave
save 60 10000 // 60 秒内，如果至少有 10000 个 key 被修改，则执行 bgsave
save "" // 表示禁用 RDB
rdbcompression yes // 是否压缩，建议不开启，压缩也会消耗 CPU ，磁盘空间相对廉价
dbfilename dump.rdb // RDB 文件名称
dir ./ // 文件保存的路径目录
</code></span>Al comienzo de bgsave, el proceso principal se bifurcará para obtener el proceso secundario, y el proceso secundario compartirá los datos de memoria del proceso principal. Una vez completada la bifurcación, lea los datos de la memoria y escríbalos en el archivo RDB.
El proceso de bifurcación está bloqueado y Redis no puede responder a las solicitudes de los clientes en este momento. La velocidad de la bifurcación es muy rápida, porque la bifurcación solo copia la tabla de la página correspondiente, en lugar de copiar datos reales, similar al índice que solo copia datos.
Fork utiliza tecnología de copia en escritura:
- Cuando el proceso principal realiza una operación de lectura, acceso a la memoria compartida
- Cuando el proceso principal realiza una operación de escritura, se copia una copia de los datos y se realiza la operación de escritura.
caso extremo
Cuando el proceso secundario escribe un nuevo archivo RDB, el proceso principal modifica una gran cantidad de datos en este momento, por lo que los datos deben copiarse. Cuando el proceso principal necesita modificar todos los datos, necesita el doble de memoria original. Por lo tanto, cuando configuramos el servicio Redis, no podemos asignar toda la memoria real a Redis, y necesitamos reservar una parte del espacio de búfer.
Resumen de persistencia de RDB:
El proceso de bgsave en modo RDB:
- Bifurcar el proceso principal para obtener un proceso secundario, compartiendo espacio de memoria
- El proceso hijo lee los datos de la memoria y escribe nuevos archivos RDB
- Reemplace archivos RDB antiguos con archivos RDB nuevos
¿Cuándo se ejecutará el RDB? ¿Qué significa ahorrar 60 1000?
- El valor predeterminado es ejecutar RDB cuando se detiene el servicio Redis.
- save 60 10000 significa que RDB se activará si se realizan al menos 1000 modificaciones en 60 segundos
¿Desventajas de los RDB?
- El intervalo de ejecución de RDB es largo y existe el riesgo de pérdida de datos entre dos escrituras de RDB
- Lleva tiempo bifurcar subprocesos, comprimir y escribir archivos RDB
# persistencia AOF
El nombre completo de AOF es Append Only File (archivo adjunto). Cada comando de escritura procesado por Redis se registrará en el archivo AOF, que se puede considerar como un archivo de registro de comandos.
AOF está deshabilitado de forma predeterminada, debe modificar el archivo de configuración redis.conf para habilitar AOF
<span style="color:#2c3e50"><code>appendonly yes // 是否开启 AOF 功能，默认是关闭的
appendfilename "appendonly.aof" // AOF 的文件名称
</code></span>La frecuencia de grabación de comandos AOF también se puede configurar a través del archivo redis.conf:
<span style="color:#2c3e50"><code>appendfsync always // 表示每执行一次写命令，立刻记录到 AOF 文件中
appendfsync everysec // 写命令执行完先放入 AOF 缓冲区，然后每隔 1 秒将缓冲区数据写入到 AOF 文件，是默认方案
appendfsync no // 写命令执行完先放入 AOF 缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
</code></span>| elemento de configuración | Momento del cepillado | ventaja | defecto |
|---|---|---|---|
| Siempre | Disco de cepillo síncrono | Alta confiabilidad, casi sin pérdida de datos | impacto en el rendimiento |
| cada segundo | cepillo por segundo | rendimiento moderado | Hasta 1 segundo de pérdida de datos |
| No | control del sistema operativo | Mejor presentación | Poca confiabilidad, posible pérdida de grandes cantidades de datos |
AOF es un comando de registro y el archivo AOF será mucho más grande que el archivo RDB. Y AOF registrará múltiples operaciones de escritura en la misma clave, pero solo la última operación de escritura es significativa. Al ejecutar el comando bgrewriteaof, el archivo AOF se puede reescribir para lograr el mismo efecto con la menor cantidad de comandos.
Redis también reescribirá automáticamente el archivo AOF cuando se active el umbral. Los umbrales también se pueden configurar en redis.conf:
<span style="color:#2c3e50"><code>auto-aof-rewrite-percentage 100 // AOF 文件比上次文件增长多少百分比，则触发重写
auto-aof-rewrite-min-size 64mb // AOF 文件体积最小多大以上才触发重写
</code></span># Comparación entre RDB y AOF
RDB y AOF tienen cada uno sus propias ventajas y desventajas.Si los requisitos de seguridad de datos son altos, a menudo se usan en combinación en el desarrollo real.
| Persistencia | integridad de los datos | Tamaño del archivo | Velocidad de recuperación del tiempo de inactividad | Prioridad de recuperación de datos | Uso de recursos del sistema | Escenas a utilizar |
|---|---|---|---|---|---|---|
| RDB | Tome instantáneas de toda la memoria a intervalos regulares | Incompleto, perdido entre copias de seguridad | Habrá compresión, el tamaño del archivo es pequeño. | pronto | Bajo porque la integridad de los datos no es tan buena como AOF | Alto y pesado consumo de memoria y CPU |
| AOF | Registra cada comando ejecutado | Relativamente completo, dependiendo de la estrategia de cepillado | Grabar comandos, el tamaño del archivo es muy grande | lento | Alto debido a una mayor integridad de los datos | Bajo, principalmente recursos de E / S de disco, pero AOF consumirá una gran cantidad de recursos de CPU y memoria al reescribir |