TL;DR :Enkelt tråd gør redis enklere, og redis er stadig IO bundet.
Hukommelse er I/O. Redis er stadig I/O bundet. Når redis er under hård belastning og når maksimale anmodninger pr. sekund, er det normalt sultet efter netværksbåndbredde eller hukommelsesbåndbredde og bruger normalt ikke meget af CPU'en. Der er visse kommandoer, som dette ikke vil være sandt for, men i de fleste tilfælde vil redis være stærkt I/O-bundet af netværk eller hukommelse.
Medmindre hukommelses- og netværkshastigheder pludselig bliver størrelsesordener hurtigere, er det normalt ikke et problem at være enkelttrådet. Hvis du har brug for at skalere ud over en eller nogle få tråde (dvs.:master<->slave<->slave-opsætning), kigger du allerede på Redis Cluster. I så fald kan du konfigurere en klyngeforekomst pr. CPU-kerne, hvis du på en eller anden måde er CPU-udsultet og ønsker at maksimere antallet af tråde.
Jeg er ikke særlig bekendt med redis source eller internals, men jeg kan se, hvordan brugen af en enkelt tråd gør det nemt at implementere låseløse atomiske handlinger. Tråde ville gøre dette mere komplekst og ser ikke ud til at give store fordele, da redis ikke er CPU-bundet. Implementering af samtidighed på et niveau over en redis-instans virker som en god løsning, og det er hvad Redis Sentinel og Redis Cluster hjælper med.
Hvad sker der med andre anmodninger, når genoptagelsen tager lang tid?
Disse andre anmodninger vil blokere, mens redis fuldfører den lange anmodning. Hvis det er nødvendigt, kan du teste dette ved at bruge client-pause kommando.