Resiliência da conexão com o Azure Managed Redis (visualização)
Repetir comandos
Configure suas conexões de cliente para repetir comandos com backoff exponencial. Para obter mais informações, consulte Diretrizes de novas tentativas.
Configurações de TCP para aplicativos cliente hospedados no Linux
As configurações padrão de TCP 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 detete conexões fechadas e as restaure automaticamente se a conexão não tiver sido fechada normalmente.
A falha ao restabelecer uma conexão pode acontecer 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:
| Definição | Value |
|---|---|
net.ipv4.tcp_retries2 |
5 |
Para obter mais informações sobre o cenário, consulte A conexão não restabelece por 15 minutos ao ser executada no Linux. Embora esta discussão seja sobre a biblioteca StackExchange.Redis , outras bibliotecas de cliente em execução no Linux também são afetadas. A explicação ainda é útil e você pode generalizar para outras bibliotecas.
Utilizar ForceReconnect com StackExchange.Redis
Em casos raros, o StackExchange.Redis não consegue se reconectar depois que uma conexão é interrompida. Nesses casos, reiniciar o cliente ou criar um novo ConnectionMultiplexer corrige o problema. Recomendamos o uso de um padrão singleton ConnectionMultiplexer enquanto permite 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 quaisquer ObjectDisposedException erros que possam ocorrer como resultado do descarte do antigo.
Ligue ForceReconnectAsync() para RedisConnectionExceptions e RedisSocketExceptions. Você também pode chamar ForceReconnectAsync() , RedisTimeoutExceptionsmas apenas se estiver usando generoso ReconnectMinInterval e ReconnectErrorThreshold. Caso contrário, o estabelecimento de novas conexões pode causar uma falha em cascata em um servidor que está expirando porque 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 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 a considerar na 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 seu cliente espera para estabelecer uma conexão com o servidor Redis. Configure sua biblioteca de cliente 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 pequeno connection timeout valor não garante que uma conexão seja estabelecida nesse período de tempo. Se algo der errado (alta CPU do cliente, alta CPU do servidor e assim por diante), um valor curto connection timeout fará com que a tentativa de conexão falhe. Esse comportamento muitas vezes piora uma situação ruim. Em vez de ajudar, tempos limite mais curtos agravam o problema, forçando o sistema a reiniciar o processo de tentar se reconectar, o que pode levar a um loop de conexão -> falha -> repetição .
Tempo limite do comando
A maioria das bibliotecas de cliente tem outra configuração de tempo limite para command timeouts, que é o tempo que o cliente aguarda uma resposta do servidor Redis. Embora recomendemos uma configuração inicial de menos de cinco segundos, considere definir a maior ou a command timeout menor, dependendo do cenário e dos tamanhos dos valores armazenados no cache.
Se o command timeout for muito pequeno, a conexão pode parecer instável. No entanto, se o command timeout for muito grande, seu aplicativo pode ter que esperar por um longo tempo para descobrir se o comando vai expirar ou não.
Evitar picos de ligações do cliente
Evite criar muitas conexões ao mesmo tempo ao se reconectar após uma perda de conexão, pois as novas criações de conexão são limitadas. Da mesma forma que 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 estender o tempo que leva para todos os clientes se reconectarem com êxito.
Se você estiver reconectando muitas instâncias de cliente, considere escalonar as novas conexões para evitar que suas novas conexões sejam limitadas.
Nota
Quando você usa a biblioteca de cliente StackExchange.Redis , defina abortConnect como false em sua cadeia de conexão. Recomendamos deixar o ConnectionMultiplexer identificador reconectar. Para obter mais informações, consulte Práticas recomendadas do StackExchange.Redis.
Evite conexões que sobraram
Os caches têm limites para o número de conexões de cliente por camada de cache. Certifique-se de que, quando o aplicativo cliente recriar conexões, ele feche e remova as conexões antigas.
Janela de manutenção agendada
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 quaisquer efeitos negativos no cache, consulte Atualizar canal e Agendar atualizações.
Mais padrões de design para resiliência
Aplique padrões de design para resiliência. Para obter mais informações, consulte Como faço para tornar meu aplicativo resiliente.
Tempo limite de inatividade
O Azure Managed Redis (visualização) 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 com vazamento ou conexões órfãs por um aplicativo cliente. A maioria das bibliotecas de cliente Redis tem um recurso interno para enviar heartbeat ou keepalive comandos periodicamente para evitar 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 inferior a 10 minutos. Se seu aplicativo estiver usando uma biblioteca de cliente que não tenha suporte nativo para keepalive funcionalidade, você poderá implementá-lo em seu aplicativo enviando periodicamente um PING comando.