If Redis is single Threaded, how can it be so fast?

Question

I'm currently trying to understand some basic implementation things of Redis. I know that redis is single-threaded and I have already stumbled upon the following Question: Redis is single-threaded, then how does it do concurrent I/O?

But I still think I didn't understood it right. Afaik Redis uses the reactor pattern using one single thread. So If I understood this right, there is a watcher (which handles FDs/Incoming/outgoing connections) who delegates the work to be done to it's registered event handlers. They do the actual work and set eg. their responses as event to the watcher, who transfers the response back to the clients. But what happens if a request (R1) of a client takes lets say about 1 minute. Another Client creates another (fast) request (R2). Then - since redis is single threaded - R2 cannot be delegated to the right handler until R1 is finished, right? In a multithreade environment you could just start each handler in a single thread, so the "main" Thread is just accepting and responding to io connections and all other work is carried out in own threads.

If it really just queues the io handling and handler logic, it could never be as fast it is. What am I missing here?

Anti

Answer 1

You're not missing anything, besides perhaps the fact that most operations in Redis complete in less than a ~millisecond~ couple of microseconds. Long running operations indeed block the server during their execution.

Elevated

A bit of nitpicking, my esteemed colleague - internal running time of most redis operations is done in a couple of microseconds, milliseconds includes the networking roundtrip, where CPU has zero effect. – Yirinec

Thank you for you answer! So for instance if I only use one redis instance (no replications, no master-slave) which is requested by millions of clients simultaniously, the last client has to wait until all other requests are finished, right? I know that redis is easy to replicate, but just for my understanding. – Anti

"last" is a vague concept, but essentially yes - one operation is executed at any given (micro)instant, all the others are pending. – Elevated

Great, thanks! I know it's a very vague concept, but it helped me understand I'm on the right path ;) – Anti

Answer 2

Let’s say if there were 10,000 users doing live data pulling with 10 seconds each on hmget, and on the other side, server were broadcasting using hmset, redis can only issue the set at the last available queue.

Redis is only good for queuing and handle limited processing like inserting lazy last login info, but not for live info broadcasting, in this case, memcached will be the right choice. Redis is single threaded, like FIFO.

Blister