A description of the two persistence modes of Redis

Before you say Redis persistence, you need to figure out what the concept of database state is, because the persistence is to save the state of the database in memory to disk. So what is the database state? Redis is a key-value database server, typically by default there are 16 databases that can be switched using the Select <index> Command (0-15), and each Non-empty database can contain any number of key-value pairs, for convenience purposes, We typically use the Non-empty database in the database server and their key-value pairs as "database state," so this is persisted, not a database, but all Non-empty databases on the server.

Then, we continue to talk about two ways of Redis, one is RDB persistence, the other is aof persistence, both of which can save the state of the database in memory to disk, but the principle is very different, let's take a look at, first of all, the rdb of persistence.

Rdb The default generated file name is Dump.rdb, which can be configured by configuration file, Rdb file a compressed binary file, and then introduce some RDB file structure, RDB file contains five parts, respectively, "Redis |  db_ Version  |  databases | EOF | Check_sum "The beginning of the Redis that this is a RDB file, the server can quickly check whether the loaded file is a Rdb file, Db_version is an integer, representing the Rdb file version, the databases part contains 0 or any number of databases, and the key value pairs of data in the database, if the database state is empty, then this part is also empty, this part of the structure is as follows "Selectdb | Db_number | Key_values_pairs "where Selectdb is a constant, the length is a byte, and when the server encounters this, it knows that the next thing to read will be a database number, db_ Number is stored in a database (0-15) The two parts of the combination can be switched to the corresponding database, then read the key value pairs, the key pairs of the part of the structure of the two types, one with the expiration value, one is not with the expiration value, if it is with the expiration value, then the structure is "expiretime_ MS | Ms |  type | Key | Value "The first constant is the same as SELECTDB, the second part is a Unix timestamp in milliseconds, that is, the expiration time of the key value pair, and then the type records the types of value, String,list,set,zset,hash, and so on. A key value pair with no expiration value is not the first two parts of the structure, just the TYPE | Key | Value '

RDB persistence can be performed manually by a command, or it can be configured to automate the server, manual execution can use the Redis command "SAVE" or "bgsave", there are some differences between the two commands, which need to be explained that the SAVE command blocks the server process and says, However, when the Save command executes, the server is not able to process any command requests, knowing that the Save command completes, the Rdb file is created, the Bgsave command does not block the server, but by deriving a subprocess, and then the child process is responsible for creating the Rdb file, the server process continues processing the command request, It should be explained here that while the server process can continue to process command requests during bgsave processing, the save,bgsave,bgrewriteaof three commands will be handled differently than usual, and the Save command will be rejected by the server during Bgsave. The server prohibits save and bgsave from executing at the same time, avoiding the simultaneous execution of two rdbsave between the parent process and the subprocess (the actual work of creating RDB files is actually done by the Rdbsave function, save and Bgsave will call this function, just the way it is invoked), The Bgsave command will also be rejected during Bgsave, as is the case with the rejection of Save, where two bgsave also compete, and the bgrewriteaof command is deferred until Bgsave executes.

Redis does not have a special RDB file Load command, as long as the Redis server on, will detect the existence of RDB file, will automatically load the Rdb file, here to note that if the server turned on the AOF persistence function, the server will use the AoF file to restore the database status, The Rdb file is used to restore the database state only when the AOF persistence feature is turned off.

Next, Rdb automatically save, as has been said before, RDB can be manually executed, save command and Bgsave command, can also be configured to let the server automate, then how to configure it.

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

Save 900 1
Save
60 10000

The above means that the service has been modified at least once within 900 seconds

Server has been modified at least 10 times in 300 seconds

The server was modified at least 10,000 times within 60 seconds.

These conditions satisfy any one of the Bgsave commands that are automatically executed.

Then you might be wondering how the server knows how much I've made changes. There is a dirty counter and a lastsave timestamp in the server

When the server executes a database modification command, the dirty counter is updated, the number of times the database is modified, and the number of dirty increases, such as "Set msg Hello" modifies one, then dirty adds one if "Mset msg word name Nihao age 20 "then dirty will increase by three.

The Lastsave property records the last time the server performed the save operation, a Unix timestamp, which, through these two properties, can be a very simple distance from the last time it was saved, and how many times the database was modified, and the Bgsave command is automatically invoked once the above three conditions are met. Update both the Lastsave property and the dirty property to zero.

As for checking whether the save condition satisfies this work, is by the Redis server periodic operation function Servercron The default interval 100 milliseconds to perform a check, this function has many places to use, notes, this function is the function which maintains to the running server, It is mentioned in the Redis event that the Redis server is an event driver and what is the event driver. is when the event will move, or just like dead, event-driven and is divided into file events and time events, Servercron is a kind of time-driven, as for file-driven, in fact, is the client sent a command, the server will go to execute, and then to the client return results.

Finally, Redis itself has a Rdb file checking tool redis-check-dump that can be used to check RDB file integrity.