Design idea

  • 1, completely memory based, most requests are pure memory operations, very fast. The data is stored in memory, similar to a HashMap, which has the advantage of having O(1) time for both lookup and operation.

  • 2. The data structure in Redis is specially designed, and the data operation is also simple, many of which are extremely memory saving

  • 3, the use of single thread, avoid unnecessary context switch and competition conditions, there is no multi-process or multi-threading caused by the switch and CPU consumption, do not have to consider the problem of various locks, there is no lock release lock operation, there is no performance consumption due to the possibility of deadlock

  • 4. Use multi-channel I/O multiplexing model, non-blocking IO

  • 5, the use of the underlying model is different, between them the underlying implementation and communication with the client between the application protocol is not the same, Redis directly built their own VM mechanism, because the general system call system function, will waste a certain amount of time to move and request

Redis multiplexing (synchronous non-blocking IO)–epoll

The first thing to understand about I/O multiplexing (also known as “event-driven”) is that the operating system provides you with a feature that notifies you when one of your sockets is readable or writable. In this way, when used with a non-blocking socket, I only execute the read operation when the system informs me which descriptor is readable. This ensures that I can read valid data every time and does not repeatedly facilitate the useless work of no data. Write operations are similar in that the operating system uses system call functions such as SELECT /poll/epoll/kqueue to monitor the read and write readiness of multiple descriptors at the same time, so that I/O operations of multiple descriptors can be completed concurrently and sequentially in a single thread. This is called I/O multiplexing, and by “multiplexing” I mean multiplexing the same thread. Author: zhihu user link: www.zhihu.com/question/28…

Why multithreading in Redis 6.0

  • At present, the performance bottleneck for single-threaded Redis is mainly the IO consumption of the network

Because read/write system calls on read/write networks consume most of the CPU time during Redis execution, making network reads and writes multithreaded can greatly improve performance.

The multi-threaded part of Redis is only used to handle network data reading and writing and protocol parsing, and the execution of commands is still single-threaded. The reason for this design is that Redis does not need to be complicated by multi-threading, controlling concurrency for keys, LUA, transactions, LPUSH/LPOP, etc

  • For example,

In the latest versions of Redis, some deletions can be handled asynchronously by other threads, such as the ones we mentioned above: FLUSHDB ASYNC: FLUSHDB ASYNC: FLUSHDB ASYNC: FLUSHDB ASYNC: FLUSHDB ASYNC: FLUSHDB ASYNC: FLUSHDB ASYNC: FLUSHDB ASYNC: FLUSHDB ASYNC

We know that Redis can use the del command to delete an element. If the element is very large, maybe tens or hundreds of megabytes, it cannot be done in a short time, which requires multi-threaded asynchronous support. Deletion can now be done in the background.