Redis è a thread singolo, quindi come funziona l'I / O simultaneo?

Cercando di cogliere alcune basi di Redis mi sono imbattuto in un post sul blog interessante .

L'autore afferma:

Redis è a thread singolo con epoll / kqueue e scala indefinitamente in termini di concorrenza I / O.

Sicuramente fraintendo l'intera cosa del threading, perché trovo questa affermazione sconcertante. Se un programma è a thread singolo, come può fare qualcosa contemporaneamente? Perché è così eccezionale che le operazioni di Redis siano atomiche, se il server è comunque single thread?

Qualcuno potrebbe far luce sul problema, per favore?

Bene dipende da come si definisce la concorrenza.

Nel software lato server, la concorrenza e il parallelismo sono spesso considerati concetti diversi. In un server, il supporto di I / O simultanei significa che il server è in grado di servire diversi client eseguendo diversi flussi corrispondenti a quei client con una sola unità di calcolo. In questo contesto, il parallelismo significherebbe che il server è in grado di eseguire diverse cose contemporaneamente (con più unità di calcolo), il che è diverso.

Ad esempio un barista è in grado di prendersi cura di più clienti mentre può preparare solo una bevanda alla volta. Quindi può fornire concorrenza senza parallelismo.

Questa domanda è stata discussa qui: qual è la differenza tra concorrenza e parallelismo?

Vedi anche questa presentazione di Rob Pike.

Un programma a thread singolo può sicuramente fornire concorrenza a livello di I / O utilizzando un meccanismo di multiplexing I / O (de) e un loop di eventi (che è ciò che fa Redis).

Il parallelismo ha un costo: con i socket multipli / core multipli che puoi trovare sull'hardware moderno, la sincronizzazione tra i thread è estremamente costosa. D'altra parte, il collo di bottiglia di un efficiente motore di archiviazione come Redis è molto spesso la rete, ben prima della CPU. I loop di eventi isolati (che non richiedono sincronizzazione) sono quindi visti come una buona progettazione per costruire server efficienti, scalabili.

Il fatto che le operazioni di Redis siano atomiche è semplicemente una conseguenza del loop di eventi a thread singolo. Il punto interessante è che l'atomicità è fornita senza costi aggiuntivi (non richiede sincronizzazione). Può essere sfruttato dall'utente per implementare il blocco ottimistico e altri schemi senza pagare l'overhead di sincronizzazione.

OK, Redis è a thread singolo a livello di utente, OTOH, tutti gli I / O asincroni sono supportati da pool di thread del kernel e / o driver a livello diviso.

" Concorrente ", per alcuni, include la distribuzione di eventi di rete a macchine a stati socket. È a thread singolo, gira su un core, (a livello di utente), quindi non vorrei riferirmi a questo come concorrente. Altri differiscono ..

la " scala indefinitamente in termini di concorrenza I / O " è semplicemente economica con la verità. Potrebbero avere più fiducia se dicessero che "possono ridimensionare meglio di un thread per client, a condizione che i clienti non chiedano molto", anche se potrebbero sentirsi obbligati ad aggiungere "spazzato via dal carico pesante da altre soluzioni asincrone" che utilizzano tutti i core a livello di utente ".