Il client Redis non crea alcun thread clent aggiuntivo e funziona nel thread esistente.
Il Redis ha funzionato in un altro processo (principale). L'API redis che utilizzi ha funzionato nel processo locale e utilizza la comunicazione tra processi per il processo principale. La richiesta asincrona significa che il tuo processo o thread assegna un'attività a un altro e, successivamente, può eseguire qualsiasi altra attività o evento di attesa. Qualche tempo dopo è arrivata una risposta asincrona all'applicazione e disponibile per l'uso. L'applicazione deve utilizzare https://en.wikipedia.org/wiki/Event_loop o qualsiasi sistema di gestione asincrono che ti avvisa chiamando la richiamata per gestire l'evento (in questo caso ridisponi la risposta).
L'architettura asincrona significa che si esegue un ciclo di eventi che chiama gestori di callback per ogni evento. Quando viene chiamata la richiamata, è possibile creare un numero di attività asincrone. Una volta creata l'attività, si suppone che quando l'attività viene eseguita o si verifica un errore verrà chiamato il gestore dell'evento di callback. La richiamata può essere assegnata all'avvio dell'app o alla visualizzazione di una nuova connessione Web. Quando viene chiamata la richiamata, è possibile creare l'attività redis e in seguito verrà chiamata la richiamata dell'evento del risultato. Tutte le cose nel thread corrente. Non ho più thread, è ragionevole aspettarsi che tu abbia un ciclo di eventi per ogni thread.
Natura a thread singolo di Redis:http://redis.io/topics/latency#single-threaded-nature-of-redis
Il socket client viene messo in uno stato non bloccante poiché Redis utilizza I/O multiplexing e non bloccante. http://redis.io/topics/clients Ciò significa che il tuo client non verrà mai bloccato.
Da Redis 2.4 i thread in Redis vengono utilizzati solo per eseguire alcune operazioni di I/O lente in background, principalmente relative all'I/O del disco, ma questo non cambia il fatto che Redis serve tutte le richieste utilizzando un unico thread.
