What is the asynchronous mechanism of Redis

1. Redis blocking points

Objects that interact with Redis instances, and operations that occur during interaction:

• Client: network IO, key value For add, delete, modify and query operations, database operations;

• Disk: generate RDB snapshot, record AOF log, AOF log rewrite;

• Master-slave Node: The main library generates and transmits RDB files, receives RDB files from the library, clears the database, and loads RDB files;

• Slicing cluster instance: transmits hash slot information to other instances, data migration .

4 The relationship between class interaction objects and specific operations:

Blocking when interacting with the client Point:

Network IO can sometimes be slow, but Redis uses an IO multiplexing mechanism to avoid the main thread waiting for network connections or requests to arrive, so network IO is not the factor that causes Redis to block.

The main task of the Redis main thread is to perform the addition, deletion, modification and query operations of key-value pairs that interact with the client. Highly complex add, delete, modify, and query operations will definitely block Redis.

The standard for judging the complexity of an operation: see whether the complexity of the operation is O(N).

The first blocking point of Redis: full set query and aggregation operation:

The complexity of operations involving collections in Redis is usually O(N), so you need to pay attention when using it.
For example, set elementsFull queryOperations HGETALL, SMEMBERS, and Aggregation statisticsoperations of sets, such as intersection, union and difference.

The second blocking point of Redis: bigkey deletion operation

The deletion operation of the collection itself also has potential blocking risks. The essence of the deletion operation is to release the memory space occupied by the key-value pair. Releasing memory is only the first step. In order to manage memory space more efficiently, when an application releases memory, the operating system needs to insert the released memory block into a linked list of free memory blocks for subsequent management and reallocation.

This process itself takes a certain amount of time, and will block the application that is currently releasing memory. If a large amount of memory is released at once, the operation time of the free memory block linked list will increase, which will accordingly cause the Redis main thread to fail. block.

Time to release a large amount of memory: When deleting a large number of key-value pairs, deleting a collection containing a large number of elements is also called bigkey deletion.

The time consumed when deleting collections with different number of elements:

Three conclusions are drawn:

• When the number of elements increases from 100,000 to 1 million, the deletion time of the four major collection types increases from 5 times to nearly 20 times; The larger it is, the longer it takes to delete;

• When deleting a set containing 1 million elements, the maximum deletion time of the Hash type has reached an absolute value of 1.98 seconds. Under normal circumstances, Redis response time is at the microsecond level, but if an operation takes nearly 2 seconds to execute, it will block the main thread, which is unavoidable.

• The third blocking point of Redis: clearing the database

Since frequent deletion of key-value pairs is a potential blocking point, in the database-level operation of Redis, Flushing the database (such as FLUSHDB and FLUSHALL operations) is also a potential blocking risk because it involves deleting and releasing all key-value pairs.

The fourth blocking point of Redis: AOF log synchronization writing

Disk IO is generally time-consuming and laborious and requires focus. Redis developers have long recognized that disk IO can cause blocking, so Redis is designed to use a sub-process to generate RDB snapshot files and perform AOF log rewrite operations. The child process is responsible for execution, and slow disk IO will not block the main thread.

If Redis records AOF logs directly, it will use different write strategies to write data to disk. A synchronous disk write operation takes about 1 to 2 ms. If a large number of write operations need to be recorded in the AOF log and written back synchronously, the main thread will be blocked.

The fifth blocking point of Redis: loading RDB files from the slave library

In a master-slave cluster, the master library needs to generate an RDB file and transfer it to the slave library.

During the copying process of the main library,

creating and transmitting RDB files are completed by the child process

and will not block the main thread.

But after receiving the RDB file, the slave library needs to use the FLUSHDB command to clear the current database, which happens to hit the third blocking point.

After clearing the current database, the slave library needs to load the RDB file into the memory. The speed of this process is closely related to the size of the RDB file. The larger the RDB file, the slower the loading process.

Blocking points when slicing cluster instances interact

When deploying a Redis slicing cluster, the hash slot information allocated on each Redis instance needs to be transferred between different instances. When load balancing is required Or when instances are added or deleted, data will be migrated between different instances. However, the amount of information in the hash slot is not large, and data migration is performed incrementally. These two types of operations have little risk of blocking the Redis main thread.

