Configuration du client Lettuce (Valkey et Redis OSS)

Cette section décrit les options de configuration recommandées pour Java et Lettuce, ainsi que leur application aux ElastiCache clusters.

Les recommandations de cette section ont été testées avec la version 6.2.2 de Lettuce.

TTL du cache DNS de Java

La machine virtuelle Java (JVM) met en cache les recherches de nom DNS. Lorsque la JVM convertit un nom d'hôte en adresse IP, elle met l'adresse IP en cache pendant une période spécifiée, connue sous le nom de time-to-live(TTL).

Le choix d'une valeur TTL est un compromis entre la latence et la réactivité au changement. Avec une valeur plus courte TTLs, les résolveurs DNS détectent plus rapidement les mises à jour du DNS du cluster. Cela peut permettre à votre application de réagir plus rapidement aux remplacements ou à d'autres flux de travail auxquels votre cluster est soumis. Toutefois, si la TTL est trop faible, le volume de requêtes augmente, ce qui peut accentuer la latence de votre application. Bien qu'il n'y ait pas de valeur TTL correcte, lorsque vous la configurez, vous pouvez déterminer le délai d'attente maximal avant qu'une modification prenne effet.

Comme ElastiCache les nœuds utilisent des entrées de nom DNS susceptibles de changer, nous vous recommandons de configurer votre JVM avec un TTL faible de 5 à 10 secondes. Ainsi, lorsque l’adresse IP d’un nœud change, votre application peut recevoir et utiliser la nouvelle adresse IP de la ressource en interrogeant l’entrée DNS.

Dans certaines configurations Java, la durée de vie par défaut de la JVM est définie de façon à ce que la JVM n'actualise jamais les entrées DNS tant qu'elle n'est pas redémarrée.

Pour plus de détails sur la façon de définir la durée de vie de votre JVM, consultez Comment définir la durée de vie de la JVM.

Version de Lettuce

Nous recommandons Lettuce version 6.2.2 ou ultérieure.

Points de terminaison

Lorsque vous utilisez des clusters activés en mode cluster, définissez redisUri sur le point de terminaison de configuration du cluster. La recherche DNS pour cet URI renvoie une liste de tous les nœuds disponibles dans le cluster et est résolue de manière aléatoire vers l'un d'entre eux lors de l'initialisation du cluster. Pour plus de détails sur le fonctionnement de l'actualisation topologique, reportez-vous à la section dynamicRefreshResourcessuivante de cette rubrique.

SocketOption

Activez KeepAlive. L'activation de cette option réduit la nécessité de gérer les échecs de connexion lors de l'exécution des commandes.

Assurez-vous de définir le Délai de connexion en fonction des exigences de votre application et de votre charge de travail. Pour plus d'informations, consultez la section Délais plus loin dans cette rubrique.

ClusterClientOption: options client activées en mode cluster

Activez AutoReconnecten cas de perte de connexion.

Configurez CommandTimeout. Pour plus de détails, consultez la section Délais plus loin dans cette rubrique.

Définissez nodeFilter pour exclure les nœuds défaillants de la topologie. Lettuce enregistre tous les nœuds présents dans la sortie « nœuds de cluster » (y compris les nœuds ayant le statut PFAIL/FAIL) dans les « partitions » du client. Au cours du processus de création de la topologie du cluster, celle-ci tente de se connecter à tous les nœuds de partition. Ce comportement de Lettuce qui consiste à ajouter des nœuds défaillants peut provoquer des erreurs de connexion (ou des avertissements) lorsque des nœuds sont remplacés pour une raison quelconque.

Par exemple, une fois qu'un basculement est terminé et que le cluster démarre le processus de restauration, alors que la topologie du cluster est actualisée, la carte des nœuds de bus du cluster indique brièvement que le nœud inférieur est listé en tant que nœud FAIL, avant qu'il ne soit entièrement supprimé de la topologie. Pendant cette période, le client Lettuce considère qu'il s'agit d'un nœud sain et s'y connecte en permanence. Cela provoque un échec une fois que les nouvelles tentatives sont épuisées.

Par exemple :

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: Options permettant de contrôler l'actualisation de la topologie du cluster du client activé en mode cluster

Activez enablePeriodicRefresh. Cela active les mises à jour périodiques de la topologie du cluster, afin que le client puisse mettre à jour la topologie du cluster dans les intervalles de refreshPeriod (par défaut : 60 secondes). Lorsqu'il est désactivé, le client met à jour la topologie du cluster uniquement lorsque des erreurs se produisent s'il tente d'exécuter des commandes sur le cluster.

Lorsque cette option est activée, vous pouvez réduire la latence associée à l'actualisation de la topologie du cluster en ajoutant cette tâche à une tâche en arrière-plan. Bien que l'actualisation de la topologie soit effectuée en arrière-plan, elle peut être quelque peu lente pour les clusters comportant de nombreux nœuds. Cela est dû au fait que tous les nœuds sont interrogés afin de connaître leurs vues et d'obtenir la vue de cluster la plus récente. Si vous gérez un cluster de grande taille, vous souhaiterez peut-être augmenter la période.

