Differences between RDB and AOF for redis persistence

Persistence is RDB

Definition ： Generates a point-in-time snapshot of the dataset at a specified interval

RDB The advantages of :

1.RDB It's a very compact file

It has been saved. Redis Data set at a certain point in time . This kind of file is very suitable for backup ： for instance , You can be in the nearest 24 Within hours , Back up every hour RDB file , And every day of every month , Also back up one RDB file . In this case , Even if there is a problem , You can also restore datasets to different versions at any time .

2.RDB Ideal for disaster recovery

It has only one file , And the content is very compact , Sure （ After encryption ） Send it to another data center , Or Amazon S3 in .

3.RDB Can be maximized Redis Performance of

The parent process is saving RDB The only thing to do when you file is fork Make a sub process , Then this subprocess will handle all the subsequent saving work , The parent process does not need to execute any disks I/O operation .

4.RDB Speed ratio when recovering large data sets AOF It's faster to recover .

RDB The shortcomings of

If you need to try to avoid losing data in the event of a server failure , that RDB Not for you. . although Redis Allows you to set different save points to control save RDB File frequency , however , because RDB The file needs to save the state of the entire dataset , So it's not an easy operation . So you may at least 5 Minutes to save RDB file . under these circumstances , In the event of a breakdown stop , You could lose a few minutes of data .

Every time you save RDB When ,Redis Both fork() Make a sub process , And it's up to the subprocesses to do the actual persistence work . When the data set is large , fork() It can be very time consuming , Cause the server to stop processing the client in a millisecond ; If the data set is very large , also CPU When time is very tight , So this kind of stop time may even be as long as a whole second . although AOF Rewriting also requires fork() , But no matter AOF How long is the execution interval of the rewrite , There will be no loss of data durability .

---

AOF The advantages of

Use AOF Persistence makes Redis Become very durable ： You can set different fsync Strategy , Like none fsync , Once per second fsync , Or every time a write command is executed fsync . AOF The default policy for is per second fsync once , In this configuration ,Redis Still maintain good performance , And even in the event of a breakdown , And only lose one second of data at most （ fsync Will execute in the background thread , So the main thread can continue to work hard on command requests ）.

AOF A file is a log file that only appends , So right. AOF Writing files does not need to be done seek , Even if the log contains commands that are not written completely for some reason （ For example, the disk is full when writing , Write stoppage , wait ）, redis-check-aof Tools can also easily fix this problem .

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 , Will 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 old 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 , It's also easy to analyze files . export AOF The documents are also very simple ： 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 .

AOF This has happened in the past bug ： Because of individual orders , Lead to AOF When the file is reloaded , Unable to restore the dataset as it was when it was saved . （ for instance , Blocking order BRPOPLPUSH It has caused such bug .） The test suite adds tests for this situation ： They will automatically generate random 、 Complex datasets , And by reloading the data to make sure everything is OK . Although this kind of bug stay AOF Not common in documents , But by contrast , RDB This is almost impossible bug Of .

---

summary ：rdb and aof Advantages and disadvantages

RDB The advantages of

1. A smaller ： The same amount of data rdb Data ratio aof Small , because rdb It's a compact file

2. Faster recovery ： because rdb Is a snapshot of data , Basically, it's data replication , No need to re read and write to memory

3. Higher performance : The parent process is saving rdb Time just fork A subprocess , There is no need for the parent process to carry out other io operation , It also guarantees the performance of the server .

RDB The shortcomings of

1. Fault loss : because rdb It's a total of , We usually use shell Script implementation 30 Minutes or 1 Hours or every day redis Conduct rdb Backup , But at least 5 Backup every minutes , So when the service dies , At least lose 5 Minute data .

2. Poor durability : relative aof For the asynchronous strategy , because rdb The replication of is full , Even if it's fork For backup , When the amount of data is large, the consumption of disk can not be ignored , Especially when the traffic is high ,fork The time will also be extended , Lead to cpu Tighten up , The durability is relatively poor .

aof The advantages of

1. Data assurance ： We can set fsync Strategy , The general default is everysec, You can also set each write to append , So even if the service dies , We can also lose one second of data at most

2. Auto zoom out ： When aof When the file size reaches a certain level , The background will automatically execute aof rewrite , This process will not affect the main process , After rewriting , New writes will be written to new aof in , The old ones will be deleted . But if this article is compared rdb There is still no need to count it as an advantage , It's just that the official website shows advantages .

aof The shortcomings of

1. Relatively poor performance ： Its operation mode determines that it will be right redis The performance of has been lost

2. Relatively larger ： Although it will aof The file was rewritten , But after all, there is still a big difference between the operation process and the operation result , The volume is undoubtedly larger .

3. Slower recovery

---

Final summary

redis There are two ways to persist ,aof and rdb,aof Equivalent to logging operation command ,rdb Equivalent to a snapshot of data . In terms of safety, due to aof The record of can be added accurately to the second level or even one by one , and rdb Only full copy ,aof Significantly higher than rdb. But in terms of performance rdb Just a little better ,rdb yes redis Performance maximization , It does not monitor whether data is written every second , When the trigger condition is reached, it will automatically fork A child process carries out full update , It's also very fast . Disaster recovery rdb It can recover data quickly , and aof Need to read and then write , Relatively slow .