prefácio
O Redis lançou oficialmente a versão 6.0 em maio de 2020, fornecendo muitos novos recursos interessantes, por isso atraiu muita atenção.
Quais recursos ele oferece? Você sabe se eu posso conseguir um aumento?
As principais características são as seguintes:
- Processamento multi-thread de E/S de rede;
- cache do cliente;
- Controle de permissão refinado (ACL);
RESP3Uso do Contrato;- Os arquivos RDB usados para replicação não são mais úteis e serão excluídos imediatamente;
- Arquivos RDB carregam mais rápido;
Entre eles, o " modelo multi-thread + cache de cliente " é o mais preocupado.Somente dominando os princípios de novos recursos podemos julgar quando usar a versão 6.0 e como usá-la melhor e mais rápido sem pisar no poço.
Este artigo começa com o modelo multi-threading do Redis e, quanto ao cache do lado do cliente, etc., e ouça a próxima decomposição.
Por fim, clique no cartão abaixo para seguir "Code Brother Byte" para obter um aumento.
Por que o Redis 6.0 não usou multithreading?
Resposta oficial:
- Ao usar o Redis, quase não há situação em que a CPU se torne o gargalo, e o Redis é limitado principalmente pela memória e pela rede.
- Em um sistema Linux normal, o Redis
pipeliningpode lidar com 1 milhão de solicitações por segundo usando-o, portanto, se o aplicativo usar principalmente comandos O(N) ou O(log(N)), dificilmente precisará de muita CPU. - Depois de usar um único thread, a capacidade de manutenção é alta. Embora o modelo multi-threading seja excelente em alguns aspectos, ele introduz a incerteza da ordem de execução do programa, traz uma série de problemas de leitura e escrita simultânea, aumenta a complexidade do sistema, podendo ter troca de thread e até mesmo travamento. por desbloqueio e impasse.
O Redis tem um desempenho de processamento muito alto por meio do modelo de evento AE e multiplexação de IO, portanto, não há necessidade de usar multithreading.
O mecanismo de thread único reduz muito a complexidade da implementação interna do Redis. Os comandos preguiçosos do Hash Rehash, Lpush e outros "thread-unsafe" podem ser executados sem travas .
O thread único antes do Redis 6.0 significa que o Redis tem apenas um thread para funcionar?
Não, quando o Redis processa a solicitação do cliente, incluindo aquisição (leitura de soquete), análise, execução, retorno de conteúdo (gravação de soquete), etc., ela é processada por um thread principal serial sequencial, que é o chamado "single thread" .
Na fase de execução de comandos, como o Redis processa comandos em um único thread, todos os comandos que chegam ao servidor não serão executados imediatamente, e todos os comandos entrarão em uma fila Socket. -threaded event dispatcher um por um.
Além disso, algumas operações de comando podem ser executadas com threads ou subprocessos em segundo plano (por exemplo, exclusão de dados, geração de instantâneos, reescrita AOF).
O código é antigo e úmido, então por que o Redis 6.0 introduz o multithreading?
Com a melhoria do desempenho do hardware, o gargalo de desempenho do Redis pode aparecer na rede de leitura e gravação de E/S, ou seja, a velocidade de leitura e gravação de uma rede de processamento de thread único não pode acompanhar a velocidade do hardware de rede subjacente .
As chamadas do read/writesistema ocupam a maior parte do tempo de CPU durante a execução do Redis. O gargalo é principalmente o consumo de IO da rede. Existem duas direções principais para otimização:
- Para melhorar o desempenho de E/S de rede, implementações típicas, como usar
DPDKpara substituir a pilha de rede do kernel. - Use multi-threading para fazer pleno uso de multi-core, melhorar o paralelismo de leitura e escrita de solicitação de rede, implementações típicas como
Memcached.
Adicionar suporte para a pilha de protocolos de rede do modo de usuário requer a modificação das partes relacionadas à rede do código-fonte do Redis (por exemplo, modificar todas as funções de solicitação de envio e recebimento de rede), o que trará muita carga de trabalho de desenvolvimento.
E o novo código também pode introduzir novos bugs, resultando em instabilidade do sistema.
Portanto, o Redis usa vários threads de E/S para processar solicitações de rede para melhorar o paralelismo do processamento de solicitações de rede.
Deve-se observar que o modelo de thread multi-IO do Redis é usado apenas para processar solicitações de leitura e gravação de rede. Para comandos de leitura e gravação do Redis, ainda é um processamento de thread único .
Isso ocorre porque o processamento de rede geralmente é o gargalo e o desempenho pode ser aprimorado pelo processamento paralelo multithread.
Continuar a usar um único thread para executar comandos de leitura e escrita não requer o desenvolvimento de mecanismos de segurança multithread para garantir scripts, transações, etc. Lua, e a implementação é mais simples.
O diagrama de arquitetura é o seguinte :
Como o thread principal e o multithreading de E/S cooperam?
Como mostrado abaixo:
Processo principal :
- A thread principal é responsável por receber a solicitação de estabelecimento de conexão, obtê-la e
socketcolocá-la na fila de processamento de leitura de espera global; - O encadeamento principal
socketaloca ; - O encadeamento principal bloqueia e aguarda o encadeamento de E/S ler a
socketconclusão ; - O encadeamento principal executa o comando de solicitação Redis lido e analisado pelo encadeamento de E/S;
- O encadeamento principal bloqueia e espera que o encadeamento de E/S escreva de volta o resultado da
socketexecução ; - O encadeamento principal limpa a fila global e aguarda as solicitações subsequentes do cliente.
Ideia: dividir as tarefas de leitura e gravação de E/S do thread principal em um conjunto de threads independentes para processamento, de modo que várias tarefas de leitura e gravação de soquete possam ser paralelizadas, mas o comando Redis ainda é executado serialmente pelo thread principal.
Como habilitar o multithread?
O multithreading no Redis 6.0 está desabilitado por padrão e apenas o thread principal é usado. Para habilitá-lo, você precisa modificar o arquivo de redis.confconfiguração : io-threads-do-reads yes.
O código é antigo e molhado, o número de threads é melhor?
Claro que não. Em relação à configuração do número de threads, há uma sugestão oficial: a máquina de 4 núcleos é recomendada para 2 ou 3 threads, a máquina de 8 núcleos é recomendada para 6 threads e o número de threads deve ser menor que o número de núcleos de máquina.
O número de tópicos não é tão grande quanto possível. Os funcionários acreditam que mais de 8 é basicamente sem sentido.
Além disso, depois de habilitar o multi-threading, você também precisa definir o número de threads, caso contrário, ele não terá efeito .
io-threads 4
1.
Resumo e pensamento
Com o rápido desenvolvimento da Internet, o tráfego online a ser processado pelo sistema de negócios da Internet está ficando cada vez maior. O modo de thread único do Redis fará com que o sistema consuma muito tempo de CPU na E/S da rede, reduzindo o throughput. Para melhorar o desempenho do Redis, é necessário Duas direções:
- Otimizando os módulos de E/S de rede
- Melhore a velocidade de leitura e escrita da memória da máquina
Este último depende do desenvolvimento de hardware, e não há solução por enquanto. Portanto, podemos apenas começar com o primeiro, e a otimização de E/S da rede pode ser dividida em duas direções:
- Tecnologia de cópia zero ou tecnologia DPDK
- Aproveite os vários núcleos
Falhas do modelo
O modelo de rede multithread do Redis não é realmente um modelo padrão de Multi-Reactors/Master-Workers. , mas não há real para executar o comando.
Todos os comandos do cliente ainda precisam voltar ao thread principal para execução, portanto, a utilização de multi-core não é alta e, a cada vez, o thread principal deve estar ocupado pesquisando após alocar tarefas e aguardando que todos os threads de E/S concluam as tarefas antes Continue com outra lógica.
Na minha opinião, a atual solução multi-threading da Redis é mais uma escolha de compromisso: ela não apenas mantém a compatibilidade do sistema original, mas também usa multi-core para melhorar o desempenho de E/S.