TL;DR :Ein einzelner Thread macht Redis einfacher, und Redis ist immer noch IO-gebunden.
Speicher ist I/O. Redis ist immer noch E/A-gebunden. Wenn Redis stark ausgelastet ist und die maximalen Anforderungen pro Sekunde erreicht, wird es normalerweise für Netzwerkbandbreite oder Speicherbandbreite ausgehungert und verwendet normalerweise nicht viel von der CPU. Es gibt bestimmte Befehle, für die dies nicht zutrifft, aber für die meisten Anwendungsfälle ist redis stark durch das Netzwerk oder den Speicher an E/A gebunden.
Sofern Speicher- und Netzwerkgeschwindigkeiten nicht plötzlich um Größenordnungen schneller werden, ist Single-Threading normalerweise kein Problem. Wenn Sie über einen oder wenige Threads hinaus skalieren müssen (dh:Master<->Slave<->Slave-Setup), sehen Sie sich bereits Redis Cluster an. In diesem Fall können Sie eine Clusterinstanz pro CPU-Kern einrichten, wenn Sie irgendwie CPU-hungrig sind und die Anzahl der Threads maximieren möchten.
Ich bin mit Redis Source oder Internals nicht sehr vertraut, aber ich kann sehen, wie die Verwendung eines einzelnen Threads es einfach macht, lockless atomare Aktionen zu implementieren. Threads würden dies komplexer machen und scheinen keine großen Vorteile zu bieten, da Redis nicht CPU-gebunden ist. Die Implementierung von Parallelität auf einer Ebene über einer Redis-Instanz scheint eine gute Lösung zu sein, und dabei helfen Redis Sentinel und Redis Cluster.
Was passiert mit anderen Anfragen, wenn Redis lange dauert?
Diese anderen Anfragen werden blockiert, während Redis die lange Anfrage abschließt. Bei Bedarf können Sie dies mit client-pause testen Befehl.