Activez enableAllAdaptiveRefreshTriggers. Cela active une actualisation adaptative de la topologie qui utilise tous les déclencheurs : MOVED_REDIRECT, ASK_REDIRECT, PERSISTENT_RECONNECTS, UNCOVERED_SLOT, UNKNOWN_NODE. Les déclencheurs d'actualisation adaptatifs initient les mises à jour de la vue topologique en fonction des événements qui se produisent lors des opérations du cluster Valkey ou Redis OSS. L'activation de cette option entraîne une actualisation immédiate de la topologie lorsque l'un des déclencheurs précédents s'active. La fréquence des actualisations déclenchées adaptatives est limitée grâce à un délai d'attente, car les événements peuvent se produire à grande échelle (délai d'attente par défaut entre les mises à jour : 30).

Activez closeStaleConnections. Cela permet de fermer les connexions obsolètes lors de l'actualisation de la topologie du cluster. Il n'entre en vigueur que si ClusterTopologyRefreshOptions. isPeriodicRefreshEnabled () est vrai. Lorsqu'elle est activée, le client peut fermer les connexions obsolètes et en créer d'autres en arrière-plan. L'activation de cette option réduit la nécessité de gérer les échecs de connexion lors de l'exécution des commandes.

Activez dynamicRefreshResources. Nous recommandons de l'activer dynamicRefreshResources pour les petits clusters et de la désactiver pour les grands clusters. dynamicRefreshResourcespermet de découvrir les nœuds de cluster à partir du nœud d'origine fourni (par exemple, point de terminaison de configuration du cluster). Il utilise tous les nœuds détectés en tant que sources pour actualiser la topologie du cluster.

L'actualisation dynamique interroge tous les nœuds détectés pour la topologie du cluster et tente de choisir la vue de cluster la plus précise. S'il est défini sur false, seuls les nœuds de départ initiaux sont utilisés comme sources pour la détection de la topologie, et le nombre de clients est obtenu uniquement pour les nœuds de départ initiaux. Lorsqu'il est désactivé, si le point de terminaison de la configuration du cluster est résolu en un nœud défaillant, la tentative d'actualisation de la vue du cluster échoue et entraîne des exceptions. Ce scénario peut se produire, car il faut un certain temps pour que l’entrée d’un nœud défaillant soit supprimée du point de terminaison de configuration du cluster. Par conséquent, le point de terminaison de la configuration peut toujours être résolu de manière aléatoire et brève en un nœud défaillant.

Cependant, lorsqu'il est activé, nous utilisons tous les nœuds de cluster reçus depuis la vue du cluster pour demander leur vue actuelle. Étant donné que nous éliminons les nœuds défaillants de cette vue, l'actualisation de la topologie sera réussie. Toutefois, lorsque dynamicRefreshSources c'est vrai, Lettuce interroge tous les nœuds pour obtenir la vue du cluster, puis compare les résultats. L'opération peut donc être coûteuse pour les clusters comportant un grand nombre de nœuds. Nous vous suggérons de désactiver cette fonctionnalité pour les clusters comportant de nombreux nœuds.

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

ClientResources

Configurez DnsResolver avec DirContextDnsResolver. Le résolveur DNS est basé sur com.sun.jndi.dns de Java. DnsContextFactory.

Configurez reconnectDelay avec un backoff exponentiel et une instabilité complète. Lettuce possède des mécanismes de relance intégrés basés sur des stratégies de backoff exponentiel. Pour plus de détails, consultez Exponential Backoff and Jitter sur le AWS blog d'architecture. Pour plus d'informations sur l'importance d'adopter une nouvelle stratégie d'interruption, consultez les sections sur la logique d'interruption du billet de blog consacré aux meilleures pratiques sur le AWS blog de base de données.

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(); 

Délais

Utilisez une valeur de délai de connexion inférieure à celle de votre commande. Lettuce utilise l'établissement d'une connexion différée. Ainsi, si le délai d'expiration de la connexion est supérieur à celui de la commande, vous pouvez connaître des échecs persistants après une actualisation de la topologie, si Lettuce essaie de se connecter à un nœud défectueux et si le délai de la commande est toujours dépassé.

Utilisez un délai de commande dynamique pour différentes commandes. Nous vous recommandons de définir le délai de commande en fonction de la durée attendue de la commande. Par exemple, utilisez un délai plus long pour les commandes qui itèrent sur plusieurs clés, comme les scripts FLUSHDB, FLUSHALL, KEYS, SMEMBERS ou Lua. Utilisez des délais plus courts pour les commandes à clé unique, telles que SET, GET et 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();