Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # ElastiCache migliori pratiche e strategie di caching Di seguito puoi trovare le best practice consigliate per Amazon ElastiCache. Queste best practice consentono di migliorare prestazioni e affidabilità della cache. **Topics** + [Le migliori pratiche generali](WorkingWithRedis.md) + [Best practice per l’utilizzo delle repliche in lettura](ReadReplicas.md) + [Comandi Valkey, Memcached e Redis OSS supportati e limitati](SupportedCommands.md) + [Configurazione e limiti di Valkey e Redis OSS](RedisConfiguration.md) + [Esempi di client IPv6 per Valkey, Memcached e Redis OSS](network-type-best-practices.md) + [Le migliori pratiche per i clienti (Valkey e Redis OSS)](BestPractices.Clients.redis.md) + [Le migliori pratiche per i clienti (Memcached)](BestPractices.Clients.memcached.md) + [Cluster dual ElastiCache stack abilitati per TLS](#network-type-configuring-tls-enabled-dual-stack) + [Gestione della memoria riservata per Valkey e Redis OSS](redis-memory-management.md) + [Procedure consigliate per l'utilizzo di cluster basati su nodi Valkey e Redis OSS](BestPractices.SelfDesigned.md) + [Memorizzazione nella cache dei risultati delle query del database](caching-database-query-results.md) + [Strategie di caching per Memcached](Strategies.md) ## Cluster dual ElastiCache stack abilitati per TLS Quando TLS è abilitato per ElastiCache i cluster, le funzioni di rilevamento del cluster (`cluster slots``cluster shards`, e `cluster nodes` per Redis) o `config get cluster` per Memcached restituiscono nomi di host anziché IP. I nomi host vengono quindi utilizzati al posto degli IP per connettersi al cluster ed eseguire un handshake TLS. ElastiCache Ciò significa che i client non sono interessati dal parametro Individuazione IP. Per i cluster abilitati per TLS, il parametro Individuazione IP non ha alcun effetto sul protocollo IP preferito. Invece, il protocollo IP utilizzato verrà determinato in base a quello preferito dal client durante la risoluzione dei nomi host DNS. **Client Java** Quando si esegue la connessione da un ambiente Java che supporta sia IPv4 che IPv6, per impostazione predefinita Java preferirà IPv4 rispetto a IPv6 per la compatibilità con le versioni precedenti. Tuttavia, la preferenza del protocollo IP è configurabile tramite gli argomenti JVM. Per preferire IPv4, la JVM accetta `-Djava.net.preferIPv4Stack=true` e per preferire IPv6 imposta `-Djava.net.preferIPv6Stack=true`. Se si imposta `-Djava.net.preferIPv4Stack=true`, significa che la JVM non effettuerà più connessioni IPv6. **Per Valkey o Redis OSS, questo include quelli di altre applicazioni OSS non Valkey e non Redis.** **Preferenze a livello di host** In generale, se il client o il runtime client non forniscono opzioni di configurazione per l'impostazione di una preferenza del protocollo IP, quando si esegue la risoluzione DNS, il protocollo IP dipenderà dalla configurazione dell'host. Per impostazione predefinita, la maggior parte degli host preferisce IPv6 rispetto a IPv4, ma questa preferenza può essere configurata a livello di host. Ciò influirà su tutte le richieste DNS provenienti da quell'host, non solo su quelle ai cluster. ElastiCache **Host Linux** Per Linux, una preferenza protocollo IP può essere configurata modificando il file `gai.conf`. Il file `gai.conf` è disponibile in `/etc/gai.conf`. Se non è specificato alcun `gai.conf`, uno di esempio deve essere disponibile in `/usr/share/doc/glibc-common-x.xx/gai.conf` che può essere copiato in `/etc/gai.conf`; è quindi necessario rimuovere i commenti dalla configurazione predefinita. Per aggiornare la configurazione in modo da preferire l'IPv4 durante la connessione a un ElastiCache cluster, aggiorna la precedenza per l'intervallo CIDR che comprende gli IP del cluster in modo che sia superiore alla precedenza per le connessioni IPv6 predefinite. Per impostazione predefinita, alle connessioni IPv6 viene assegnata una priorità di 40. Ad esempio, supponendo che il cluster si trovi in una sottorete con CIDR 172.31.0.0:, la configurazione seguente farebbe sì che i client preferiscano le connessioni IPv4 a quel cluster. 0/16 ``` 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 # 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 ``` [Maggiori dettagli su sono disponibili nella pagina man di Linux `gai.conf`](https://man7.org/linux/man-pages/man5/gai.conf.5.html) **Host Windows** Il processo per gli host Windows è simile. Per gli host Windows è possibile eseguire `netsh interface ipv6 set prefix CIDR_CONTAINING_CLUSTER_IPS PRECEDENCE LABEL`. L'effetto è identico alla modifica del file `gai.conf` su host Linux. Ciò aggiornerà le policy di preferenza in modo da preferire le connessioni IPv4 rispetto alle connessioni IPv6 per l'intervallo CIDR specificato. Ad esempio, supponendo che il cluster si trovi in una sottorete con 172.31.0.0: l'esecuzione 0/16 CIDR comporterebbe la seguente tabella di precedenza che `netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15` farebbe sì che i client preferiscano IPv4 quando si connettono al cluster. ``` 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 ```