Redis is single-threaded, then how does it do concurrent I/O?

Question

Trying to grasp some basics of Redis I came across an interesting blog post .

The author states:

Redis is single-threaded with epoll/kqueue and scale indefinitely in terms of I/O concurrency.

I surely misunderstand the whole threading thing, because I find this statement puzzling. If a program is single-threaded, how does it do anything concurrently? Why it is so great that Redis operations are atomic, if the server is single-threaded anyway?

Could anybody please shed some light on the issue?

Deaconry

Starting from Redis 6, the I/O is threaded, see redis.com/blog/diving-into-redis-6 . Seems like full multithreading for Redis 7 is also being considered, as seen in this git issue: github.com/redis/redis/issues/8340 – Jaggery

Answer 1

Well it depends on how you define concurrency.

In server-side software, concurrency and parallelism are often considered as different concepts. In a server, supporting concurrent I/Os means the server is able to serve several clients by executing several flows corresponding to those clients with only one computation unit. In this context, parallelism would mean the server is able to perform several things at the same time (with multiple computation units), which is different.

For instance a bartender is able to look after several customers while he can only prepare one beverage at a time. So he can provide concurrency without parallelism.

This question has been debated here: What is the difference between concurrency and parallelism?

See also this presentation from Rob Pike.

A single-threaded program can definitely provide concurrency at the I/O level by using an I/O (de)multiplexing mechanism and an event loop (which is what Redis does).

Parallelism has a cost: with the multiple sockets/multiple cores you can find on modern hardware, synchronization between threads is extremely expensive. On the other hand, the bottleneck of an efficient storage engine like Redis is very often the network, well before the CPU. Isolated event loops (which require no synchronization) are therefore seen as a good design to build efficient, scalable, servers.

The fact that Redis operations are atomic is simply a consequence of the single-threaded event loop. The interesting point is atomicity is provided at no extra cost (it does not require synchronization). It can be exploited by the user to implement optimistic locking and other patterns without paying for the synchronization overhead.

Mill

v4 is a game changer in this respect - see my answer at https://mcmap.net/q/119339/-why-redis-is-single-threaded-event-driven :) – Comedienne

the only thing I don't really like about the answer and comparison is that it makes it seem like concurrency doesn't do work in parallel and it most certainly does as I can test this with running task async and getting work done that is ultimately considered to be in parallel. parallelism in the context of that article is referring to the multicore nature of being able to run on mutliple threads. I.e. why the refer to it being threadsafe. – Dougherty

Still valid in 2020? – Glennisglennon

The presentation by Rob Pike linked which is linked here (talks.golang.org/2012/waza.slide#1) is a gem, even after ~10 years ! – Elvaelvah

Answer 2

OK, Redis is single-threaded at user-level, OTOH, all asynchronous I/O is supported by kernel thread pools and/or split-level drivers.

'Concurrent', to some, includes distributing network events to socket state-machines. It's single-threaded, runs on one core, (at user level), so I would not refer to this as concurrent. Others differ..

'scale indefinitely in terms of I/O concurrency' is just being economical with the truth. They may get more belief if they said 'can scale better than one-thread-per-client, providing the clients don't ask for much', though they may then feel obliged to add 'blown away on heavy loading by other async solutions that use all cores at user level'.

Harbinger

May be out of context but does each update operation (as by INCR command) carries a lock? If there are 1000 concurrent requests and one increment operation on a key (per request), does that ensure that the variable gets incremented only 1000 times? – Tempting