1.RDB AOF difference

RDB persistence refers to writing a snapshot of the data set in memory within a specified time interval In the disk, fork a child process and first write the data set into a temporary file. After the writing is successful, the previous file is replaced and stored using binary compression.

Specific operation: traverse the hash table, use copy on write, and save the entire db dump.
save, shutdown, slave commands will trigger this operation.
Features: The granularity is relatively large. If save, shutdown, and slave crash before, the intermediate operations cannot be restored.

AOF persistence records every write and delete operation processed by the server in the form of a log. Query operations are not recorded, but are recorded in text. You can open the file to see detailed operation records. Redis can also rewrite the AOF file in the background so that the size of the AOF file does not exceed the actual size required to save the data set state. Redis can also use AOF persistence and RDB persistence at the same time. In this case, when Redis restarts, it will give priority to using the AOF file to restore the data set, because the data set saved by the AOF file is usually more complete than the data set saved by the RDB file. You can even turn off persistence so that the data only exists while the server is running.

Features: The granularity is small. After a crash, only operations that did not have time to log before the crash cannot be recovered.

The selection criterion is to see whether the system is willing to sacrifice some performance in exchange for higher cache consistency (aof), or whether it is willing to not enable backup in exchange for higher performance when write operations are frequent. It will be manually When running save, make a backup (rdb). RDB has a more eventually consistent meaning.

2. AOF RDB advantages and disadvantages

AOF:

Advantages: Using AOF persistence will make Redis very durable (much more durable): you can set different fsync strategy, such as no fsync, fsync once per second, or fsync every time a write command is executed. The default policy of AOF is to fsync once per second. Under this configuration, Redis can still maintain good performance, and even if a failure occurs, only one second of data will be lost at most (fsync will be executed in a background thread, so The main thread can continue to work hard processing command requests). The AOF file is a log file that only performs append operations (append only log), so writing to the AOF file does not require seeking, even if the log contains incomplete commands for some reasons (for example, when writing to the disk is full, writing is stopped midway, etc.), the redis-check-aof tool can also easily fix this problem.
Redis can automatically rewrite the AOF in the background when the AOF file size becomes too large: the new AOF file after rewriting contains the minimum set of commands required to restore the current data set. The entire rewriting operation is absolutely safe, because Redis will continue to append commands to the existing AOF file during the process of creating a new AOF file. Even if there is a shutdown during the rewriting process, the existing AOF file will not be lost. . Once the new AOF file is created, Redis will switch from the old AOF file to the new AOF file and start appending to the new AOF file. The AOF file saves all write operations performed on the database in an orderly manner. These write operations are saved in the format of the Redis protocol. Therefore, the content of the AOF file is very easy to read and it is easy to analyze the file (parse). Exporting (exporting) AOF files is also very simple: for example, if you accidentally execute the FLUSHALL command, but as long as the AOF file has not been overwritten, then just stop the server, remove the FLUSHALL command at the end of the AOF file, and restart Redis. You can restore the data set to the state before FLUSHALL was executed.

Disadvantages:
For the same data set, the size of the AOF file is usually larger than the size of the RDB file.Depending on the fsync strategy used, AOF may be slower than RDB. Under normal circumstances, the performance of fsync per second is still very high,and turning off fsync can make AOF as fast as RDB, even under high load.However, RDB can provide a more guaranteed maximum latency when handling huge write loads. AOF has had such a bug in the past: due to individual commands, when the AOF file is reloaded, the data set cannot be restored to the original state when saved. (For example, the blocking command BRPOPLPUSH once caused such a bug.) Tests have been added to the test suite for this situation: they automatically generate random, complex data sets and reload these data to ensure that everything normal. Although this kind of bug is not common in AOF files, in comparison, it is almost impossible for RDB to have this kind of bug.

Advantages of RDB:
RDB is a very compact file that saves the Redis data set at a certain point in time.This kind of file is very suitable for backup: for example, you can back up an RDB file every hour in the last 24 hours, and also back up an RDB file every day of the month. This way, even if you encounter a problem, you can always restore the data set to a different version. RDB is great for disaster recovery: it has only one file, and the contents are very compact, and it can be transferred (after encryption) to other data centers, or to Amazon S3. RDB can maximize the performance of Redis: the only thing the parent process has to do when saving the RDB file is to fork out a child process, and then the child process will handle all subsequent saving work, and the parent process does not need to perform any disk I/O operations. . RDB is faster than AOF when restoring large data sets.

Disadvantages:
If you need to avoid losing data when the server fails, then RDB is not suitable for you. Although Redis allows you to set different save points to control the frequency of saving RDB files, it is not an easy operation because RDB files need to save the state of the entire data set. So you may save the RDB file at least once every 5 minutes. In this case, in the event of an outage, you may lose several minutes of data. Every time the RDB is saved, Redis must fork() a child process, and the child process will perform the actual persistence work. When the data set is large, fork() may be very time-consuming, causing the server to stop processing the client within a certain millisecond; if the data set is very large and the CPU time is very tight, then this stop time may even be longer. for a full second. Although AOF rewriting also requires fork(), no matter how long the execution interval of AOF rewriting is, there will be no loss in data durability.