Desenvolvimento com Azure Managed Redis

  • Aplica-se a: ✅ Azure Managed Redis

Este artigo discute como desenvolver código para Azure Managed Redis.

Resiliência da conexão e carga do servidor

Ao desenvolver aplicações cliente, considere as melhores práticas relevantes para resiliência de ligação e gestão da carga do servidor.

Considere mais chaves e valores menores

O Azure Managed Redis funciona melhor com valores mais pequenos. Para distribuir os dados por múltiplas chaves, considere dividir blocos maiores de dados em blocos mais pequenos. Para mais informações sobre o tamanho ideal, consulte este artigo.

Grande tamanho de solicitação ou resposta

Um pedido ou resposta grande pode causar tempos de espera. Por exemplo, suponha que configura o valor de timeout no seu cliente como 1 segundo. A sua aplicação solicita duas chaves (por exemplo, A e B) ao mesmo tempo (usando a mesma ligação física de rede). A maioria dos clientes suporta o encadeamento de pedidos, em que tanto os pedidos A como B são enviados um após o outro sem esperar pelas respetivas respostas. O servidor envia as respostas de volta na mesma ordem. Se a resposta A for grande, pode consumir a maior parte do tempo limite para as solicitações seguintes.

No exemplo seguinte, os pedidos A e B são enviados 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 tem de esperar pela expiração 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 padrão de pedido e 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 tamanhos de resposta grandes variam, mas incluem:

  • Otimize seu aplicativo para um grande número de valores pequenos, em vez de alguns valores grandes.
  • Aumente o tamanho da sua máquina virtual (VM) para obter maiores capacidades 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 a utilização 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 ligação que a sua aplicação utiliza.
    • 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 do Redis, como o comando KEYS , são caras e deves evitá-las. 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 de Otimização de Memória, Balanceado, Otimizado para Computação e Otimizado para Flash. Para obter mais informações sobre como escolher uma camada, consulte Como dimensionar. Teste o desempenho para escolher o nível certo e validar as definições de ligaçã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 ativar ou desativar a configuração de alta disponibilidade. Quando desativas o modo de alta disponibilidade, os dados na tua instância AMR não são replicados e a tua instância Redis fica indisponível durante a manutenção. Todos os dados na instância AMR são perdidos durante a manutenção planejada ou não planejada. Desative a alta disponibilidade apenas para as suas cargas de desenvolvimento ou testes. O desempenho das instâncias Redis com alta disponibilidade também pode ser inferior devido à falta de replicação de dados, que é crucial para distribuir a carga entre o shard de dados primário e o shard 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 possas ligar-te fora do Azure, não é recomendado, especialmente quando usas o Redis para acelerar o desempenho da tua aplicação ou base 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 atribuído à sua cache pode mudar como resultado de uma operação de escala ou melhoria no backend. Confie no nome de host em vez de um endereço IP público ou privado explícito. O endereço IP estático configurado para uma cache numa rede virtual não é uma garantia imutável e pode mudar durante certas operações, embora as alterações sejam raras.

Os nomes de host no Azure Managed Redis são assim: <DNS name>.<Azure region>.redis.azure.net

Usar criptografia TLS

O Azure Managed Redis requer comunicações encriptadas TLS por defeito. 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 utilizar uma instância Azure Managed Redis em produção, defina alertas para as métricas Percentagem de Memória Utilizada, CPU e Clientes Ligados. 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. Para obter mais detalhes, consulte quando dimensionar. Para detalhes sobre como a memória é reportada e como planear a capacidade, consulte gestão de memória.

Considere ativar persistência de dados ou 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 a sua aplicação for sensível à perda de dados, ative a persistência de dados ou o backup periódico de dados utilizando a operação de exportação de dados.

A funcionalidade de persistência de dados fornece automaticamente um ponto de recuperação rápida para os dados quando uma cache fica indisponível. A recuperação rápida é possível porque a funcionalidade armazena o ficheiro RDB ou AOF num disco gerido que monta na instância de cache. Os utilizadores não conseguem aceder a ficheiros de persistência no disco, e nenhuma outra instância AMR pode usá-los.

Muitos clientes querem usar a persistência para fazer backups periódicos dos dados em seu cache. Não uses persistência de dados para este fim. Em vez disso, use a funcionalidade 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. Podes ativar a exportação a partir do portal ou usando as ferramentas CLI, PowerShell ou SDK.

Orientação específica para bibliotecas de cliente

Para mais informações, consulte Azure Managed Redis Client Libraries.

Conteúdo relacionado

  • Last updated on