Desenvolvimento com Redis Gerenciado do Azure

  • Aplica-se a: ✅ Azure Managed Redis

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

Resiliência de conexão e carga do servidor

Ao desenvolver aplicativos cliente, considere as práticas recomendadas relevantes para resiliência de conexão e gerenciamento de carga do servidor.

Considere mais chaves e valores menores

Azure Redis Gerenciado funciona melhor com valores menores. Para espalhar os dados em várias chaves, considere dividir partes maiores de dados em partes menores. Para obter mais informações sobre o tamanho ideal do valor, consulte este artigo.

Tamanho grande de solicitação ou resposta

Uma solicitação ou resposta grande pode causar tempos limite. Por exemplo, suponha que você configure o valor de tempo limite em seu cliente como 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 o encadeamento de solicitações, em que ambas as solicitações A e B são enviadas uma após a outra sem esperar por suas respostas. O servidor devolve as respostas na mesma ordem. Se a resposta A for grande, ela poderá consumir a maior parte do tempo limite das solicitações posteriores.

No exemplo a seguir, as solicitações A e B são enviadas rapidamente ao 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 que a resposta A atinja o tempo limite, 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**)

Esse padrão de solicitação e resposta é difícil de medir. Você pode instrumentar o código do cliente para monitorar grandes solicitações e respostas.

As resoluções para tamanhos de resposta grandes variam, mas incluem:

  • Otimizar o aplicativo para um grande número de valores pequenos, em vez de alguns valores grandes.
  • Aumente o tamanho da VM (máquina virtual) para obter recursos de largura de banda mais altos.
    • Mais largura de banda em sua VM de cliente ou servidor pode reduzir os tempos de transferência de dados para respostas maiores.
    • Compare o uso de rede atual em ambos os computadores com os limites do tamanho atual da VM. Mais largura de banda somente no servidor ou somente no cliente pode não ser suficiente.
  • Aumentar o número de objetos de conexão que o aplicativo usa.
    • Use uma abordagem Round Robin para fazer solicitações em diferentes objetos de conexão.

Uso do pipelining

Tente escolher um cliente Redis que dê suporte ao pipelining Redis. O pipelining ajuda a fazer uso eficiente da rede e obter a melhor taxa de transferência possível.

Evite operações caras

Algumas operações do Redis, como o comando KEYS, são custosas e você deve evitá-las. Para ver algumas considerações sobre comandos de execução prolongada, confira comandos de execução prolongada.

Escolha uma camada adequada

Azure Redis Gerenciado oferece camadas Otimizadas para Memória, Balanceadas, Otimizadas para Computação e Otimizadas para Flash. Para obter mais informações sobre como escolher uma camada, consulte Como dimensionar. Teste o desempenho para escolher a camada certa e validar as configurações de conexão. Para obter mais informações, confira Teste de desempenho.

Escolha uma modo de disponibilidade adequado

Azure Redis Gerenciado oferece a opção de habilitar ou desabilitar a configuração de alta disponibilidade. Quando você desabilitar o modo de alta disponibilidade, os dados em sua instância amr não serão replicados e sua instância do Redis não estará disponível durante a manutenção. Todos os dados na instância amr são perdidos durante a manutenção planejada ou não planejada. Desabilite a alta disponibilidade somente para suas cargas de trabalho de desenvolvimento ou teste. O desempenho de instâncias do Redis com alta disponibilidade também pode ser inferior devido à falta de replicação de dados, que é crucial para distribuir a carga entre os fragmentos de dados primário e de réplica.

Cliente na mesma região que a instância do Redis

Localize sua instância do 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 de Azure, não é recomendável, especialmente ao usar o Redis para acelerar o desempenho do aplicativo ou do banco de dados. Se você estiver usando o servidor Redis como apenas um repositório de chave/valor, a latência pode não ser a principal preocupação.

Confiar no endereço IP público do nome do host

O endereço IP atribuído ao cache pode ser alterado como resultado de uma operação de escala ou melhoria de back-end. Confie no nome do host em vez de um endereço IP público ou privado explícito. O endereço IP estático configurado para um cache em uma rede virtual não é uma garantia imutável e pode ser alterado durante determinadas operações, embora as alterações sejam raras.

Os nomes de host no Azure Managed Redis se parecem com isto: <DNS name>.<Azure region>.redis.azure.net

Uso de criptografia do TLS

Azure Redis Gerenciado requer comunicações criptografadas TLS por padrão. No momento, há suporte para o TLS nas versões 1.2 e 1.3. Se sua ferramenta ou biblioteca de clientes não oferecer suporte ao TLS, é possível habilitar as conexões não criptografadas.

Monitorar o uso de memória, as métricas de uso da CPU, as conexões do cliente e a largura de banda de rede

Ao usar a instância gerenciada do Azure Redis em produção, defina alertas para as métricas Percentual de memória usada, CPU e Clientes conectados. Se essas métricas estiverem continuamente acima de 75%, considere escalar sua instância para uma camada de serviço de memória maior ou com uma melhor taxa de transferência. Para mais detalhes, veja quando escalar. Para obter detalhes sobre como a memória é relatada e como planejar a capacidade, consulte o gerenciamento de memória.

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 raras ocasiões, seus dados podem ser perdidos devido a várias circunstâncias, como manutenção ou interrupções. Se o aplicativo for sensível à perda de dados, habilite 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 fornece automaticamente um ponto de recuperação rápida para dados quando um cache fica inativo. A recuperação rápida é possível porque o recurso armazena o arquivo RDB ou AOF em um disco gerenciado que ele monta na instância de cache. Os usuários não podem acessar arquivos de persistência no disco e nenhuma outra instância amr pode usá-los.

Muitos clientes desejam usar a persistência para fazer backups periódicos dos dados em seu cache. Não use persistência de dados para essa finalidade. Em vez disso, use o recurso importação/exportação. Você pode exportar cópias de dados no formato RDB diretamente para a conta de armazenamento escolhida e acionar a exportação de dados com a frequência necessária. Você pode disparar a exportação do portal ou usando as ferramentas CLI, PowerShell ou SDK.

Diretrizes específicas para a biblioteca de clientes

Para obter mais informações, consulte bibliotecas de cliente do Azure Managed Redis.

Conteúdo relacionado

  • Last updated on