Implementation of Redis single-machine database

Implementation of single-machine database

Principle

The Redis server saves all databases in the DB array of the server state redis.h/redisserver structure, each of which is a REDISDB structure, and each REDISDB structure represents a database. When initializing a server, the program determines how many databases should be created based on the Dbnum property of the server state, and the value of the Dbnum property is determined by the database option configured by the server, which, by default, has a value of 16, so the Redis server creates 16 databases by default.

Switch database

By default, the Redis client has a target database of number No. 0, but the client can switch the target database by executing the SELECT command.

Key space

Each database is represented by a REDIS.H/REDISDB structure, and the Dict Dictionary of the REDISDB structure holds all the key-value pairs in the database, which is called the key space. When you use the Redis command to read and write to a database, the server does not only perform the specified read and write operations on the key space, but also performs some additional maintenance operations. For example, after reading a key, the server will update the last use time of the key, this value can be used to calculate the idle time of the key, use the object Idletime command to see the key's idle time.

Set the lifetime or expiration of a key Expire/pexpire key time

Expiration key deletion policy for Redis: Lazy deletion and periodic deletion.

Lazy Delete: All commands to read and write to the database--Call the expireifneeded function--to determine if the input key has expired-yes, delete key

Periodic deletion: Periodically calls the Activeexpirecycle function, each time the function is run, a certain number of random keys are removed from a certain number of databases for checking, and the expiration key is removed. The global variable current_db records the current progress and invokes the last progress process at the next start.

Database notifications

Database notifications are new additions to the Redis2.8 version, allowing clients to subscribe to a given channel or pattern to learn about the changes in the keys in the database and the execution of commands in the database.

For example: [Email protected]_ _:message

RDB Persistence

Because Redis is an in-memory database that stores its own database state in memory, Redis provides the RDB persistence feature that enables Redis

The in-memory database state is saved to the disk to avoid accidental data loss. RDB persistence can be performed either manually or periodically, depending on the server configuration options, which can be used to save the state of the database at a point in time to an RDB file. RDB persistence generates an RDB file that is a compressed binary that enables you to restore the state of the database when an RDB file is generated. Because the Rdb file is saved in the hard disk, even if the Redis server process exits, even the computer running the Redis server is down, the Redis server can use it to restore the database state as long as the Rdb file is still present.

Create and load an RDB file

Both save and Bgsave can be used to generate an RDB file, and the Save command blocks the Redis server process until the Rdb file is created, and the server cannot process any command requests during server process blocking.

The Bgsave command derives a child process and then creates the Rdb file in a complex sub-process, and the server process continues to process the command request.

For different types of key-value pairs, the Rdb file is saved in a different way.

AOF Persistence

In addition to the RDB persistence feature, Redis also provides aof persistence. Persisted with RDB by saving the database state by storing the key-value pairs in the databases, AOF persistence records the database state by saving the write commands that the Redis server executes.

Because the update frequency of the AoF file is usually higher than the update frequency of the Rdb file,

If the server has AOF persistence enabled, the server will prioritize the use of the AoF file to restore the database state;

The server uses the Rdb file to restore the database state only when the AOF persistence feature is turned off.

Redis > SET msg "Hello"

Redis > Saddfruits "apple" "Banana"

Redis > Rpushnumbers 128 122 444

The RDB persistence saves the database state by saving the key value pairs of the msg, fruits, numbers three keys to the Rdb file, while the AOF persisting the database state is to save the set, Sadd, and Rpush three commands that the server executes into a aof file.

In order to improve the writing efficiency of the file, in the current operating system, when the user calls the Write function to write some data to the file, the operating system will usually temporarily save the write data in a memory buffer, until the buffer space is filled, or after the specified time limit, The data in the buffer is actually written to the disk.

While this approach improves efficiency, it also poses a security issue for writing data, because if the computer is down, the write data stored in the memory buffer will be lost.

To this end, the system provides Fsync and Fdatasync two synchronization functions, which can force the operating system to immediately write the data in the buffer to the hard disk, thus ensuring the security of writing data.

The value of the server configuration Appendfsync option directly determines the efficiency and security of the AOF persistence feature.

When the value of Appendfsync is always, the server writes all the contents of the AOF_BUF buffer to the aof file in each event loop, and synchronizes aof files, the slowest, but most secure. Even if a failure occurs, aof persistence will only lose the command data generated in an event loop.

EVERYSEC: The server writes all the contents of the AOF_BUF buffer to the aof file in each event loop, and synchronizes the aof files in the child thread every second. Efficiency is fast, and even if there is a failure, the database loses only one second of command data.

No: The Flushappendonlyfile call in no mode does not require a synchronous operation, so the aof file write speed in this mode is always the fastest. However, because this mode accumulates a period of write data in the system cache, the mode's single-sync duration is usually the longest of three.

Implementation of Redis single-machine database