Advantages and disadvantages of RDB and AOF

Redis Provides different levels of persistence :
RDB Persistence allows you to store snapshots of your data at specified intervals .
·AOF Persist to record every write to the server , These commands are reexecuted when the server restarts to restore the original data ,AOF Command to redis Protocol append saves each write to the end of the file .Redis Also able to AOF The file is rewritten in the background , bring AOF The size of the file should not be too large .
· If you only want your data to exist when the server is running , You can also do it without any persistence .
· You can also turn on two persistence methods at the same time , under these circumstances , When redis It will be loaded prior to restart AOF File to restore the original data , Because in general AOF The data set saved by the file is better than RDB The data set of the file should be complete .
· The most important thing is to understand RDB and AOF Different ways of persistence , Let's take RDB Persistent party
Style start :

RDB

RDB The advantages of ：

·RDB It's a very compact file , It holds the data set at a certain point in time , Very suitable for data set backup , For example, you can save the past in every small times 24 Data in hours , And save the past every day 30 Days of data , In this way, even if there is a problem, you can recover to different versions of datasets according to your needs .
·RDB It's a compact single file , It's easy to transfer to another remote data center or Amazon's S3( It could be encrypted ), Ideal for disaster recovery .
·RDB In preservation RDB The only thing the parent process needs to do when it files is fork Make a sub process , The next work is all done by subprocesses , The parent process doesn't need to do anything else lO operation , therefore RDB Persistence can maximize redis Performance of .
· And AOF comparison , When recovering large datasets ,RDB The way will be faster .

RDB The shortcomings of ：·

If you want to redis Stop working unexpectedly （ For example, the power supply is interrupted ) In the case of the least data lost , that RDB Not for you. . Although you can configure different save Point in time ( For example, every 5 Minutes and for the dataset 100 A write operation ), yes Redis It's a lot of work to save the whole data set completely , You usually do it every 5 Make a complete save in minutes or more , In case of Redis Unexpected downtime , You may lose a few minutes of data .
·RDB Need to often fork Subprocess to save the data set to the hard disk , When the data set is large fork The process is very time consuming , May lead to Redis Can't respond to client requests in milliseconds . If the data set is huge and CPU When the performance is not very good , This situation will continue 1 second ,AOF Also needed fork, But you can adjust the frequency of rewriting the log file to improve the durability of the dataset .

AOF 

AOF The advantages of ：

· Use AOF Will let you Redis More durable : You can use different fsync Strategy : nothing fsync, Per second fsync, Every time I write fsync. Use the default per second fsync Strategy ,Redis The performance is still very good (fsync It is processed by the background thread , The main thread will try its best to handle client requests ), In case of failure , The most you lose 1 Second data .
·AOF A file is a log file that only appends , So there's no need to write seek, Even for some reason ( Disk space is full , Downtime during writing, etc ) The full write command was not executed , You can also use redis-check-aof Tools to fix these problems .
·Redis Can be in AOF When the file size becomes too large , Automatically in the background AOF Rewrite : The rewritten new AOF The file contains the minimum set of commands required to recover the current dataset . The whole rewrite operation is absolutely safe , because Redis Creating a new AOF In the process of documentation , Meeting
Continue to append the command to the existing AOF In the document , Even if there is a outage during the rewrite , The existing AOF Documents will not be lost . And once it's new AOF File creation complete ,Redis From the day AOF File switch to new AOF file , And start on the new AOF File to append .
·AOF The file holds all writes to the database in an orderly manner , These write operations to Redis The format of the protocol is saved , therefore AOF The contents of the document are very easy to read , Analyze the document (parse) It's easy too . export
(export)AOF The document is also very simple
single : for instance , If you don't execute it carefully FLUSHALL command , But as long as AOF The file has not been rewritten , So just stop the server , remove AOF At the end of the document FLUSHALL command , And restart Redis, You can restore the dataset to FLUSHALL Status before execution .

 AOF The shortcomings of ：
· For the same dataset ,AOF The volume of the file is usually larger than RDB Volume of file .
· According to the fsync Strategy ,AOF May be slower than RDB. In general , Per second fsync Performance is still very high , Shut down fsync It can make AOF Speed and RDB As fast as , Even under high load . But when dealing with large write loads ,RDB More guaranteed maximum delay time (latency).