Reputation: 919
I am trying to understanding basics of Redis. One that that keeps coming everywhere is, Redis is single threaded that makes things atomic.But I am unable to imagine how this is working internally.I have below doubt.
Don't we design a server single thread if it is IO bound application(like Node.js),where thread got free for another request after initiating IO operation and return data to client once IO operation is finished(providing concurrency). But in case of Redis all data are available in Main Memory,We are not going to do IO operation at all.So then why Redis is single threaded? What will happen if first request is taking to much time,remaining request will have to keep waiting?
Upvotes: 13
Views: 14358
Reputation: 39568
TL;DR: Single thread makes Redis simpler, and Redis is still I/O bound.
Memory is I/O. Redis is still I/O bound. When Redis is under heavy load and reaches maximum requests per second it is usually starved for network bandwidth or memory bandwidth, and is usually not using much of the CPU. There are certain commands for which this won't be true, but for most use cases Redis will be severely I/O bound by network or memory.
Unless memory and network speeds suddenly get orders of magnitude faster, being single threaded is usually not an issue. If you need to scale beyond one or a few threads (ie: master<->slave<->slave setup) you are already looking at Redis Cluster. In that case you can set up a cluster instance per CPU core if you are somehow CPU starved and want to maximize the number of threads.
I am not very familiar with Redis source or internals, but I can see how using a single thread makes it easy to implement lockless atomic actions. Threads would make this more complex and don't appear to offer large advantages since Redis is not CPU bound. Implementing concurrency at a level above a Redis instance seems like a good solution, and is what Redis Sentinel and Redis Cluster help with.
What happens to other requests when Redis takes a long time?
Those other requests will block while Redis completes the long request. If needed, you can test this using the client-pause
command.
Upvotes: 27
Reputation: 11
From redis website
Redis uses a mostly single threaded design. This means that a single process serves all the client requests, using a technique called multiplexing. This means that Redis can serve a single request in every given moment, so all the requests are served sequentially. This is very similar to how Node.js works as well. However, both products are not often perceived as being slow. This is caused in part by the small amount of time to complete a single request, but primarily because these products are designed to not block on system calls, such as reading data from or writing data to a socket.
I said that Redis is mostly single threaded since actually from Redis 2.4 we use threads in Redis in order to perform some slow I/O operations in the background, mainly related to disk I/O, but this does not change the fact that Redis serves all the requests using a single thread.
Memory is no I/O operation
Upvotes: 1
Reputation: 50112
The correct answer is Carl's, of course. However.
In Redis v4 we're seeing the beginning of a shift from being mostly single threaded to selectively and carefully multi threaded. Modules and thread-safe contexts are one example of that. Another two are the new UNLINK
command and ASYNC
mode for FLUSHDB/FLUSHALL
. Future plans are to offload more work that's currently being done by the main event loop (e.g. IO-bound tasks) to worker threads.
Upvotes: 22