multithreading - why Redis is single threaded(event driven) -

i trying understanding basics of redis. 1 that keep coming everywhere is, redis single threaded makes things atomic.but unable imagine how working internally.i have below doubt.

don't design server single thread if io bound application(like node.js),where thread got free request after initiating io operation , return data client once io operation finished(providing concurrency). in case of redis data available in main memory,we not going io operation @ all.so why redis single threaded?what happen if first request taking time,remaining request have keep waiting?

tl;dr: single thread makes redis simpler, , redis still io bound.

memory i/o. redis still i/o bound. when redis under heavy load , reaches maximum requests per second starved network bandwidth or memory bandwidth, , not using of cpu. there commands won't true, use cases redis severely i/o bound network or memory.

unless memory , network speeds orders of magnitude faster, being single threaded not issue. if need scale beyond 1 or few threads (ie: master<->slave<->slave setup) looking @ redis cluster. in case can set cluster instance per cpu core if somehow cpu starved , want maximize number of threads.

i not familiar redis source or internals, can see how using single thread makes easy implement lockless atomic actions. threads make more complex , doesn't appear offer large advantages since redis not cpu bound. implementing concurrency @ level above redis instance seems solution, , redis sentinel , redis cluster with.

what happens other requests when redis takes long time?

those other requests block while redis completes long request. if needed, can test using client-pause command.