TL;DR :il thread singolo rende più semplice redis e redis è ancora legato all'IO.
La memoria è I/O. Redis è ancora legato all'I/O. Quando redis è sottoposto a un carico elevato e raggiunge il massimo delle richieste al secondo, di solito è affamato di larghezza di banda di rete o larghezza di banda di memoria e di solito non utilizza gran parte della CPU. Ci sono alcuni comandi per i quali questo non è vero, ma per la maggior parte dei casi d'uso redis sarà fortemente legato all'I/O dalla rete o dalla memoria.
A meno che la memoria e la velocità della rete non ottengano improvvisamente ordini di grandezza più veloci, il thread singolo di solito non è un problema. Se hai bisogno di scalare oltre uno o pochi thread (es:master<->slave<->slave setup) stai già guardando Redis Cluster. In tal caso puoi configurare un'istanza del cluster per core CPU se sei in qualche modo affamato di CPU e desideri massimizzare il numero di thread.
Non ho molta familiarità con l'origine o gli interni di redis, ma posso vedere come l'utilizzo di un singolo thread semplifichi l'implementazione di azioni atomiche senza blocco. I thread renderebbero questo più complesso e non sembrano offrire grandi vantaggi poiché redis non è vincolato alla CPU. L'implementazione della simultaneità a un livello superiore a un'istanza redis sembra una buona soluzione ed è ciò per cui Redis Sentinel e Redis Cluster aiutano.
Cosa succede alle altre richieste quando redis impiega molto tempo?
Quelle altre richieste si bloccheranno mentre redis completa la richiesta lunga. Se necessario, puoi verificarlo utilizzando client-pause comando.
