Mecanismo de persistencia de Redis, ventajas y desventajas, cómo elegir el camino correcto

Mecanismo de persistencia de Redis

RDB: Redis DataBase
AOF: Adjuntar solo archivo

RDB

1. Que es RDB

   RDB: a intervalos regulares, escriba los datos en la memoria en un archivo temporal en el disco como una instantánea, y lea el archivo de la instantánea en la memoria al restaurar. Si la máquina se apaga y se reinicia, los datos de la memoria definitivamente
   desaparecerán y, después de la eliminación, se restaurarán.

2. Copia de seguridad y restauración Copia de
   seguridad de la memoria -> Archivos de disco
   temporales Archivos temporales -> Restaurar a la memoria

3. Ventajas y desventajas de RDB

   • Ventaja
     1. Copia de seguridad de vez en cuando, copia de seguridad completa
     2. La recuperación ante desastres es simple y se puede transmitir de forma remota
     3. Cuando se realiza una copia de seguridad del proceso hijo, el proceso principal no tendrá ninguna operación de io (no habrá modificación ni eliminación de escritura) para garantizar la integridad de los datos de la copia de seguridad.
     4. En comparación con AOF, se puede reiniciar y restaurar rápidamente cuando hay archivos más grandes
   • Desventaja
     1. Si ocurre una falla, es posible que se pierdan los últimos datos de respaldo
     2. La proporción de memoria ocupada por el proceso hijo será exactamente la misma que la del proceso padre, lo que causará una carga en la CPU.
     3. Dado que la copia de seguridad completa programada es una operación pesada, no se puede procesar para una copia de seguridad en tiempo real.

4. Configuración RDB

   1. La ubicación para guardar se puede personalizar en redis.conf:
      /user/local/redis/working/dump.rdb

   2. Mecanismo de conservación:

      save 900 1 #如果1个缓存更新，则15分钟后备份
      save 300 10 #如果10个缓存更新，则5分钟后备份
      save 60 10000 #如果10000个缓存更新，则1分钟后备份 
      

      1. stop-writees-on-bgsave-error
         yes: si ocurre un error durante el proceso de guardado, detenga la operación de escritura.
         No: los datos pueden ser inconsistentes
      2. rdbcompression
         sí: abre el modo de compresión rdb
         no: cierra, se ahorrará la pérdida de cpu, pero el archivo será grande, la razón es la misma que nginx

   AOF

   RDB perderá el último archivo rdb respaldado, pero no importa, se puede ignorar. Después de todo, es un caché. Si lo pierde, lo perderá. Pero si busca la integridad de los datos, considere usar AOF .

   Funciones de AOF

   1. La operación de escritura solicitada por el usuario se registra en forma de registro. Las operaciones de lectura no se registrarán porque se almacenarán las operaciones de escritura.
   2. El archivo está en forma adjunta en lugar de forma modificada.
   3. La aof de recuperación de Redis es en realidad leer y escribir el archivo adjunto desde el principio hasta el final.

   Ventaja

   1. AOF es más duradero y se puede respaldar en segundos. Si ocurre un problema, solo se perderá el último segundo de los datos, lo que aumenta en gran medida la confiabilidad y la integridad de los datos. Entonces, AOF se puede usar
      una vez, usando la operación fsync.
   2. Se adjunta en forma de registro. Si el disco está lleno, se ejecutará la herramienta redis-check-aof
   3. Cuando los datos son demasiado grandes, redis puede reescribir automáticamente AOF en segundo plano. Cuando redis continúa agregando registros a archivos antiguos, la reescritura también es muy segura y no afectará las
      operaciones del cliente .
   4. Todas las operaciones de escritura contenidas en el registro AOF facilitarán el análisis y la recuperación de redis.

   Desventaja

   1. Los mismos datos, los mismos datos, AOF es más grande que RDB
   2. Para diferentes mecanismos de sincronización, AOF será más lento que RDB, porque AOF realizará una copia de seguridad de las operaciones de escritura cada segundo, que es un poco más bajo que RDB. No hay nada de malo en realizar una copia de seguridad de fsync cada segundo, pero
      si realiza una copia de seguridad de fsync cada vez que escribe, el rendimiento de redis disminuirá.
   3. AOF ha tenido un error, es decir, cuando se restauran los datos, los datos están incompletos, lo que hace que AOF sea más frágil y propenso a errores, porque AOF no es tan simple como RDB, pero debido a la ocurrencia
      , AOF no se reconstruirá de acuerdo con las instrucciones antiguas, en cambio, se reconstruye de acuerdo con las instrucciones de datos existentes en la caché en ese momento, lo que es más robusto y confiable.

   Configuración AOF

   # AOF 默认关闭，yes可以开启
   appendonly no
   # AOF 的文件名
   appendfilename "appendonly.aof"
   # no：不同步
   # everysec：每秒备份，推荐使用
   # always：每次操作都会备份，安全并且数据完整，但是慢性能差
   appendfsync everysec
   # 重写的时候是否要同步，no可以保证数据安全
   no-appendfsync-on-rewrite no
   # 重写机制：避免文件越来越大，自动优化压缩指令，会fork一个新的进程去完成重写动作，新进程里的内存数据会被重写，此时
   # 当前AOF文件的大小是上次AOF大小的100% 并且文件体积达到64m，满足两者则触发重写
   auto-aof-rewrite-percentage 100
   auto-aof-rewrite-min-size 64mb
   

   ¿Debería utilizarse RDB o AOF?

   1. Si puede aceptar un período de pérdida de caché, puede usar RDB
   2. Si le preocupan más los datos en tiempo real, utilice AOF