Resiliência da conexão
Comandos de repetir
Configure as conexões de cliente para repetir comandos com retirada exponencial. Para obter mais informações, confira as diretrizes de repetição.
Testar resiliência
Teste a resiliência do sistema para interrupções de conexão usando uma reinicialização para simular um patch. Para obter mais informações sobre como testar seu desempenho, consulte Teste de desempenho.
Configurações 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 detecte conexões fechadas e as restaure automaticamente quando a conexão não for fechada corretamente.
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ção | Valor |
|---|---|
net.ipv4.tcp_retries2 |
5 |
Para obter mais informações sobre o cenário, confira Conexão não é restabelecida por 15 minutos ao executar no Linux. Embora essa 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.
Usando ForceReconnect com o StackExchange.Redis
Em casos raros, o StackExchange.Redis falha ao se reconectar depois que uma conexão é descartada. Nesses casos, reiniciar o cliente ou criar um ConnectionMultiplexer corrige o problema. É recomendável usar um padrão ConnectionMultiplexer singleton ao permitir 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 guias de início rápido.
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 propriedade UseForceReconnect como “true”:
Microsoft.AspNetCore.Caching.StackExchangeRedis.UseForceReconnect = true
Configurar tempos limite apropriados
É importante considerar dois valores de tempo limite na resiliência da conexão: o tempo limite da conexão e o tempo limite do 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 clientes para usar um connect timeout de cinco segundos, dando ao sistema tempo suficiente para se conectar mesmo sob condições de alto uso da CPU.
Um valor baixo de connection timeout não garante que a conexão seja estabelecida nesse período. Se algo der errado (alto uso da CPU do cliente ou do servidor e assim por diante), um valor connection timeout baixo causará falha na tentativa de conexão. Esse comportamento geralmente piora a situação. Em vez de ajudar, tempos limite menores agravam o problema, ao forçam o sistema a reiniciar o processo de tentativa de reconexão, o que pode levar a um loop de conexão -> falha -> nova tentativa.
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 espera por uma resposta do servidor Redis. Embora seja recomendável uma configuração inicial de menos de cinco segundos, considere definir o command timeout maior ou menor, dependendo de seu cenário, e os tamanhos dos valores que são armazenados em seu cache.
Quando o command timeout é muito baixo, a conexão pode parecer instável. No entanto, se o command timeout for muito alto, seu aplicativo pode ter que esperar muito tempo para descobrir se o tempo limite do comando será atingido 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 repentino no número de clientes conectados.
Observação
Quando você usa a biblioteca de clientes StackExchange.Redis, defina o valor abortConnect como false em sua cadeia de conexão. Recomendamos permitir a reconexão do identificador ConnectionMultiplexer. Para obter mais informações, confira as melhores práticas de StackExchange.Redis.
Evitar conexões restantes
Os caches têm limites de número de conexões de cliente por nível de cache. Verifique se o aplicativo cliente fecha e remove as conexões antigas quando recria conexões.
Notificação de manutenção antecipada
Use notificações para ser informado sobre manutenções futuras. Para obter mais informações, consulte Posso ser notificado com antecedência sobre uma manutenção planejada?
Janela de manutenção de agendamento
Ajuste suas 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 em seu cache, consulte Atualizar o canal e Agendar as atualizações.
Outros padrões de design para resiliência
Aplique padrões de design para resiliência. Para obter mais informações, confira Como tornar meu aplicativo resiliente.
Tempo limite de ociosidade
O Cache do Azure para Redis tem um tempo limite de dez minutos para conexões ociosas. O tempo limite de dez minutos permite que o servidor limpe automaticamente as conexões perdidas ou as que ficaram órfãs devido a um aplicativo cliente. A maioria das bibliotecas de clientes do Redis tem uma capacidade interna de enviar comandos heartbeat ou keepalive periodicamente para impedir que as conexões sejam fechadas mesmo que não haja solicitações do aplicativo cliente.
Se houver risco de que as conexões fiquem ociosas por dez minutos, configure o intervalo keepalive com um valor menor que dez minutos. Se o aplicativo estiver usando uma biblioteca de clientes sem suporte nativo para a funcionalidade keepalive, você poderá implementá-lo no aplicativo enviando periodicamente um comando PING.