Redis persistence mechanism, advantages and disadvantages, how to choose the right way

Redis persistence mechanism

RDB: Redis DataBase
AOF: Append Only File

RDB

1. What is RDB

   RDB: At regular intervals, write the data in the memory to a temporary file on the disk as a snapshot, and read the snapshot file into the memory when restoring. If the machine is down and restarted, the data in the memory will definitely be
   gone, and after dis, it will be restored.

2. Backup and restore
   Memory backup --> Temporary disk files
   Temporary files --> Restore to memory

3. RDB advantages and disadvantages

   • Advantage
     1. Backup every once in a while, full backup
     2. Disaster recovery is simple and can be transmitted remotely
     3. When the child process is backed up, the main process will not have any io operations (there will be no write modification or deletion) to ensure the integrity of the backup data
     4. Compared with AOF, it can be quickly restarted and restored when there are larger files
   • Disadvantage
     1. If a failure occurs, the last backup data may be lost
     2. The ratio of memory occupied by the child process will be exactly the same as that of the parent process, which will cause a burden on the CPU
     3. Since the scheduled full backup is a heavyweight operation, it cannot be processed for real-time backup.

4. RDB configuration

   1. The save location can be customized in redis.conf:
      /user/local/redis/working/dump.rdb

   2. Preservation mechanism:

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

      1. stop-writes-on-bgsave-error
         yes: If there is an error in the save process, stop the write operation.
         No: may cause data inconsistency
      2. rdbcompression
         yes: open the rdb compression mode
         no: close, it will save cpu loss, but the file will be large, the reason is the same as nginx

   AOF

   RDB will lose the last backed up rdb file, but it doesn’t matter, it can be ignored. After all, it’s a cache. If you lose it, you will lose it. But if you pursue data integrity, then consider using AOF.

   AOF features

   1. The write operation requested by the user is recorded in the form of a log. Read operations will not be recorded, because write operations will be stored.
   2. The file is in appended form rather than modified form.
   3. Redis's aof recovery is actually to read and write the appended file from the beginning to the end.

   Advantage

   1. AOF is more durable and can be backed up in seconds. If a problem occurs, only the last second of data will be lost, which greatly increases reliability and data integrity. So AOF can be used
      once, using fsync operation.
   2. It is appended in the form of log. If the disk is full, the redis-check-aof tool will be executed
   3. When the data is too large, redis can automatically rewrite AOF in the background. When redis continues to append logs to old files, rewriting is also very safe and will not affect client
      operations.
   4. All the write operations contained in the AOF log will make it easier for redis to analyze and recover.

   Disadvantage

   1. The same data, the same data, AOF is larger than RDB
   2. For different synchronization mechanisms, AOF will be slower than RDB, because AOF will back up for write operations every second, which is slightly lower than RDB. There is nothing wrong with backing up fsync every second, but
      if you do a backup fsync every time you write, then the performance of redis will decrease.
   3. There have been bugs in AOF, that is, the data is incomplete when data is restored. This makes AOF more fragile and prone to bugs, because AOF is not as simple as RDB, but because of the occurrence
      , AOF will not be reconstructed according to the old instructions. Instead, it is reconstructed according to the data instructions existing in the cache at the time, which is more robust and reliable.

   AOF configuration

   # 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
   

   Should RDB or AOF be used?

   1. If you can accept a period of cache loss, you can use RDB
   2. If you are more care about real-time data, then use AOF