Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Importante
O Cache do Azure para Redis anunciou a linha do tempo de desativação para todos os SKUs. Recomendamos migrar suas instâncias do Cache do Azure para Redis para o Redis Gerenciado pelo Azure assim que possível.
Para obter mais detalhes sobre a aposentadoria:
Comandos de repetição
Configure as conexões de cliente para repetir comandos com retirada exponencial. Para obter mais informações, consulte as diretrizes de repetição.
Testar resiliência
Teste a resiliência do sistema com quebras de conexão usando uma reinicialização para simular um patch. Para obter mais informações sobre como testar seu desempenho, consulte o teste de desempenho.
Configurações de TCP para aplicativos cliente hospedados no Linux
As configurações de TCP padrão em algumas versões do Linux podem fazer com que as conexões do servidor Redis falhem por 13 minutos ou mais. As configurações padrão podem impedir que o aplicativo cliente detecte conexões fechadas e restaure-as automaticamente se a conexão não tiver sido fechada normalmente.
A falha ao restabelecer uma conexão pode ocorrer em situações em que a conexão de rede é interrompida ou o servidor Redis fica offline para manutenção não planejada.
Recomendamos estas configurações de TCP:
| Configurações | Value |
|---|---|
net.ipv4.tcp_retries2 |
5 |
Para obter mais informações sobre o cenário, consulte Conexão não se restabelece por 15 minutos quando executado no Linux. Embora essa discussão seja sobre a biblioteca StackExchange.Redis , outras bibliotecas de clientes em execução no Linux também são afetadas. A explicação ainda é útil e você pode generalizar para outras bibliotecas.
Usando ForceReconnect com StackExchange.Redis
Em casos raros, StackExchange.Redis não consegue se reconectar depois que uma conexão é descartada. Nesses casos, reiniciar o cliente ou criar um novo ConnectionMultiplexer corrige o problema. É recomendável usar um padrão singleton ConnectionMultiplexer , permitindo que os aplicativos forcem uma reconexão periodicamente. Dê uma olhada no projeto de exemplo de início rápido que melhor corresponde à estrutura e à plataforma que seu aplicativo usa. Você pode ver um exemplo desse padrão de código em nossos inícios rápidos.
Os usuários do ConnectionMultiplexer devem lidar com todos os erros de ObjectDisposedException que possam ocorrer como resultado do descarte do antigo.
Chame ForceReconnectAsync() para RedisConnectionExceptions e RedisSocketExceptions. Você também pode chamar ForceReconnectAsync() para RedisTimeoutExceptions, mas somente se estiver usando ReconnectMinInterval e ReconnectErrorThreshold generosos. Caso contrário, estabelecer novas conexões poderá causar uma falha em cascata em um servidor que atingirá o runtime porque ele já está sobrecarregado.
Em um aplicativo ASP.NET, você pode usar a implementação integrada no pacote Microsoft.Extensions.Caching.StackExchangeRedis em vez de usar o pacote StackExchange.Redis diretamente. Se você estiver usando Microsoft.Extensions.Caching.StackExchangeRedis em um aplicativo ASP.NET em vez de usar o StackExchange.Redis diretamente, poderá definir a UseForceReconnect propriedade como true:
Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true
Configurar tempos limite apropriados
Dois valores de tempo limite são importantes para considerar a resiliência da conexão: tempo limite de conexão e tempo limite de comando.
Tempo limite de conexão
O connect timeout é o tempo que o cliente espera para estabelecer uma conexão com o servidor do Redis. Configure sua biblioteca de clientes para usar um connect timeout de cinco segundos, dando ao sistema tempo suficiente para se conectar mesmo em condições de CPU mais altas.
Um valor pequeno connection timeout não garante que uma conexão seja estabelecida nesse período. Se algo der errado (CPU de cliente alto, CPU de alto servidor e assim por diante), um valor curto connection timeout fará com que a tentativa de conexão falhe. Esse comportamento geralmente piora a situação. Em vez de ajudar, tempos limite mais curtos agravam o problema forçando o sistema a reiniciar o processo de tentativa de reconexão, o que pode levar a um loop de repetição de conexão –> falha>.
Tempo limite do comando
A maioria das bibliotecas de clientes tem outra configuração de tempo limite, command timeoutsque é o momento em que o cliente aguarda uma resposta do servidor Redis. Embora recomendemos uma configuração inicial de menos de cinco segundos, considere definir a command timeout maior ou menor, dependendo do cenário e dos tamanhos dos valores armazenados em seu cache.
Se o command timeout for muito pequeno, a conexão poderá parecer instável. No entanto, se o command timeout for muito grande, seu aplicativo talvez tenha que aguardar muito tempo para descobrir se o comando vai expirar ou não.
Evitar picos de conexão do cliente
Evite criar muitas conexões ao mesmo tempo ao se reconectar após uma perda de conexão. Assim como os tempos limite de conexão curtos podem resultar em interrupções mais longas, iniciar muitas tentativas de reconexão ao mesmo tempo também pode aumentar a carga do servidor e o tempo para que todos os clientes se reconectem com êxito.
Se você estiver reconectando muitas instâncias de cliente, considere escalonar as novas conexões para evitar um pico acentuado no número de clientes conectados.
Observação
Ao usar a biblioteca de clientes StackExchange.Redis , defina abortConnect como false na cadeia de conexão. É recomendável deixar o ConnectionMultiplexer lidar com a reconexão. Para obter mais informações, consulte as práticas recomendadas do StackExchange.Redis.
Evitar conexões remanescentes
Os caches têm limites no número de conexões de cliente por camada de cache. Verifique se quando o aplicativo cliente recria as conexões que ele fecha e remove as conexões antigas.
Notificação de manutenção antecipada
Use notificações para saber mais sobre a manutenção futura. Para obter mais informações, consulte Posso ser notificado antes de uma manutenção planejada.
Agendar janela de manutenção
Ajuste as configurações de cache para acomodar a manutenção. Para obter mais informações sobre como criar uma janela de manutenção para reduzir os efeitos negativos no cache, consulte Atualizações do canal e agendamento.
Mais padrões de design para resiliência
Aplique padrões de design para resiliência. Para obter mais informações, consulte Como fazer para tornar meu aplicativo resiliente.
Tempo limite de ociosidade
O Cache do Azure para Redis tem um tempo limite de 10 minutos para conexões ociosas. O tempo limite de 10 minutos permite que o servidor limpe automaticamente conexões vazadas ou conexões órfãs por um aplicativo cliente. A maioria das bibliotecas de clientes redis tem uma capacidade interna de enviar heartbeat ou keepalive comandos periodicamente para impedir que as conexões sejam fechadas mesmo que não haja solicitações do aplicativo cliente.
Se houver algum risco de suas conexões ficarem ociosas por 10 minutos, configure o keepalive intervalo para um valor menor que 10 minutos. Se o aplicativo estiver usando uma biblioteca de clientes que não tem suporte nativo para keepalive funcionalidade, você poderá implementá-lo em seu aplicativo enviando periodicamente um PING comando.