19 What does Each Processing Module do in Redis System Architecture #
Hello, I am your caching course teacher Chen Bo. Welcome to the 19th lesson on “Redis System Architecture”.
Redis System Architecture #
Through previous lessons, I believe you have already grasped the principles, data types, and access protocols of Redis. In this lesson, I will further analyze the system architecture of Redis, focusing on the event processing mechanism, data management, functionality extension, and system scalability.
Event Processing Mechanism #
The system architecture of Redis components, as shown in the diagram, mainly includes event processing, data storage and management, master-slave replication/cluster management for system extension, and the Module System module for plug-in functionality extension.
The event processing module in Redis uses the author’s own developed ae event-driven model, which allows efficient network IO reading, writing, command execution, and event handling.
For network IO reading and writing, Redis uses IO multiplexing technology, encapsulating evport, epoll, kqueue, select, etc., to simultaneously monitor multiple sockets and associate them with different event handlers based on the tasks the sockets are currently performing.
When the socket corresponding to the listening port receives a connection request, a client structure is created to manage the connection status. When a request comes in, the request command is read from the buffer, parsed, and stored in the client’s parameter list.
Then, based on the request command, the corresponding redisCommand is found, and the request parameters are further parsed, verified, and executed according to the command protocol. Currently, time events in Redis are relatively simple and mainly involve executing serverCron to perform auxiliary operations such as statistics updates, expired key cleanup, AOF and RDB persistence.
Data Management #
The memory data in Redis is stored in redisDB. Redis supports multiple DBs, with each DB corresponding to a redisDB structure. The 8 data types in Redis are stored using one or more internal data structures. These internal data structures and the related auxiliary information are stored in various dict dictionaries in redisDB in the key/value format.
After data is written to redisDB, the write commands are promptly appended to the AOF. The appending process involves writing to the AOF buffer in real time and then flushing the buffered data to the file according to a strategy. Since AOF records each write operation, a large amount of intermediate state for a key will also appear in the AOF, resulting in excessive redundant information in the AOF. As a result, Redis also introduced a RDB snapshot operation to periodically persist all memory data to RDB files in the most concise way.
The core processing thread for data read and write in Redis follows a single-threaded model. To maintain high performance for the entire system, any operations that could potentially block the kernel must be avoided. To achieve this, Redis adds a BIO thread to handle potentially blocking operations such as file close and fsync, ensuring the performance and stability of the system.
In the server end, memory storage is always expensive and limited. In Redis, expired keys need to be promptly cleared, and inactive keys may need to be evicted when memory is scarce. To accomplish this, Redis designed 8 eviction strategies, leveraging the newly introduced eviction pool for efficient key eviction and memory reclamation.
Functionality Extension #
Redis introduced the Module System module starting from version 4.0, which allows users to develop plug-in functionalities without modifying the core functions. Users can package new features into dynamic link libraries, which Redis can load at startup or on-demand during runtime.
In extension modules, developers can initialize new modules using RedisModule_init, and expand various new module instructions using RedisModule_CreateCommand, introducing new data structures and access commands for Redis in a plug-and-play manner.
System Scalability #
Redis author has devoted a lot of attention to the system scalability in the architecture design. In the master-slave replication feature, psync has been continuously optimized, allowing incremental replication not only after slave reconnection, but also when a slave becomes the new master after master-slave switch, and in other scenarios such as incremental replication after slave restart. This greatly improves the availability of master-slave replication. Users can easily use master-slave replication for read-write separation of business data, significantly enhancing the stable read and write capabilities of the Redis system.
Although single-node read/write issues in Redis can be well addressed through master-slave replication, all write operations are still concentrated on the master server, easily reaching the write limit of Redis. Additionally, both the master and slave nodes in Redis store all business data, and as the business grows, it is easy to run out of memory.
Therefore, Redis partitioning becomes inevitable. Although most industry practices involve partitioning at the client and proxy ends, Redis itself introduced the cluster feature early on and continues to optimize it. Redis cluster predefines 16384 slots, which are manually or automatically distributed to different service nodes when the Redis cluster starts. When locating keys for read and write operations, the key is hashed, and the hash value is bitwise ANDed with 16383 to determine the slot, and then the service node and corresponding Redis node are determined for regular read and write operations. If a client sends a request to the wrong Redis shard, Redis will send a redirect reply. If the business data increases significantly, Redis cluster can perform online scaling through data migration.