Description of two Redis persistence Methods

Description of two Redis persistence Methods

Before talking about Redis persistence, you need to understand what is the concept of database status, because persistence is to save the database status in memory to the disk. So what is the database status? Redis is a key-value database server. Generally, there are 16 databases by default. You can use the select <index> command to switch (0-15 ), each non-empty database can contain any number of key-value pairs. For convenience, we usually set non-empty databases on the database server and their key-value pairs to [database status]. Therefore, persistence is not a database, but all non-empty databases on the server.

Next, let's continue to talk about two persistence methods of redis: RDB persistence and AOF persistence, both persistence methods can save the database status in the memory to the disk, but the principle is very different. Let's take a look at it one by one. First, let's talk about RDB persistence.

The default file name generated by RDB persistence is dump. rdb, which can be configured through the configuration file. The RDB file is a compressed binary file. Next we will introduce the rdb file structure. The RDB file contains five parts, redis, which starts with Redis | db_version | databases | EOF | check_sum, indicates that this is an RDB file. The server can quickly check whether the loaded file is an rdb file, and db_version indicates an integer, represents the version of the RDB file. The databases part contains 0 or any number of databases, and the key-value pair data in the database. If the database status is empty, this part is also empty, the structure of this part is as follows: [SELECTDB | db_number | key_values_pairs] SELECTDB is a constant with a length of one byte. When the server encounters this, we know that the data to be read will be a database number, and db_number stores the Database Number (0-15 ). In combination, you can switch to the corresponding database, and then read the correct key value. There are two types of structure of the key value pair, one with an expiration value, one is without an expiration value, if it is with an expiration value, then the structure is [EXPIRETIME_MS | MS | TYPE | key | value] The first constant is the same as SELECTDB, the second part is the UNIX timestamp in milliseconds, that is, the expiration time of the key-value pair. Then the TYPE records the value TYPE, which is String, list, set, zset, hash,. The structure of the key-value Pair without an expiration value does not have the first two parts, but it is only [TYPE | key | value]

RDB persistence can be executed manually through commands, or automatically executed by the server after configuration. You can run the Redis Command [SAVE] or [BGSAVE] manually, which has some differences, note that the "save" command will block the server process. However, when the "save" command is executed, the server cannot process any command requests. When the "save" command is executed, the RDB file is created, the bgsave command does not block the server. Instead, it derives a sub-process, and then the sub-process is responsible for creating the RDB file. The server process continues to process the command request. It should be noted that during the bgsave process, although the server process can continue to process command requests, the methods for processing the save, bgsave, and bgrewriteaof commands are different from each other. During bgsave, the save command is rejected by the server, the server prohibits both save and bgsave from being executed at the same time to prevent the Parent and Child processes from executing two rdbSave at the same time (the actual work of creating the RDB file is actually completed by the rdbSave function, and the save and bgs Ave will call this function, but the calling method is different. The bgsave command will be rejected during bgsave. The reason is the same as that for rejecting save. The two bgsave will also compete, the bgrewriteaof command is delayed until bgsave is executed.

Redis does not have a dedicated RDB file loading command. If the Redis server is enabled, it will check whether the RDB file exists and automatically load the RDB file, if the AOF persistence function is enabled on the server, the server first uses the AOF file to restore the database status. The RDB file is used to restore the database status only when the AOF persistence function is disabled.

Next, let's talk about RDB's automatic saving. As mentioned above, RDB can manually execute, SAVE, and BGSAVE commands, or enable the server to execute them automatically through configuration. How can we configure it?

Redis. conf can be configured. The default configuration is as follows:

Save 900 1
Save 300 10
Save 60 10000

The above indicates that,

• The service was modified at least once within 900 seconds.
• The server made at least 10 modifications within 300 seconds.
• The server was modified at least 10000 times within 60 seconds.

Any bgsave command that meets these conditions is automatically executed.

Then you may wonder, how does the server know how many modifications I have made? The server has a dirty counter and a lastsave timestamp.

After the server executes a database modification command, the dirty counter is updated. dirty increases the number of times the command modifies the database, for example, set msg hello, then dirty is added. If [mset msg word name nihao age 20], dirty is increased by three.

The lastsave attribute records the time when the last storage operation was performed on the server. It is a unix timestamp. With these two attributes, you can easily determine how long the last storage has been and how many times the database has been modified, once the preceding three conditions are met, the bgsave command is automatically called, and the lastsave and dirty attributes are updated to zero.

To check whether the storage conditions meet this requirement, the periodic operation function serverCron of the Redis server performs a check at a default interval of 100 milliseconds. This function is used in many places. Pay attention to it, this function is a maintenance function for the running server. It will be mentioned in the Redis event (Redis Server is an event-driven program. What is event-driven? It will only be triggered when an event occurs. Otherwise, it will be the same as death. Event drivers are divided into file events and time events. ServerCron is a time-driven. As for file-driven, in fact, the server will execute a command sent by the client and then return the result to the client)

Finally, Redis itself comes with an RDB File check Tool redis-check-dump, which can be used to check whether the rdb file is complete.

Install and test Redis in Ubuntu 14.04

Redis cluster details

Install Redis in Ubuntu 12.10 (graphic explanation) + Jedis to connect to Redis

Redis series-installation, deployment, and maintenance

Install Redis in CentOS 6.3

Learning notes on Redis installation and deployment

Redis. conf

Redis details: click here
Redis: click here

This article permanently updates the link address: