O cliente Redis não cria nenhum thread clent adicional e funciona no thread existente.
O Redis trabalhou em outro processo (principal). A API redis que você usa funcionou em seu processo local e usa a comunicação entre processos para o processo principal. A solicitação assíncrona significa que seu processo ou thread coloca a tarefa em outro e, depois disso, pode executar qualquer outra tarefa ou evento de espera. Algum tempo depois, a resposta assíncrona chegou ao seu aplicativo e ficou disponível para uso. Seu aplicativo deve usar https://en.wikipedia.org/wiki/Event_loop ou qualquer sistema de gerenciamento assíncrono que o notifique chamando o retorno de chamada para manipular o evento (neste caso, a resposta redis).
Arquitetura assíncrona significa que você está executando um loop de eventos que chama manipuladores de retorno de chamada para cada evento. Quando o retorno de chamada é chamado, você pode criar várias tarefas assíncronas. Uma vez criada a tarefa, supõe-se que quando a tarefa for concluída ou ocorrer um erro, o manipulador de eventos de retorno de chamada será chamado. O retorno de chamada pode ser atribuído para iniciar o aplicativo ou para que uma nova conexão da web apareça. Quando o retorno de chamada é chamado, você pode criar a tarefa redis e o retorno de chamada do evento de resultado posterior será chamado. Todas as coisas no tópico atual. Se você tiver vários threads, é razoável esperar que você tenha um loop de eventos por cada thread.
Natureza de thread único do Redis:http://redis.io/topics/latency#single-threaded-nature-of-redis
O soquete do cliente é colocado no estado sem bloqueio, pois o Redis usa E/S de multiplexação e sem bloqueio. http://redis.io/topics/clients Isso significa que seu cliente nunca será bloqueado.
A partir do Redis 2.4, os threads no Redis eram usados apenas para realizar algumas operações de E/S lentas em segundo plano, principalmente relacionadas à E/S de disco, mas isso não altera o fato de que o Redis atende a todas as solicitações usando um único thread.
