TL;DR :En tråd gör redis enklare, och redis är fortfarande IO-bunden.
Minnet är I/O. Redis är fortfarande I/O-bunden. När redis är under tung belastning och når maximala förfrågningar per sekund är det vanligtvis svalt för nätverksbandbredd eller minnesbandbredd, och använder vanligtvis inte mycket av CPU:n. Det finns vissa kommandon för vilka detta inte kommer att vara sant, men för de flesta användningsfall kommer redis att vara starkt I/O-bunden av nätverk eller minne.
Såvida inte minnes- och nätverkshastigheterna plötsligt blir storleksordningar snabbare, är det vanligtvis inget problem att vara entrådad. Om du behöver skala bortom en eller några trådar (t.ex. master<->slave<->slave setup) tittar du redan på Redis Cluster. I så fall kan du ställa in en klusterinstans per CPU-kärna om du på något sätt är CPU-hungrig och vill maximera antalet trådar.
Jag är inte så bekant med redis source eller interna delar, men jag kan se hur att använda en enda tråd gör det enkelt att implementera låslösa atomära åtgärder. Trådar skulle göra detta mer komplext och verkar inte ge några stora fördelar eftersom redis inte är CPU-bunden. Att implementera samtidighet på en nivå över en redis-instans verkar vara en bra lösning, och det är vad Redis Sentinel och Redis Cluster hjälper till med.
Vad händer med andra förfrågningar när redis tar lång tid?
Dessa andra förfrågningar kommer att blockeras medan redis slutför den långa begäran. Om det behövs kan du testa detta med client-pause kommando.