Configuração do cliente Lettuce (Valkey e Redis) OSS

Esta seção descreve as opções de configuração recomendadas do Java e do Lettuce e como elas se aplicam aos ElastiCache clusters.

As recomendações nesta seção foram testadas com o Lettuce versão 6.2.2.

DNSCache Java TTL

A máquina virtual Java (JVM) armazena em cache as pesquisas de DNS nomes. Quando o JVM resolve um nome de host para um endereço IP, ele armazena o endereço IP em cache por um período de tempo especificado, conhecido como (). time-to-liveTTL

A escolha do TTL valor é uma troca entre latência e capacidade de resposta às mudanças. Com a versão mais curtaTTLs, DNS os resolvedores notam atualizações no cluster DNS mais rapidamente. Isso pode fazer com que sua aplicação responda com maior rapidez às substituições ou a outros fluxos de trabalho pelos quais seu cluster passa. No entanto, se TTL for muito baixo, ele aumentará o volume de consultas, o que pode aumentar a latência do seu aplicativo. Embora não haja um TTL valor correto, vale a pena considerar o tempo que você pode esperar até que uma alteração entre em vigor ao definir seu TTL valor.

Como ElastiCache os nós usam entradas de DNS nome que podem mudar, recomendamos que você configure seu JVM com um mínimo TTL de 5 a 10 segundos. Isso garante que, quando o endereço IP de um nó for alterado, seu aplicativo possa receber e usar o novo endereço IP do recurso solicitando a DNS entrada.

Em algumas configurações Java, o JVM padrão TTL é definido para que ele nunca atualize DNS as entradas até que JVM seja reiniciado.

Para obter detalhes sobre como definir seu JVMTTL, consulte Como definir JVM TTL o.

Versão do Lettuce

Recomendamos o Lettuce versão 6.2.2 ou posterior.

Endpoints

Quando você estiver usando clusters habilitados para o modo de cluster, defina o redisUri como o endpoint de configuração do cluster. A DNS busca por isso URI retorna uma lista de todos os nós disponíveis no cluster e é resolvida aleatoriamente para um deles durante a inicialização do cluster. Para obter mais detalhes sobre como a atualização de topologia funciona, consulte dynamicRefreshResourcesmais adiante neste tópico.

SocketOption

Habilitar KeepAlive. Quando habilitada, essa opção reduz a necessidade de lidar com falhas nas conexões durante o runtime de comando.

Defina Tempo limite de conexão com base nos requisitos da aplicação e na workload. Para ter mais informações, consulte “Tempos limite” posteriormente neste tópico.

ClusterClientOption: Opções de cliente habilitadas para o modo de cluster

Ative AutoReconnectquando a conexão for perdida.

Conjunto CommandTimeout. Para obter mais detalhes, consulte a seção “Tempos limite” mais adiante neste tópico.

nodeFilterDefina para filtrar os nós com falha da topologia. O Lettuce salva todos os nós encontrados na saída de “nós de cluster” (incluindo nós com FAIL statusPFAIL/) nas 'partições' do cliente (também conhecidas como fragmentos). Durante o processo de criação da topologia do cluster, ele tenta se conectar a todos os nós da partição. Esse comportamento do Lettuce ao adicionar nós com falha pode causar erros de conexão (ou avisos) quando os nós são substituídos por algum motivo.

Por exemplo, depois que um failover é concluído e o cluster inicia o processo de recuperação, enquanto ele clusterTopology é atualizado, o mapa dos nós do barramento do cluster tem um curto período de tempo em que o nó inativo é listado como um FAIL nó, antes de ser completamente removido da topologia. Durante esse período, o cliente do Lettuce o considera um nódulo saudável e se conecta continuamente a ele. Isso causa uma falha após o término da nova tentativa.

Por exemplo:

