In operation , Redis Keep data in memory in the form of data structures , In order to make these data in Redis Still available after reboot , Redis Respectively provided RDB and AOF Two persistence patterns .

RDB

stay Within a specified time interval Put the data set in memory Snapshot write to disk , namely snapshot, Data recovery is to read the snapshot file directly into memory .

Redis Will create… Separately （fork） A subprocess to persist , Write the data to a temporary file first , When the persistence process is over , Replace the last persistent file with this temporary file .

fork Its function is to copy the same process as the current process . All the data for the new process （ Variable 、 environment variable 、 Program counter, etc ） The values are consistent with the original process , But it’s a whole new process , And as a child of the original process .

The whole process , The main process is not going to do anything IO Operation of the , This ensures extremely high performance .

If large-scale data recovery is needed , And it’s not very sensitive to the integrity of data recovery , that RDB The way is better than AOF It’s more efficient .

RDB The disadvantage is that the data may be lost after the last persistence .

About RDB Of Related configuration Can be found in redis.conf(Linux Next ) Medium SNAPSHOTTING Part of it

################################ SNAPSHOTTING ################################
#
# Save the DB on disk:
#
# save <seconds> <changes>
#
# Will save the DB if both the given number of seconds and the given
# number of write operations against the DB occurred.
#
# In the example below the behaviour will be to save:
# after 900 sec (15 min) if at least 1 key changed
# after 300 sec (5 min) if at least 10 keys changed
# after 60 sec if at least 10000 keys changed
#
# Note: you can disable saving completely by commenting out all "save" lines.
#
# It is also possible to remove all the previously configured save
# points by adding a save directive with a single empty string argument
# like in the following example:
#
# save ""
save 900 1
save 300 10
save 60 10000

The above save 900 1 Equal parameters are used to represent

900 Within seconds 1 When I write an order , Enable snapshot backup

300 Within seconds 10 When I write an order , Enable snapshot Backup

60 Within seconds 10000 When I write an order , Enable snapshot Backup

In addition to the above automatic backup , You can also use the command to back up ,

Redis Two commands are provided for saving ,SAVE and BGSAVE

SAVE

SAVE Call directly rdbSave , Blocking Redis The main process , Until the save is complete . During the main process block , The server cannot process any requests from the client .

BGSAVE

fork Make a sub process , The subprocess is responsible for calling rdbSave , And send a signal to the main process after saving , Notification save completed . because  

rdbSave When a subprocess is called , therefore Redis The server BGSAVE The client’s request can still be processed during execution .

In addition, execute flushall command , There will be dump.rdb file , But it’s empty , meaningless .

It can also be configured through dbfilename, modify rdb File name , The default is dump.rdb

AOF

In the form of an agreement , All commands that have been written to the database （ And its parameters ） It was recorded that AOF file , In order to achieve the purpose of recording the state of the database .

Synchronize command to AOF The whole process of documentation can be divided into three stages ：

1. Command propagation ：Redis The order that will be executed 、 Arguments to the command 、 The number of parameters of the command and other information are sent to AOF In the program .
2. Cache append ：AOF The program according to the received command data , Convert command to network protocol format , Then append the protocol content to the server’s AOF In cache .
3. File write and save ：AOF The contents of the cache are written to AOF end of file , If it’s set AOF If the preservation conditions are met , fsync  Function or  fdatasync  Function will be called , Save what you write to disk .

By default AOF The backup mode of is not enabled , Need modification redis.conf In the document appendonly no It is amended as follows appendonly yes

The generated file defaults to configuration appendfilename “appendonly.aof” Medium appendonly.aof, stay Redis It will be reloaded after reboot .

When you meet aof When the file is damaged （ Such as ：aof The file contains incorrect instructions, etc ）, have access to redis-check-aof –fix Make repairs .

rewrite

AOF By means of document addition , The documents will become larger and larger to avoid this , New rewrite mechanism , When AOF When the file size exceeds the set threshold ,Redis Will start AOF The content of the file is compressed , Keep only the smallest instruction set that can recover data . You can use commands bgrewriteaof

AOF When files continue to grow and become too large , Meeting fork A new process to rewrite the file ( Also write temporary documents first and then rename),
Traverse the data in memory of the new process , Each record has one Set sentence . rewrite aof Operation of file , Not reading the old aof file ,
Instead, the database contents in the whole memory are rewritten with a new command aof file , It’s a bit like a snapshot

The trigger conditions for rewriting are also in redis.conf There is a configuration… In the file

auto-aof-rewrite-percentage 100 Represents the same as the last rewritten AOF File size compared to , The current file growth exceeds the last AOF File size 100% when , Trigger override

auto-aof-rewrite-min-size 64mb Specifies the AOF file size , if AOF The file is less than this value , Even satisfy auto-aof-rewrite-percentage 100 Conditions , Automatic override will not be triggered .

Two conditions are satisfied at the same time before rewriting

By modifying the above two configurations , You can change the conditions that trigger override

conclusion

RDB

advantage ：  1. Suitable for large-scale data recovery
            2. The requirements for data integrity and consistency are not high

Inferiority ： 1. Make a backup at regular intervals , So if redis accident down If you drop it , All changes since the last snapshot will be lost

            2.fork When , The data in memory is cloned , roughly 2 Double expansion needs to be considered

AOF

advantage ： Sync per change ：appendfsync always    Synchronous persistence Every time there is a data change, it will be recorded to the disk immediately , Poor performance but good data integrity

A second synchronous ：appendfsync everysec    Asynchronous operations , Record every second     If it goes down in a second , There is data loss
Out of sync ：appendfsync no    No synchronization

Inferiority ： 1.aof Operating efficiency is slower than rdb, The efficiency of synchronization strategy per second is better , Out of sync efficiency and rdb identical

            2. Data from the same data set aof Documents are much larger than rdb file , Recovery is slower than rdb