• introduce
    • The AOF and RDB persistence mechanisms are provided. The persistence function effectively avoids data loss caused by process exit, and the data can be recovered using the previous persistence file during the next restart.
  • RDB
    • Snapshot is a process that generates a snapshot of the current process data and saves it to a disk
    • triggering
      • Manually triggered
        • Save command: block the current Redis server until the RDB process is complete.
        • Bgsave command
          • The redis process forks to create a child process. The child process is responsible for the RBD persistence process and will automatically recover after completion. Blocking only occurs in the fork phase.
          • Bgsave uses write copy technology to generate snapshots while still processing commands normally.
          • Bgsave children are forked by the main process and can share all memory data from the main thread
      • Automatic trigger
        • At least n changes to the dataset in m seconds
    • File processing
      • save
        • The RDB file is saved in the directory of the dir configuration file. The filename is configured by dbfilename and can be dynamically executed during runtime by running the config set dir {newdir} command.
      • Compression: The LZF algorithm is used to compress RDB files by default
        • Through the config set rdbcompression yes | no configuration
    • The advantages and disadvantages
      • advantages
        • Compact compressed binary files
        • Represents only a snapshot of redis data at a point in time
        • Ideal for backup and full copy scenarios
          • For example, at some point every day bgSave is executed and RDB files are copied to a remote machine or file system for disaster recovery
      • disadvantages
        • Second/real-time persistence is not possible
        • Each time bgSave forks a child process, it is heavyweight
        • RDB files are saved in binary format. In the process of redis version evolution, there are multiple FORMATS of RDB versions. However, the redis server of the old version cannot be compatible with the new format
  • AOF
    • Each write command is recorded in its own log, and the command in the AOF file is executed again when the system restarts to recover data.
    • The main function of AOF is to solve the real-time of data persistence
    • process
      • All write commands are traced to the aOF_buf cache
      • The AOF cache synchronizes data to disks based on the corresponding policy
      • As AOF files become larger and larger, AOF files need to be rewritten periodically to achieve compression
      • When the Redis server restarts, AOF files can be loaded for recovery
    • How to use
      • Appendonly :yes is required to enable the AOF function
      • This function is disabled by default
      • The working process
        • Command to write
        • File synchronization
          • Redis provides multiple AOF cache synchronization file policies controlled by the appendfsync parameter:
            • always
              • After the command is written to aof_buf, the system fsync operation is invoked to synchronize the data to AOF. After fsync is complete, the thread returns
            • everysec
              • The fsync file synchronization operation is invoked once per second by a dedicated thread
            • no
              • The synchronization period is usually 30 seconds
        • Rewriting mechanism
          • As commands write to AOF, files get bigger and bigger. To solve this problem, Redis introduced AOF rewriting to reduce file size.
          • The AOF rewrite process can be triggered manually or automatically
            • Manual trigger
              • Call the bgrewriteaof command directly
              • Automatic trigger
                • Auto-aof -rewrite-min-size and auto-aof-rewrite-percentage parameters determine the automatic trigger time
        • Restart the load
        • File check