final ClusterClientOptions clusterClientOptions = 
    ClusterClientOptions.builder()
    ... // other options
    .nodeFilter(it -> 
        ! (it.is(RedisClusterNode.NodeFlag.FAIL) 
        || it.is(RedisClusterNode.NodeFlag.EVENTUAL_FAIL) 
        || it.is(RedisClusterNode.NodeFlag.HANDSHAKE)
        || it.is(RedisClusterNode.NodeFlag.NOADDR)))
    .validateClusterNodeMembership(false)
    .build();
redisClusterClient.setOptions(clusterClientOptions);

ClusterTopologyRefreshOptions: Opções para controlar a atualização da topologia do cluster do cliente habilitado para o modo de cluster

Habilitar enablePeriodicRefresh. Isso permite atualizações periódicas da topologia do cluster para que o cliente atualize a topologia do cluster nos intervalos do refreshPeriod (padrão: 60 segundos). Quando desabilitado, o cliente atualiza a topologia do cluster somente quando ocorrem erros ao tentar executar comandos no cluster.

Com essa opção habilitada, você pode reduzir a latência associada à atualização da topologia do cluster adicionando esse trabalho a uma tarefa em segundo plano. Embora a atualização da topologia seja executada em um trabalho em segundo plano, ela pode ser um pouco lenta para clusters com muitos nós. Isso ocorre porque todos os nós estão sendo consultados para obter a visualização mais atualizada do cluster. Se você executa um cluster grande, é recomendável aumentar o período.

Habilitar enableAllAdaptiveRefreshTriggers. Isso permite a atualização adaptativa da topologia que usa todos os acionadores: MOVED _REDIRECT, _, _, ASK _REDIRECT, PERSISTENT _RECONNECTS. UNCOVERED SLOT UNKNOWN NODE Os gatilhos de atualização adaptáveis iniciam atualizações de visualização de topologia com base em eventos que ocorrem durante as operações de cluster Valkey ou Redis. OSS Quando habilitada, essa opção ocasiona uma atualização imediata da topologia quando ocorre um dos acionadores anteriores. As atualizações adaptáveis acionadas têm uma taxa limitada usando um tempo limite porque os eventos podem ocorrer em grande escala (tempo limite padrão entre as atualizações: 30).

Habilitar closeStaleConnections. Isso possibilita fechar conexões obsoletas ao atualizar a topologia do cluster. Só entra em vigor se ClusterTopologyRefreshOptions. isPeriodicRefreshEnabled () é verdadeiro. Quando habilitado, o cliente pode fechar conexões obsoletas e criar outras em segundo plano. Isso reduz a necessidade de lidar com falhas nas conexões durante o runtime de comando.

Habilitar dynamicRefreshResources. Recomendamos ativá-la dynamicRefreshResources para clusters pequenos e desativá-la para clusters grandes. dynamicRefreshResourcespermite descobrir nós do cluster a partir do nó inicial fornecido (por exemplo, endpoint de configuração do cluster). Ele usa todos os nós descobertos como fontes para atualizar a topologia do cluster.

A atualização dinâmica consulta todos os nós descobertos para a topologia do cluster e tenta escolher a visualização mais precisa do cluster. Se for definido como falso, somente os nós iniciais serão usados como fontes para a descoberta da topologia e o número de clientes será obtido apenas para os nós iniciais. Quando desabilitado, se o endpoint de configuração do cluster for resolvido em um nó com falha, a tentativa de atualizar a visualização do cluster falhará e causará exceções. Esse cenário pode ocorrer porque demora até que a entrada de um nó com falha seja removida do endpoint de configuração do cluster. Portanto, o endpoint de configuração ainda pode ser resolvido aleatoriamente em um nó com falha por um curto período.

No entanto, quando está habilitado, usamos todos os nós do cluster recebidos da visualização do cluster para consultar a visualização atual. Como filtramos os nós com falha nessa visualização, a atualização da topologia será bem-sucedida. No entanto, quando dynamicRefreshSources é verdade, o Lettuce consulta todos os nós para obter a visualização do cluster e, em seguida, compara os resultados. Portanto, isso pode ser caro para clusters com muitos nós. Sugerimos que você desabilite esse recurso para clusters com muitos nós.

