Redis é um banco de dados de thread único (para operações principais). Qual é a vantagem de criar múltiplas conexões (conjunto de conexões) quando as operações são processadas uma por uma no lado do servidor? Podemos simplesmente criar uma única conexão e compartilhá-la entre todos os threads.
AskOverflow.Dev
O resultado final é que isso realmente depende e depende principalmente do cliente que você está usando.
O caso do pool de conexões
Sim, o Redis é de thread único, sim, você pode passar as mesmas conexões para outras partes do seu aplicativo e reutilizá-las. No entanto, o que falta aqui é que é a latência que realmente leva você ao Redis. Digamos que você tenha um comando que (para simplificar) leva aproximadamente 2,01 ms do início ao fim em seu aplicativo.
1ms é a latência que vai para o Redis 0,01ms é o comando em execução no Redis 1ms é a latência que volta do Redis
Na grande maioria das vezes (2ms de 2,01ms), o thread principal do Redis não está em uso, de modo que 2 ms são essencialmente desperdiçados. e se o soquete que você está passando não for reentrante enquanto um comando estiver sendo executado sobre ele, você será bloqueado até que o comando termine de enviar qualquer outra coisa para o Redis.
É por isso que você usaria um pool de conexões, para permitir que vários segmentos do seu aplicativo enviem comandos ao Redis ao mesmo tempo.
Alguns clientes geralmente não precisam deles
Há uma advertência muito importante que você deve fazer aqui. Um cliente pode canalizar comandos para o Redis, enviar vários comandos para o Redis usando as mesmas viagens de ida e volta, e alguns clientes fazem um trabalho realmente excelente ao gerenciar isso.
Por exemplo, o principal cliente .NET Redis de uso geral, StackExchange.Redis , multiplexa todos os comandos que você envia a ele por meio de uma conexão, canalizando o máximo que pode. Nesse caso, há relativamente pouco tempo desperdiçado no Redis em comparação com o que seu aplicativo pode enviar. O Node Redis faz algo semelhante, canalizando automaticamente tudo o que recebe no mesmo tick. No caso de tais clientes, geralmente não é necessário agrupar conexões sem um motivo convincente (por exemplo, objetos muito grandes cuja transferência pela rede pode bloquear a execução de outros comandos).