Todo mundo está familiarizado com o Redis, mas é fácil ser ignorado quando está invisível no nível de uso. O que quero compartilhar com vocês hoje é o papel de cada buffer no Redis, as consequências do estouro e a direção da otimização .
Antes de começar o texto, quero dizer mais algumas palavras. Seja Redis ou outro middleware, muitos princípios subjacentes são semelhantes e as ideias de design são universais.
Se você estiver aprendendo novas estruturas/componentes no futuro, pode tentar associar os pontos de conhecimento que já aprendeu, para que seja mais fácil de entender e não dizer memorização.
Por exemplo, qual é o propósito do buffer agora mencionado?
Sem ele, para o desempenho.
Qualquer um dos dados de cache para melhorar a velocidade de resposta . Por exemplo, há um buffer de alteração no MySQL
Ou se preocupe com o fato de os consumidores não conseguirem acompanhar a produção ou a perda de dados . Portanto, os dados de produção precisam ser armazenados temporariamente. É isso que os buffers do Redis fazem.
Além disso, a velocidade do consumidor não pode acompanhar. Se for processado de forma síncrona, também desacelerará o produtor, então a velocidade do produtor também é garantida aqui.
Alguns leitores podem dizer: bobagem, os consumidores não conseguem acompanhar, para que servem os produtores?
De fato, existe a possibilidade de o produtor não se importar quando o consumidor usar? O primeiro é responsável por processar o que o segundo precisa e dar a ele. O produtor está muito ocupado e há muitos outros dados para processar, portanto, não é possível esperar que o consumidor termine o consumo síncrono antes de fazer outras coisas.
Parece que o início da expansão é um pouco mais, vou fechá-la, e falarei detalhadamente sobre ela abaixo. Se você tiver alguma dúvida, por favor, pegue o ônibus, Qixi parte oficialmente.
1. Cada buffer
Em primeiro lugar, qual buffer o Redis possui?
4 no total:
- buffer de entrada do cliente
- buffer de saída do cliente
- buffer de cópia
- Copiar buffer de pendências
2. Buffer de entrada do cliente
O lado do servidor define um buffer de entrada para cada cliente conectado .
2.1 Função
Dados de solicitação de teste.
O buffer de entrada armazenará temporariamente os comandos enviados pelo cliente e o thread principal do Redis lerá os comandos do buffer de entrada e os processará.
Para evitar incompatibilidades entre as velocidades de envio e processamento de solicitações do cliente e do servidor, este é o mesmo que o buffer de saída a ser discutido posteriormente.
2.2 Cenários de estouro
Em primeiro lugar, o buffer é uma área de memória de tamanho fixo, se este lugar for preenchido, o Redis fechará diretamente a conexão do cliente.
Proteja-se, é melhor o seu cliente desligar do que o meu servidor desligar. Uma vez que o servidor desliga, todos os clientes são inúteis.
Existem duas situações quando o buffer está cheio:
- ou encher de uma vez
- Ou a taxa de produção é mais rápida que a taxa de consumo e é lentamente preenchida
Então o princípio acima corresponde ao cenário Redis.
A situação de encher tudo de uma vez pode estar gravando uma grande quantidade de dados no Redis, que é da ordem de milhões.
Outra situação pode ser que o servidor Redis esteja bloqueado devido a operações demoradas, resultando na incapacidade de consumir os dados do buffer de entrada.
2.3 Otimização
Correspondendo aos dois cenários de estouro acima, a direção da otimização é natural.
No caso de preencher tudo de uma vez, é possível considerar não gravar tantos dados de uma só vez e remover os dados (na verdade, não é razoável gravar uma grande quantidade de dados de uma só vez)
Além disso, é possível aumentar o tamanho do buffer?
Na verdade, isso não é possível, pois não há lugar para configurá-lo. Atualmente, o tamanho padrão do buffer de entrada alocado pelo servidor para cada cliente é de 1 GB.
Então é o segundo cenário de estouro: a velocidade de processamento em ambos os lados é inconsistente.
Normalmente, o servidor não deve ficar bloqueado por muito tempo, então você precisa ver o que causou o bloqueio e resolvê-lo.
3. Buffer de saída do cliente
Assim como o buffer de entrada, o servidor também define um buffer de saída para cada cliente conectado .
3.1 Função
O mesmo que acima, mas também armazena temporariamente os dados da solicitação.
Neste lugar, na verdade, eu disse no início do artigo que o produtor não se importa quando o consumidor o usa, e é responsável apenas por processar as coisas que o consumidor solicitou anteriormente.
Pode ser um pouco abstrato, eu entendo assim, se houver algo errado, por favor deixe uma mensagem para me corrigir
O servidor geralmente está conectado a vários clientes e o módulo de comunicação de rede redis é single-thread (mesmo que a nova versão suporte multi-threading)
E se não houver buffer de saída?
O servidor processou muitas solicitações do cliente A e precisa passar pela operação demorada da rede e devolvê-la ao cliente A. Durante esse processo, a solicitação do cliente B não foi processada e respondida pelo servidor, portanto, a taxa de transferência não pode aumentar.
Com o buffer, pelo menos o servidor pode ser liberado para lidar com a solicitação do cliente B.
3.2 Cenários de estouro
Este também é o mesmo que o buffer de entrada, então não vou ser verboso.Se estourar, o servidor também fechará a conexão do cliente.
- O lado do servidor retornou muitos dados, que foram preenchidos de uma só vez
- A velocidade de retorno de dados é muito rápida, como executar o comando MONITOR, ele continuará a produzir as operações de comando monitoradas
- O tamanho do buffer é definido de forma não razoável.
3.3 Otimização
Da mesma forma, não leia grandes quantidades de dados de uma só vez; não execute comandos MONITOR continuamente no fio.
O tamanho do buffer de saída pode ser definido por client-output-buffer-limit.
Mas em geral, não precisamos alterá-lo, pois o padrão é suficiente, basta entender aqui.
Vale ressaltar que as mensagens de publicação e assinatura do Redis também estão nesse buffer, que pode ser usado client-output-buffer-limit pubsub 8mb 2mb 60para limitar o tamanho.
- pubsub significa configurar o cliente assinante. Mude para normal para indicar que a configuração atual é um cliente normal
- O significado de toda a configuração é: se o tamanho do buffer realmente ocupado exceder 8 MB, ou se a quantidade de gravação no buffer de saída exceder 2 MB em 60 segundos consecutivos, o servidor fechará a conexão do cliente.
4. Copie o buffer
Como um lembrete caloroso, se você não conhece a sincronização/replicação do Redis, como replicação completa/incremental, pode ler meu artigo: Este artigo permitirá que você entenda a sincronização mestre-escravo do Redis .
Voltando ao tópico abaixo.
Deve haver replicação mestre-escravo, e a replicação de dados entre mestre-escravo inclui replicação completa e replicação incremental.
A replicação completa é para sincronizar todos os dados, enquanto a replicação incremental sincroniza apenas os comandos recebidos pela biblioteca mestre durante a desconexão da rede das bibliotecas mestre e escrava para a biblioteca escrava.
4.1 Função
Dados de preparo.
Um buffer de replicação é mantido no nó mestre para cada nó escravo .
Durante a replicação completa, o nó mestre continuará recebendo a solicitação de comando de gravação enviada pelo cliente enquanto transfere o arquivo RDB para o nó escravo e o salva no buffer de replicação. Após a conclusão da transferência do arquivo RDB, ele será enviado para o nó escravo para execução.
4.2 Cenários de estouro
Receber e carregar RDBs do nó escravo é lento e o nó mestre recebe um grande número de comandos de gravação.Os comandos de gravação se acumularão no buffer de replicação e eventualmente estourarão.
Uma vez estourado, o nó mestre fechará diretamente a conexão com o nó escravo para a operação de replicação, resultando na falha da replicação completa.
4.3 Otimização
O volume de dados do nó mestre pode ser controlado entre 2 a 4 GB (somente para referência), o que pode tornar a sincronização completa mais rápida e evitar o acúmulo de muitos comandos no buffer de cópia.
O tamanho do buffer também pode ser ajustado, que é o mesmo do client-output-buffer-limitparâmetro .
por exemplo: config set client-output-buffer-limit slave 512mb 128mb 60
- O parâmetro slave indica que o item de configuração é para o buffer de replicação.
- O significado de toda a configuração é: se o tamanho real do buffer ocupado exceder 512 MB, ou se a quantidade de gravação no buffer de saída exceder 128 MB em 60 segundos consecutivos, o servidor fechará a conexão síncrona.
5. Copie o buffer de pendências
Este é o buffer usado na nova cópia.
Para a introdução específica, recomenda-se a leitura do artigo mencionado acima, escrevi mais de 2k palavras aqui e não aguento.
5.1 Função
Dados de preparo.
Depois que o nó escravo for desconectado inesperadamente e se reconectar, ele poderá recuperar os dados que não foram sincronizados durante a sincronização desse buffer.
5.2 Cenários de estouro
Não vai transbordar. (Não consigo pensar nisso.jpg)
O buffer é essencialmente uma fila de comprimento fixo, primeiro a entrar, primeiro a sair , o padrão é 1 MB.
Portanto, quando a fila está cheia, não é um erro, nem a conexão é fechada diretamente como os buffers acima. Em vez disso, ele substitui os dados que entraram na fila mais cedo.
Portanto, se houver nós escravos que não sincronizaram esses dados de comando antigos, isso fará com que os nós mestre e escravo refaçam a replicação completa em vez da replicação incremental.
PS: A sobrecarga de desempenho da replicação completa é muito maior do que a replicação incremental
5.3 Otimização
Ajuste o tamanho do buffer de backlog de replicação, os parâmetros são:repl_backlog_size