The internal structure of Redis

The internal structure of Redis is shown in the following figure:

The function modules are described as follows:

File event: Processing of files events (multiplexing in multiple clients, accepting command requests from them (read events), and returning command execution results to clients (write events))

Time Event: Temporal events (UPDATE statistics, cleanup of outdated data, secondary node synchronization, periodic persistence, etc.)

AOF: Data Persistence for command logs

RDB: Actual data persistence

The running environment for Lua Environment:lua scripts. To make the LUA environment conform to the requirements of Redis scripting, Redis has made a series of modifications to the LUA environment, including adding libraries, replacing random functions, protecting global variables, and so on.

Command table: When the command is executed, the implementation function of the corresponding command is found according to the character.

Share Objects (object sharing):

Main storage common values: A. Common return values for various commands, such as the return value OK, ERROR, Wrongtype, and so on; B. All integers that are less than redis.h/redis_shared_integers (default 1000). By pre-allocating some common value objects and sharing objects among multiple data structures, the program avoids the hassle of repeating allocations. In other words, these common values have only one copy in memory.

Databases:

The Redis database is where the data is actually stored. Of course, the database itself is also stored in memory.

The databased data structure pseudo-code is as follows:

<span style= "Font-family:microsoft yahei;font-size:18px;" >typedef struct REDISDB {
    //holds the number int ID of the database represented by an integer
    ;

    Holds all key-value pairs of data in the database
    //This property is also known as key space (key spaces)
    dict *dict;

    The expiration information of the key is saved
    dict *expires;

    Implementing a list of blocking primitives, such as Blpop
    //In the list type chapter has a detailed discussion
    dict *blocking_keys;
    Dict *ready_keys;

    Used to implement the WATCH command
    //In the transaction section there is a detailed discussion
    dict *watched_keys;
} redisdb;
</span>

A database, in-memory data structure as shown in the following figure:

Key elements of database include:

ü The database is mainly composed of dict and expires two dictionaries, in which dict save the key value pair, and expires the expiration time of the Save key.

ü The key of the database is always a string object, and the value can be any of the Redis data types, including strings, hashes, collections, lists, and ordered sets.

A key of Üexpires and a key of the dict together point to the same string object, while the value of the Expires key is the UNIX expiration timestamp that the key calculates in milliseconds.

Üredis uses lazy deletion and periodically deletes two policies to remove expired keys.

ü The updated RDB file and the rewritten AOF file do not retain the expired keys.

ü When an expiration key is removed, the program appends a new DEL command to the end of the existing AOF file.

ü When the primary node deletes an expiration key, it explicitly sends a DEL command to all subordinate nodes.

The secondary node, even if it finds an expiration key, does not delete it by itself, but waits for the main node to send the DEL command, which guarantees that the data of the primary and secondary nodes are always consistent. The Dict Dictionary of the database and the expires dictionary extend the same policy as the normal dictionary. Their shrinkage strategy is to reduce the number of available nodes to greater than or equal to the number of currently used nodes when the node's fill percentage is less than 10%.