Redis RDB persistence mechanism

RDB file creation and loading

RDB is the default persistence method of Redis. There are two Redis commands that can be used to generate RDB files, one is SAVE and the other is BGSAVE . The SAVE command will block the Redis server process until the RDB file is created. During the server process is blocked, the server cannot process any command requests:

Unlike the SAVE command that directly blocks the server process, the BGSAVE command spawns a child process, and the child process is responsible for creating the RDB file , and the server process (parent process) continues to process the command request:

It is also worth mentioning that because the update frequency of AOF files is usually higher than that of RDB files, if the server enables the AOF persistence function, the server will give priority to using the AOF file to restore the database state. Only when the AOF persistence function is turned off, the server will use the RDB file to restore the database state. The process for the server to determine which file to use to restore the database state is shown in the following figure.

1. Server status
   when the SAVE command is executed As mentioned earlier, when the SAVE command is executed, the Redis server will be blocked, so when the SAVE command is being executed, all command requests sent by the client will be rejected. Only after the server finishes executing the SAVE command and restarts accepting the command request, the command sent by the client will be processed.
2. Server status when the BGSAVE command is executed
   Because the saving of the BGSAVE command is executed by the child process, the Redis server can still continue to process the client's command request while the child process is creating the RDB file.
3. Server status when the RDB file is loaded The server
   will be in a blocked state during the loading of the RDB file until the loading task is completed.

During the execution of the BGSAVE command, how will the server execute the SAVE command sent by the client?

此命令会被服务器拒绝，因为这两个条件会产生竞争条件

During the execution of the BGSAVE command, how will the server execute the BGREWITEAOF command sent by the client?

BGREWITEAOF命令会等到服务器执行完BGSAVE命令再去执行

During the execution of the BGSAVE command, what happens if the client sends the BGSAVE command again?

会被服务器拒绝执行

RDB files are automatically saved at intervals

Earlier we introduced the SAVE command and the BGSAVE command, and explained the main difference between the two commands in terms of implementation: the SAVE command is performed by the server process to save work, and the BGSAVE command is performed by the child process. Therefore, the SAVE command will block the server. The BGSAVE command does not. Because the BGSAVE command can be executed without blocking the server process, Redis allows the user to set the save option of the server configuration to let the server automatically execute the BGSAVE command at regular intervals. The user can set multiple save conditions through the save option, but as long as any one of the conditions is met, the server will execute the BGSAVE command.

For example, we provide the following configuration to the server:

Then as long as any one of the following three conditions is met, the BGSAVE command will be executed:

• The server modified the database at least once within 900 seconds.
• The server made at least 10 changes to the database within 300 seconds.
• The server made at least 10,000 changes to the database within 60 seconds.

RDB file structure

The following figure shows the various parts of a complete RDB file:

1. The beginning of the RDB file is the REDIS part. This part is 5 bytes in length and holds five characters of "REDIS". Through these five characters, the program can quickly check whether the loaded file is an RDB file when loading the file.
2. The length of db_version is 4 bytes, and its value is an integer represented by a string. This integer records the version number of the RDB file. For example, "0006" means that the version of the RDB file is the sixth version.
3. The databases part contains zero or any number of databases, as well as the key-value pair data in each database;
   1. If the database status of the server is empty (all databases are empty), then this part is also empty, with a length of 0 byte.
   2. If the database status of the server is non-empty (at least one database is not empty), then this part is also non-empty. Depending on the number, type and content of key-value pairs stored in the database, the length of this part will vary. different.
4. The length of the EOF constant is 1 byte. This constant marks the end of the body content of the RDB file. When the reading program encounters this value, it knows that all key-value pairs in all databases have been loaded.
5. check_sum is an 8-byte long unsigned integer that stores a checksum, which is calculated by the program through the four parts of REDIS, db_version, databases, and EOF. When the server loads the RDB file, it compares the checksum calculated by the loaded data with the checksum recorded by check_sum to check whether the RDB file has errors or damages.

to sum up

• RDB files are used to save and restore all key-value pair data in all databases of the Redis server.
• The SAVE command executes the save operation directly by the server process, so this command will block the server.
• BGSAVE commands the child process to perform the save operation, so this command will not block the server.
• All the saving conditions set with the save option will be saved in the server status. When any saving condition is met, the server will automatically execute the BGSAVE command.
• The RDB file is a compressed binary file composed of multiple parts.
• For different types of key-value pairs, RDB files use different ways to save them.