Summary of redis AOF and RDB knowledge points

Redis AOF And RDB Summary of knowledge points

Redis There are two ways to persist ：AOF And RDB

AOF

AOF Storage mode

AOF It records every write command in the form of a log , Every write command executed by the client will be recorded AOF journal , Be similar to MySQL binlog.

AOF Data recovery

In case of downtime and restart ,Redis Will be executed in sequence AOF All write commands in the log are used for data recovery （ Operation playback ）.

AOF And WAL The difference between

Relational databases are mostly used WAL Prewrite log （ Write a Prelog ）, Write the log , Then execute the statement . and Redis Of AOF It's a post log , First update the data in memory , Then insert this write command AOF In the log .

• Why? Redis Using post write log ？

Execute the write command first , Then write the command to AOF journal , If the command is invalid , You can directly return to , No write required AOF journal . Doing so prevents invalid commands from being written AOF Log files , Reduce AOF The space occupied by the file .

AOF Rewrite mechanism

because AOF It stores Redis Every operation command of , The volume of the file increases over time , In case of downtime , Too much AOF The log will cause the playback speed of the operation to slow down after restart . In order to reduce disk space occupation and speed up operation playback ,Redis Will be rewritten periodically AOF.

• AOF How to lose weight ？

example ：
If a key value pair is modified repeatedly ,Redis In rewriting AOF The previous modification command will be changed from AOF Delete , Only the last modification command is reserved .
If a key value pair is modified many times , Finally, it was deleted , that Redis In rewriting AOF All write commands related to the key value pair will be deleted .

• AOF Rewrite process

Redis Will execute fork() Operation to create a subprocess , Specially responsible for AOF Rewrite operation . At the same time, considering that there may be new write commands in the rewriting process ,Redis For this AOF The rewriting process opens a rewriting buffer separately . If there's a new write command , This command will be inserted at the same time AOF buffer （ The main process ） And AOF Rewrite buffer （ Subprocesses ）. In the process of rewriting ,AOF The operation commands received in the rewrite buffer will be sent to AOF Override subprocesses .AOF The rewriting subprocess will rewrite the original AOF Data and from AOF Rewrite the new data in the buffer and write new AOF Log files , Finally replace the old AOF file , The whole rewriting process is over .

• fork What is it? ？
  fork() yes unix and linux One of the advantages of this operating system api, instead of Redis Of api.

• fork The role of
  fork() Used to create a child process （ Notice that it's a subprocess , Not a child thread ）.fork() The resulting process shares the memory data of its parent class . Be careful ： Share only fork() The memory data at the moment when the child process is released , Later, the modified data of the main process is not visible to the child process , Empathy , The data modified by the child process is not visible to the main process .

AOF The strategy of disk brushing

appendfsync：aof Configuration of persistence policy ;

• no Means not to execute fsync, It is up to the operating system to decide when to synchronize data to disk , The fastest , But it's not safe .

• always Indicates that every write is executed fsync, Make sure the data is synchronized to disk , Efficiency is very low .

• everysec Represents one execution per second fsync, You may lose this 1 Second data . General choice everysec , It can give consideration to both safety and efficiency .

RDB

RDB Storage form of

Binary , It's smaller .

RDB Persistence mode

RDB Is to take a snapshot of the data set in the current memory （ All key value pair data ） Write to disk .

RDB Data recovery method

Load binary files into memory .

RDB Trigger mode

• Automatic triggering
  Configure in profile RDB trigger

save 900 1： Express 900  Second if there is at least  1  individual  key  Change in value of , Save 
save 300 10： Express 300  Second if there is at least  10  individual  key  Change in value of , Save 
save 60 10000： Express 60  Second if there is at least  10000  individual  key  Change in value of , Save 

After the trigger conditions are met ,Redis Will execute bgsave Conduct RDB Persistence .

• Manual trigger
  Manual trigger RDB There are two commands ：
  （1）、save： perform save The command will block Redis service , stay RDB Before persistence is complete ,Redis You can't do anything .
  （2）、bgsave：save An improved version of . perform bgsave after ,Redis Will first judge whether there is currently fork() Child processes coming out . If the child process exists , Then ignore the bgsave command , If the child process does not exist ,Redis Will execute fork() Operation to create a subprocess , asynchronous RDB Persistence , While persisting ,Redis The service is still working . Only execute fork There will be a jam at the moment of .

bgsave Memory sharing between main process and sub process ：
bgsave When creating a subprocess , It is impossible to copy a copy of the data in the main process to the child process （ Too much memory , Double directly ）. therefore Redis Adopted copyonwrite Technology to realize that the main process and sub process share memory data .

The details of memory sharing can be found in this article ：
https://blog.csdn.net/ctwctw/article/details/105147277