Configuration du client Lettuce (Valkey et RedisOSS)

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.

DNSCache Java TTL

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

Le choix de TTL la valeur est un compromis entre latence et réactivité au changement. Avec une valeur plus courteTTLs, DNS les résolveurs constatent les mises à jour DNS plus rapidement dans le 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, s'il TTL est trop faible, cela augmente le volume des requêtes, ce qui peut augmenter la latence de votre application. Bien qu'il n'y ait pas de TTL valeur correcte, il convient de prendre en compte le temps que vous pouvez vous permettre d'attendre qu'une modification prenne effet lorsque vous définissez votre TTL valeur.

Comme ElastiCache les nœuds utilisent des entrées de DNS nom susceptibles de changer, nous vous recommandons de configurer votre nœud JVM avec un minimum TTL de 5 à 10 secondes. Cela garantit que lorsque l'adresse IP d'un nœud change, votre application sera en mesure de recevoir et d'utiliser la nouvelle adresse IP de la ressource en demandant l'DNSentrée.

Sur certaines configurations Java, la JVM valeur par défaut TTL est définie de telle sorte que les DNS entrées ne seront jamais actualisées avant JVM le redémarrage.

Pour plus de détails sur JVM TTL la configuration de votre JVMTTL.

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 DNS recherche URI renvoie une liste de tous les nœuds disponibles dans le cluster et est résolue de manière aléatoire pour l'un d'entre eux lors de l'initialisation du cluster. Pour plus de détails sur le fonctionnement de l'actualisation topologique, voir dynamicRefreshResourcesplus loin dans cette rubrique.

SocketOption

Activer 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.

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

nodeFilterParamétré pour exclure les nœuds défaillants de la topologie. Lettuce enregistre tous les nœuds présents dans la sortie des « nœuds de cluster » (y compris les nœuds avec le FAIL statutPFAIL/) dans les « partitions » du client (également appelées partitions). 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 le basculement terminé et le cluster lancé le processus de restauration, alors qu' clusterTopology il est actualisé, le mappage des nœuds du bus du cluster indique un court laps de temps pendant lequel le nœud en panne est répertorié en tant que FAIL nœud, avant qu'il ne soit complètement 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 pour contrôler l'actualisation de la topologie du cluster du client activé en mode cluster

Activer enablePeriodicRefresh. Cela permet des mises à jour périodiques de la topologie du cluster afin que le client mette à jour la topologie du cluster à intervalles de 60 secondes 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.

Activer enableAllAdaptiveRefreshTriggers. Cela permet une actualisation topologique adaptative 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 RedisOSS. 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).

Activer 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.

Activer 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 DnsResolveravec DirContextDnsResolver. Le DNS résolveur est basé sur com.sun.jndi.dns de Java. DnsContextFactory.

Configurez reconnectDelayavec un recul exponentiel et une instabilité totale. 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 d'attente plus long pour les commandes qui itèrent sur plusieurs touches, telles que les scriptsFLUSHDB,FLUSHALL, KEYSSMEMBERS, ou Lua. Utilisez des délais d'attente plus courts pour les raccourcis clavier, tels que SETGET, etHSET.

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