final ClusterTopologyRefreshOptions topologyOptions = 
    ClusterTopologyRefreshOptions.builder()
    .enableAllAdaptiveRefreshTriggers()
    .enablePeriodicRefresh()
    .dynamicRefreshSources(true)
    .build();

ClientResources

Configure DnsResolvercom DirContextDnsResolver. O DNS resolvedor é baseado no com.sun.jndi.dns do Java. DnsContextFactory.

Configure reconnectDelaycom recuo exponencial e instabilidade total. O Lettuce tem mecanismos de repetição integrados com base nas estratégias de recuo exponencial. Para obter detalhes, consulte Exponential Backoff and Jitter no blog de arquitetura. AWS Para obter mais informações sobre a importância de ter uma estratégia de recuo de repetição, consulte as seções de lógica de recuo da postagem do blog de melhores práticas no blog do AWS banco de dados.

ClientResources clientResources = DefaultClientResources.builder()
   .dnsResolver(new DirContextDnsResolver())
    .reconnectDelay(
        Delay.fullJitter(
            Duration.ofMillis(100),     // minimum 100 millisecond delay
            Duration.ofSeconds(10),      // maximum 10 second delay
            100, TimeUnit.MILLISECONDS)) // 100 millisecond base
    .build(); 

Tempos limite

Use um valor de tempo limite de conexão menor do que o tempo limite do comando. O Lettuce utiliza uma conexão preguiçosa. Portanto, se o tempo limite de conexão for maior do que o tempo limite do comando, você poderá ter um período de falha persistente após uma atualização da topologia se o Lettuce tentar se conectar a um nó não íntegro e o tempo limite do comando sempre for excedido.

Utilize um tempo limite de comando dinâmico para comandos diferentes. Recomendamos definir o tempo limite do comando com base na duração esperada do comando. Por exemplo, use um tempo limite maior para comandos que iteram em várias chaves, como scriptsFLUSHDB,FLUSHALL, KEYSSMEMBERS, ou Lua. Use tempos limite mais curtos para comandos de tecla únicaSET, comoGET, e. HSET

private static final Duration META_COMMAND_TIMEOUT = Duration.ofMillis(1000);
private static final Duration DEFAULT_COMMAND_TIMEOUT = Duration.ofMillis(250);
// Socket connect timeout should be lower than command timeout for Lettuce
private static final Duration CONNECT_TIMEOUT = Duration.ofMillis(100);
    
SocketOptions socketOptions = SocketOptions.builder()
    .connectTimeout(CONNECT_TIMEOUT)
    .build();
 

class DynamicClusterTimeout extends TimeoutSource {
     private static final Set<ProtocolKeyword> META_COMMAND_TYPES = ImmutableSet.<ProtocolKeyword>builder()
          .add(CommandType.FLUSHDB)
          .add(CommandType.FLUSHALL)
          .add(CommandType.CLUSTER)
          .add(CommandType.INFO)
          .add(CommandType.KEYS)
          .build();

    private final Duration defaultCommandTimeout;
    private final Duration metaCommandTimeout;

    DynamicClusterTimeout(Duration defaultTimeout, Duration metaTimeout)
    {
        defaultCommandTimeout = defaultTimeout;
        metaCommandTimeout = metaTimeout;
    }

    @Override
    public long getTimeout(RedisCommand<?, ?, ?> command) {
        if (META_COMMAND_TYPES.contains(command.getType())) {
            return metaCommandTimeout.toMillis();
        }
        return defaultCommandTimeout.toMillis();
    }
}

// Use a dynamic timeout for commands, to avoid timeouts during
// cluster management and slow operations.
TimeoutOptions timeoutOptions = TimeoutOptions.builder()
.timeoutSource(
    new DynamicClusterTimeout(DEFAULT_COMMAND_TIMEOUT, META_COMMAND_TIMEOUT))
.build();