1. Introduction
1.1 Why
Redis is a key-value pair database server. The server usually contains any non-empty database, and each non-empty database can contain any key-value pair.
For convenience, we collectively refer to the non-empty databases in the server and their key-value pairs as the database state
The following figure shows a Redis server that contains three non-empty databases. These three databases and the key-value pairs in the databases are the database status of the server.
Because Redis is an in-memory database, it stores its own database state in memory, so if there is no way to save the database state stored in memory to disk, then once the server process exits, the The database state will also disappear
In order to solve this problem, Redis provides RDB persistence function, which can save Redis database state in memory to disk to avoid accidental data loss
1.2 How to realize the function
RDB persistence can be performed manually or periodically according to server configuration options. This function can save the database state at a certain point in time to an RDB file
The RDB file generated by the RDB persistence function is a compressed binary file, through which the database state when the RDB file is generated can be restored
Because the RDB file is saved in the hard disk, even if the Redis server process exits, or even the computer running the Redis server is shut down, as long as the RDB file still exists, the Redis server can use it to restore the database state
2. RDB file creation and loading
2.1 Related commands
1. save:
The SAVE command will block the Redis server process until the RDB file is created. During the blocking period of the server process, the server cannot process any command requests
2.besave
The BGSAVE command will spawn a child process, and then the child process is responsible for creating the RDB file, and the server process (parent process) continues to process the command request
3. Difference
pseudocode:
def SAVE(): # Create RDB document rdbSave() def BGSAVE(): # create child process pid = fork() if pid == 0: # The child process is responsible for creating the RDB document rdbSave() # Send a signal to the parent process when finished signal_parent() elif pid > 0: # The parent process continues to process command requests and waits for signals from the child process by polling handle_request_and_wait_signal() else: # Handle error conditions handle_fork_error()
Loading of 2.2rdb
Unlike using the SAVE command or the BGSAVE command to create an RDB file,
The loading of RDB files is automatically executed when the server starts, so Redis does not have a command specifically for loading RDB files. As long as the Redis server detects the existence of RDB files at startup, it will automatically load RDB file.
The following is the log record printed when the Redis server starts, and the second log DB loaded from disk:… is printed after the server successfully loads the RDB file
$ redis-server [7379] 30 Aug 21:07:01.270 # Server started, Redis version 2.9.11 [7379] 30 Aug 21:07:01.289 * DB loaded from disk: 0.018 seconds [7379] 30 Aug 21:07:01.289 * The server is now ready to accept connections on port 6
note1:
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.
3.RDB file structure
3.1 Overview
The file structure is as follows:
Parse:
1. REDIS
The beginning of the RDB file is the REDIS part, the length of this part is 5 bytes, and the five characters of “REDIS” are saved. Through these five characters, the program can quickly check whether the loaded file is an RDB file when loading the file
Because RDB files store binary data instead of C strings, for simplicity, we use the “REDIS” symbol to represent the five characters ‘R’, ‘E’, ‘D’, ‘I’, and ‘S’, and Not a C-string ‘R’, ‘E’, ‘D’, ‘I’, ‘S’, ‘\0’ with a ‘\0’ terminating character.
2.db_version
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. databases
The databases section contains zero or any number of databases, as well as the key-value pair data in each database:
·If the database status of the server is empty (all databases are empty), then this part is also empty, and the length is 0 bytes.
·If the database status of the server is non-empty (at least one database is non-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 also vary Varies
4.EOF
The length of the EOF constant is 1 byte. This constant marks the end of the content of the RDB file text. When the reading program encounters this value, it knows that all key-value pairs of all databases have been loaded.
5. check_sum
check_sum is an 8-byte unsigned integer that stores a checksum, which is calculated by the program through the contents of REDIS, db_version, databases, and EOF. When the server loads the RDB file, it will compare the checksum calculated by the loaded data with the checksum recorded by check_sum, to check whether the RDB file has errors or damage.
6. Summary
It shows an RDB file with an empty databases part: “REDIS” at the beginning of the file indicates that this is an RDB file, and “0006” after that indicates that this is the sixth version of the RDB file. Because the databases are empty, the version number is directly followed by EOF constant, the last 6265312314761917404 is the checksum of the file
3.2 Detailed explanation of databases
The databases part of an RDB file can save any number of non-empty databases
If database No. 0 and database No. 3 of the server are not empty, the server will create an RDB file as shown in the figure below. Database 0 in the figure represents all key-value pair data in database No. 0, while database 3 represents No. 3 All key-value pairs in the database
Each non-empty database can be saved as three parts: SELECTDB, db_number, key_value_pairs in the RDB file
Resolution:
1. SELECTDB
The length of the SELECTDB constant is 1 byte. When the reading program encounters this value, it knows that the next thing to be read will be a database number.
2.db_number
db_number stores a database number, and the length of this part can be 1 byte, 2 bytes or 5 bytes according to the size of the number. After the program reads the db_number part, the server will call the SELECT command to switch the database according to the read-in database number, so that the key-value pairs read in later can be loaded into the correct database
3. key_value_pairs
The key_value_pairs part saves all key-value pair data in the database. If the key-value pair has an expiration time, the expiration time will also be saved together with the key-value pair. Depending on the number, type, content, and expiration time of key-value pairs
4. Summary:
The following figure shows the structure of database 0 in the RDB file
The figure below shows a complete RDB file
3.2.1key_value_pairs
Each key_value_pairs part in the RDB file saves one or more key-value pairs. If the key-value pair has an expiration time, the expiration time of the key-value pair will also be saved.
key_value_pairs without expiration time
Analysis type:
REDIS_RDB_TYPE_STRING: string object
REDIS_RDB_TYPE_LIST: The bottom layer is the list list object
REDIS_RDB_TYPE_SET: The bottom layer is a collection object of hashtable
· REDIS_RDB_TYPE_ZSET: The bottom layer is the jump table ordered collection object
REDIS_RDB_TYPE_HASH: The bottom layer is a hash table object of a dictionary
REDIS_RDB_TYPE_LIST_ZIPLIST : The bottom layer is a list of compressed tables
REDIS_RDB_TYPE_SET_INTSET: set of underlying integer sets
REDIS_RDB_TYPE_ZSET_ZIPLIST: The bottom layer is an ordered list of compressed tables
REDIS_RDB_TYPE_HASH_ZIPLIST: The bottom layer is the hash table of the compressed table
Key pair value with expiration time
The meanings of the three parts TYPE, key, and value in the key-value pair with expiration time are exactly the same as the meanings of the three parts TYPE, key, and value in the key-value pair without expiration time introduced earlier. As for the new EXPIRETIME_MS and ms, their meanings are as follows:
The length of the EXPIRETIME_MS constant is 1 byte, it tells the program to read, the next thing to read will be an expiration time in milliseconds.
ms is an 8-byte signed integer that records a UNIX timestamp in milliseconds, which is the expiration time of the key-value pair (Unix timestamp is from January 1, 1970 Seconds since midnight in UTC/GMT, not taking leap seconds into account)
The knowledge points of the article match the official knowledge files, and you can further learn related knowledge MySQL entry skill tree Database composition Table 44939 people are studying systematically