Desenvolvimento com o Azure Managed Redis(pré-visualização)
Resiliência da conexão e carga do servidor
Ao desenvolver aplicativos cliente, certifique-se de considerar as práticas recomendadas relevantes para resiliência de conexão e gerenciamento de carga do servidor.
Considere mais chaves e valores menores
O Azure Managed Redis (visualização) funciona melhor com valores menores. Para distribuir os dados por várias chaves, considere dividir blocos maiores de dados em blocos menores. Para obter mais informações sobre o tamanho do valor ideal, consulte este artigo.
Grande tamanho de solicitação ou resposta
Um pedido/resposta grande pode provocar tempos limite. Como exemplo, suponha que o valor de tempo limite configurado no cliente seja de 1 segundo. Seu aplicativo solicita duas chaves (por exemplo, 'A' e 'B') ao mesmo tempo (usando a mesma conexão de rede física). A maioria dos clientes suporta pipelining de pedidos, onde ambos os pedidos 'A' e 'B' são enviados um após o outro sem esperar por suas respostas. O servidor envia as respostas de volta na mesma ordem. Se a resposta 'A' for grande, ela pode consumir a maior parte do tempo limite para solicitações posteriores.
No exemplo a seguir, as solicitações 'A' e 'B' são enviadas rapidamente para o servidor. O servidor começa a enviar respostas 'A' e 'B' rapidamente. Devido aos tempos de transferência de dados, a resposta 'B' deve aguardar o tempo limite da resposta 'A', mesmo que o servidor tenha respondido rapidamente.
|-------- 1 Second Timeout (A)----------|
|-Request A-|
|-------- 1 Second Timeout (B) ----------|
|-Request B-|
|- Read Response A --------|
|- Read Response B-| (**TIMEOUT**)
Este pedido/resposta é difícil de medir. Você pode instrumentar o código do seu cliente para rastrear grandes solicitações e respostas.
As resoluções para grandes tamanhos de resposta são variadas, mas incluem:
- Otimize seu aplicativo para um grande número de valores pequenos, em vez de alguns valores grandes.
- A solução preferida é dividir seus dados em valores menores relacionados.
- Veja o post Qual é a faixa de tamanho de valor ideal para redis? 100 KB é muito grande? para obter detalhes sobre por que valores menores são recomendados.
- Aumente o tamanho da sua máquina virtual (VM) para obter maiores recursos de largura de banda
- Mais largura de banda em sua VM cliente ou servidor pode reduzir os tempos de transferência de dados para respostas maiores.
- Compare o uso atual da rede em ambas as máquinas com os limites do tamanho atual da VM. Mais largura de banda apenas no servidor ou apenas no cliente pode não ser suficiente.
- Aumente o número de objetos de conexão que seu aplicativo usa.
- Use uma abordagem round-robin para fazer solicitações em diferentes objetos de conexão.
Use tubulação
Tente escolher um cliente Redis que suporte pipelining Redis. O pipelining ajuda a fazer uso eficiente da rede e obter o melhor rendimento possível.
Evite operações dispendiosas
Algumas operações Redis, como o comando KEYS, são caras e devem ser evitadas. Para obter algumas considerações sobre comandos de longa execução, consulte Comandos de longa execução.
Escolha um nível apropriado
O Azure Managed Redis oferece níveis otimizados para memória, equilibrados, otimizados para computação e otimizados para flash. Veja mais informações sobre como escolher um nível aqui. Recomendamos testes de desempenho para escolher a camada certa e validar as configurações de conexão. Para obter mais informações, consulte Testes de desempenho.
Escolha um modo de disponibilidade apropriado
O Azure Managed Redis oferece a opção de habilitar ou desabilitar a configuração de alta disponibilidade. Quando o modo de alta disponibilidade estiver desativado, os dados da instância AMR não serão replicados e, portanto, a instância do Redis ficará indisponível durante a manutenção. Todos os dados na instância AMR também serão perdidos em caso de manutenção planejada ou não planejada. Recomendamos desativar a alta disponibilidade apenas para suas cargas de trabalho de desenvolvimento ou teste. O desempenho das instâncias Redis com alta disponibilidade também pode ser menor devido à falta de replicação de dados, que é crucial distribuir a carga entre o fragmento de dados primário e de réplica.
Cliente na mesma região que a instância do Redis
Localize sua instância Redis e seu aplicativo na mesma região. Conectar-se a um Redis em uma região diferente pode aumentar significativamente a latência e reduzir a confiabilidade.
Embora você possa se conectar de fora do Azure, isso não é recomendado, especialmente ao usar o Redis para acelerar o desempenho do aplicativo ou do banco de dados. Se você estiver usando o servidor Redis apenas como um armazenamento de chave/valor, a latência pode não ser a principal preocupação.
Confie no nome do host, não no endereço IP público
O endereço IP público atribuído à sua instância AMR pode ser alterado como resultado de uma operação de escala ou melhoria de back-end. Recomendamos confiar no nome do host em vez de um endereço IP público explícito.
Usar criptografia TLS
O Azure Managed Redis requer comunicações criptografadas TLS por padrão. As versões 1.2 e 1.3 do TLS são suportadas atualmente. Se a sua biblioteca ou ferramenta de cliente não suportar TLS, é possível ativar conexões não criptografadas.
Monitore o uso de memória, métricas de uso da CPU, conexões de cliente e largura de banda de rede
Ao usar a instância do Azure Managed Redis em produção, recomendamos definir alertas para "Porcentagem de memória usada", métricas "CPU", "Clientes conectados". Se essas métricas estiverem consistentemente acima de 75%, considere dimensionar sua instância para uma memória maior ou uma camada de taxa de transferência melhor. Veja quando dimensionar para obter mais detalhes.
Considere habilitar a persistência de dados ou o backup de dados
O Redis foi projetado para dados efêmeros por padrão, o que significa que, em casos raros, seus dados podem ser perdidos devido a várias circunstâncias, como manutenção ou interrupções. Se seu aplicativo for sensível à perda de dados, recomendamos habilitar a persistência de dados ou o backup periódico de dados usando a operação de exportação de dados.
O recurso de persistência de dados foi projetado para fornecer automaticamente um ponto de recuperação rápida para os dados quando um cache fica inativo. A recuperação rápida é possível armazenando o arquivo RDB ou AOF em um disco gerenciado montado na instância de cache. Os arquivos de persistência no disco não estão acessíveis aos usuários ou não podem ser usados por nenhuma outra instância AMR.
Muitos clientes querem usar a persistência para fazer backups periódicos dos dados em seu cache. Não recomendamos que você use a persistência de dados dessa maneira. Em vez disso, use o recurso de importação/exportação . Você pode exportar cópias de dados no formato RDB diretamente para sua conta de armazenamento escolhida e acionar a exportação de dados com a frequência necessária. Esses dados exportados podem ser importados para qualquer instância do Redis. A exportação pode ser acionada a partir do portal ou usando as ferramentas CLI, PowerShell ou SDK.
Orientação específica da biblioteca do cliente
Para obter mais informações, consulte Bibliotecas do Cliente Redis Gerenciado do Azure