

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# ElastiCache meilleures pratiques et stratégies de mise en cache
<a name="BestPractices"></a>

Vous trouverez ci-dessous les meilleures pratiques recommandées pour Amazon ElastiCache. La mise en œuvre de ces bonnes pratiques améliore les performances et la fiabilité de votre cache. 

**Topics**
+ [Bonnes pratiques générales](WorkingWithRedis.md)
+ [Bonnes pratiques d'utilisation des répliques de lecture](ReadReplicas.md)
+ [Commandes Valkey, Memcached et Redis OSS prises en charge et restreintes](SupportedCommands.md)
+ [Configuration et limites de Valkey et Redis OSS](RedisConfiguration.md)
+ [IPv6 exemples de clients pour Valkey, Memcached et Redis OSS](network-type-best-practices.md)
+ [Bonnes pratiques pour les clients (Valkey et Redis OSS)](BestPractices.Clients.redis.md)
+ [Bonnes pratiques pour les clients (Memcached)](BestPractices.Clients.memcached.md)
+ [Clusters à double pile ElastiCache compatibles TLS](#network-type-configuring-tls-enabled-dual-stack)
+ [Gestion de la mémoire réservée pour Valkey et Redis OSS](redis-memory-management.md)
+ [Meilleures pratiques lors de l'utilisation de clusters basés sur des nœuds Valkey et Redis OSS](BestPractices.SelfDesigned.md)
+ [Stratégies de mise en cache pour Memcached](Strategies.md)

## Clusters à double pile ElastiCache compatibles TLS
<a name="network-type-configuring-tls-enabled-dual-stack"></a>

Lorsque TLS est activé pour les ElastiCache clusters, les fonctions de découverte de clusters (`cluster slots`,`cluster shards`, et `cluster nodes` pour Redis) ou `config get cluster` pour Memcached renvoient des noms d'hôte au lieu de. IPs Les noms d'hôtes sont ensuite utilisés au lieu de se IPs connecter au ElastiCache cluster et d'effectuer une poignée de main TLS. Cela signifie que les clients ne seront pas affectés par le paramètre de découverte d’adresses IP. Pour les clusters prenant en charge TLS, le paramètre de découverte d'adresses IP n'a aucun effet sur le protocole IP préféré. Au lieu de cela, le protocole IP utilisé sera déterminé par le protocole IP que le client préfère lors de la résolution des noms d'hôtes DNS.

**Clients Java**

Lorsque vous vous connectez à partir d'un environnement Java qui prend en charge IPv4 les deux IPv6, Java IPv4 privilégiera par défaut IPv6 la rétrocompatibilité. Toutefois, les arguments JVM permettent de configurer la préférence de protocole IP. Pour préférer IPv4, la JVM accepte `-Djava.net.preferIPv4Stack=true` et pour préférer, IPv6 définir`-Djava.net.preferIPv6Stack=true`. Le réglage `-Djava.net.preferIPv4Stack=true` signifie que la JVM n'établira plus aucune IPv6 connexion. **Pour Valkey ou Redis OSS, cela inclut ceux destinés à d'autres applications non-Valkey et non-Redis OSS.**

**Préférences au niveau de l'hôte**

En général, si le client ou l’environnement d’exécution du client ne fournit pas d’options de configuration permettant de définir une préférence de protocole IP, lors de la résolution DNS, le protocole IP dépendra de la configuration de l’hôte. Par défaut, la plupart des hôtes IPv6 préfèrent, IPv4 mais cette préférence peut être configurée au niveau de l'hôte. Cela affectera toutes les demandes DNS de cet hôte, et pas seulement celles adressées aux ElastiCache clusters.

**Hôtes Linux**

Pour Linux, une préférence de protocole IP peut être configurée en modifiant le fichier `gai.conf`. Le fichier `gai.conf` se trouve sous `/etc/gai.conf`. Si `gai.conf` n'est pas spécifié, un exemple doit être disponible sous `/usr/share/doc/glibc-common-x.xx/gai.conf`. Vous pouvez le copier sur `/etc/gai.conf` et la configuration par défaut doit être sans commentaire. Pour mettre à jour la configuration à privilégier IPv4 lors de la connexion à un ElastiCache cluster, mettez à jour la priorité de la plage d'adresses CIDR englobant le cluster IPs afin qu'elle soit supérieure à la priorité des connexions par défaut. IPv6 Par défaut, IPv6 les connexions ont une priorité de 40. Par exemple, en supposant que le cluster se trouve dans un sous-réseau dont le CIDR est 172.31.0. 0:0 /16, la configuration ci-dessous incitera les clients à préférer les connexions à ce cluster. IPv4 

```
label ::1/128       0
label ::/0          1
label 2002::/16     2
label ::/96         3
label ::ffff:0:0/96 4
label fec0::/10     5
label fc00::/7      6
label 2001:0::/32   7
label ::ffff:172.31.0.0/112 8
#
#    This default differs from the tables given in RFC 3484 by handling
#    (now obsolete) site-local IPv6 addresses and Unique Local Addresses.
#    The reason for this difference is that these addresses are never
#    NATed while IPv4 site-local addresses most probably are.  Given
#    the precedence of IPv6 over IPv4 (see below) on machines having only
#    site-local IPv4 and IPv6 addresses a lookup for a global address would
#    see the IPv6 be preferred.  The result is a long delay because the
#    site-local IPv6 addresses cannot be used while the IPv4 address is
#    (at least for the foreseeable future) NATed.  We also treat Teredo
#    tunnels special.
#
# precedence  <mask>   <value>
#    Add another rule to the RFC 3484 precedence table.  See section 2.1
#    and 10.3 in RFC 3484.  The default is:
#
precedence  ::1/128       50
precedence  ::/0          40
precedence  2002::/16     30
precedence ::/96          20
precedence ::ffff:0:0/96  10
precedence ::ffff:172.31.0.0/112 100
```

Plus de détails `gai.conf` sont disponibles sur la [page de manuel Linux](https://man7.org/linux/man-pages/man5/gai.conf.5.html) 

**Hôtes Windows**

Le processus pour les hôtes Windows est similaire. Pour les hôtes Windows, vous pouvez exécuter `netsh interface ipv6 set prefix CIDR_CONTAINING_CLUSTER_IPS PRECEDENCE LABEL`. Cela a le même effet que la modification du fichier `gai.conf` sur les hôtes Linux.

Cela mettra à jour les politiques de préférence afin de préférer IPv4 les connexions aux IPv6 connexions pour la plage d'adresses CIDR spécifiée. Par exemple, en supposant que le cluster se trouve dans un sous-réseau avec le CIDR 172.31.0. 0:0 /16 en cours d'exécution, le tableau de priorité suivant `netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15` s'affichera, ce qui incitera les clients à préférer se connecter au cluster. IPv4 

```
C:\Users\Administrator>netsh interface ipv6 show prefixpolicies
Querying active state...

Precedence Label Prefix
---------- ----- --------------------------------
100 15 ::ffff:172.31.0.0:0/112
20 4 ::ffff:0:0/96
50 0 ::1/128
40 1 ::/0
30 2 2002::/16
5 5 2001::/32
3 13 fc00::/7
1 11 fec0::/10
1 12 3ffe::/16
1 3 ::/96
```