If the Redis Cluster solution is used and bigkey is migrated at the same time, the main thread will be blocked because Redis Cluster uses synchronous migration.

Five blocking points:

• Collect full query and aggregation operation;

• bigkey deletion ;

• Clear the database;

• AOF log synchronous writing;

• Load RDB files from the library .

2. Blocking points that can be executed asynchronously

In order to avoid blocking operations, Redis provides an asynchronous thread mechanism:

Redis will start some sub-systems Threads, and then hand over some tasks to these sub-threads to complete them in the background, instead of the main thread performing these tasks. This avoids blocking the main thread.

Requirements for asynchronous execution of operations:

An operation that can be executed asynchronously is not an operation on the critical path of the Redis main thread (after the client sends the request to Redis, it waits for Redis operations that return data results).

After the main thread receives operation 1, operation 1 does not need to return specific data to the client. The main thread can hand it over to the background sub-thread for completion. At the same time, as long as Just return an "OK" result to the client.
When the child thread performs operation 1, the client sends operation 2 to the Redis instance. The client needs to use the data result returned by operation 2. If operation 2 does not return a result, the client will always be waiting. state.

Operation 1 is not considered an operation on the critical path, because it does not need to return specific data to the client, so it can be executed asynchronously by the background sub-thread.
Operation 2 needs to return the result to the client. It is an operation on the critical path, so the main thread must complete this operation immediately.

• Redis read operation is a typical critical path operation, because after the client sends the read operation, it will wait for the read data to be returned for subsequent data processing. The first blocking point of Redis, "collection full query and aggregation operation", both involve read operations, and asynchronous operations cannot be performed.

• Delete operations that do not require specific data results to be returned to the client are not critical path operations. "Both 'bigkey deletion' and 'database clearance' involve deleting data, but they are not on the critical path.". You can use background sub-threads to perform deletion operations asynchronously.

• "AOF log synchronous writing", in order to ensure data reliability, the Redis instance needs to ensure that the operation records in the AOF log have been placed on disk. Although this operation requires the instance to wait, it does not Specific data results will be returned to the instance. Therefore, a child thread can be started to perform synchronous writing of the AOF log.

• In order to provide data access services to clients, the complete RDB file must be loaded. This operation is also an operation on the critical path and must be executed by the main thread of the slave library.

Except for "collection full query and aggregation operations" and "loading RDB files from the library", the operations involved in the other three blocking points are not on the critical path, and you can use the asynchronous subroutine of Redis. Thread mechanism is used to implement bigkey deletion, clear database, and AOF log synchronous writing.

3. Asynchronous sub-thread mechanism

After the Redis main thread is started, it will use the pthread_create function provided by the operating system to create 3 sub-threads, responsible for AOF log writing operations, key-value pairs Asynchronous execution of deletion and file closing.

The main thread interacts with the child threads through a task queue in the form of a linked list.

When receiving the operation of deleting the key-value pair and clearing the database, the main thread will encapsulate the operation into a task, put it into the task queue, and then return a completion message to the client, indicating that the deletion has been completed. Finish.

But in fact, the deletion has not yet been executed at this time. After the background sub-thread reads the task from the task queue, it starts to actually delete the key-value pairs and release the corresponding memory space. This asynchronous deletion is also called lazy deletion (lazy free).

When the AOF log is configured with the everysec option, the main thread will encapsulate the AOF log writing operation into a task and put it in the task queue. One way to rewrite it is: When the background sub-thread reads the task, it starts recording to the AOF log by itself, and the main thread can continue running without relying on the AOF log.

Asynchronous sub-thread execution mechanism in Redis:

Asynchronous key-value pair deletion and database clearing operations are functions provided after Redis 4.0. Redis also provides new commands to perform these two operations:

• Key-value pair Deletion: When there are a large number of elements in the collection type (for example, there are millions or tens of millions of elements) that need to be deleted, it is recommended to use the UNLINK command;

• Clear the database: You can use the FLUSHDB and FLUSHALL commands Then add the ASYNC option to allow the background sub-thread to clear the database asynchronously.

FLUSHDB ASYNC 
FLUSHALL AYSNC

The above is the detailed content of What is the asynchronous mechanism of Redis. For more information, please follow other related articles on the PHP Chinese website!