Example analysis of Redis persistence mechanism

Redis stores data in memory, and the data will be lost when the process exits. Through Redis's persistence mechanism, data in memory can be stored on disk, and data can be loaded from disk files to refill the memory after a restart.

Redis supports two persistence mechanisms: full mirror RDB and incremental persistence AOF.

RDB is a snapshot of Redis, which stores all unexpired key-value pairs in Redis.

Configure RDB in redis.conf:

dbfilename dump.rdb
dir /var/lib/redis



save 900 1 save 300 10 save 60 10000 save "" stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes

Every time the redis process starts, it will first check whether the rdb file exists, and if it exists, load the contents of the file. into memory.

When redis automatically updates the RDB file, it will fork a sub-process to perform snapshot saving. During the saving period, the main process can provide services normally.

We can also save the snapshot through the command:

• save: Save the snapshot in a blocking manner, and redis cannot handle other requests during the save period

• bgsave: Fork a child process to complete the saving work. The normal service of redis will not be affected during the saving period. The

lastsave command can get the latest RDB file creation timestamp, which can be used to check whether the save is successful.

RDB is a database snapshot, and each time it is created, the entire database needs to be written to the file. This is a very time-consuming operation, so it is difficult to perform frequently, and a large amount of data may be lost when an exception occurs.

Redis provides the incremental persistence tool AOF (Append Only ile). AOF performs persistence by recording all write instructions in the Redis database. Instructions are stored in the AOF file in the format of the Redis communication protocol.

When the Redis process starts, it will check whether the AOF file exists. If it exists, the instructions in the AOF will be executed sequentially to restore the data.

Redis will add a log to the AOF file every time it executes a write command, but the new record will not be written to disk immediately (fsync) but cached in the write buffer.

We can configure the strategy of writing the data in the buffer to disk to avoid data loss.

Writing data in the buffer to disk is a time-consuming operation. Frequent disk writing will affect performance, but Redis crashes and loses less data, so we need to make trade-offs based on application scenarios.

AOF may record redundant instructions. If we execute the set instruction 100 times for the same key, there will be 100 records in the AOF file but only the last set instruction will be retained to recover the data. AOF rewriting will organize the AOF file, clean up unnecessary command logs (such as deleting overwritten set commands), and reduce the size of the AOF file.

redis adopts a background rewriting strategy, that is, forking a child process to write the sorted AOF into a temporary file. Use BGREWRITEAOF to manually trigger the background rewrite operation.

Actually AOF rewriting will not read the original AOF file. The child process will have a copy of the current data and directly generate a new AOF file based on the copy.

During the rewriting period, the main process writes the new write operations into the original AOF file and AOF rewrite cache. Even if the rewriting fails, the original AOF file still saves complete data. When the child process completes AOF rewriting, it will send a signal to the main process. After receiving the signal, the main process will write the contents of the AOF rewriting cache into a new AOF file, and then overwrite the original file with the new AOF file.

Configure AOF in redis.conf:

appendonly yes  
  

appendfilename appendonly.aof  
  


appendfsync everysec 

    no-appendfsync-on-rewrite no   
  


auto-aof-rewrite-percentage 100  
  

auto-aof-rewrite-min-size 64mb

Redis will record the size of the AOF file at startup or after the last rewrite. If the size of the new data reaches 100% of the original size (auto-aof-rewrite-percentage configuration) triggers rewriting.

The rewrite operation will only be performed when the current AOF file size is greater than auto-aof-rewrite-min-size. Otherwise, rewriting will not be performed even if the amount of new data exceeds the specified percentage. This avoids the problem of frequent initial rewriting caused by the original file being too small.

The above is the detailed content of Example analysis of Redis persistence mechanism. For more information, please follow other related articles on the PHP Chinese website!