As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Práticas recomendadas e estratégias de armazenamento em cache do ElastiCache Abaixo, é possível encontrar práticas recomendadas para o Amazon ElastiCache. Seguir essas práticas melhora o desempenho e aumenta a confiabilidade do cache. **Topics** + [Práticas recomendadas gerais](WorkingWithRedis.md) + [Práticas recomendadas para usar réplicas de leitura](ReadReplicas.md) + [Comandos Valkey, Memcached e Redis OSS compatíveis e restritos](SupportedCommands.md) + [Configuração e limites do Valkey e Redis OSS](RedisConfiguration.md) + [Exemplos de clientes IPv6 para Valkey, Memcached e Redis OSS](network-type-best-practices.md) + [Práticas recomendadas para clientes (Valkey e Redis OSS)](BestPractices.Clients.redis.md) + [Práticas recomendadas para clientes (Memcached)](BestPractices.Clients.memcached.md) + [Clusters do ElastiCache de pilha dupla habilitados para TLS](#network-type-configuring-tls-enabled-dual-stack) + [Gerenciamento de memória reservada para Valkey e Redis OSS](redis-memory-management.md) + [Práticas recomendadas ao trabalhar com clusters baseados em nós do Valkey e Redis OSS](BestPractices.SelfDesigned.md) + [Estratégias de armazenamento em cache para Memcached](Strategies.md) ## Clusters do ElastiCache de pilha dupla habilitados para TLS Quando o TLS está habilitado para clusters do ElastiCache, as funções de descoberta de cluster (`cluster slots`, `cluster shards`, e `cluster nodes` para o Redis) ou `config get cluster` para o Memcached retornam nomes de host em vez de IPs. Os nomes de host são então usados em vez de IPs para se conectar ao cluster do ElastiCache e realizar um handshake de TLS. Isso significa que os clientes não serão afetados pelo parâmetro de descoberta de IP. Para clusters habilitados para TLS, o parâmetro de descoberta de IP não tem efeito no protocolo IP preferencial. Em vez disso, o protocolo IP usado será determinado pelo protocolo IP que o cliente prefere ao resolver nomes de host DNS. **Clientes Java** Ao se conectar de um ambiente Java que oferece suporte a IPv4 e IPv6, o Java, por padrão, prefere IPv4 em vez de IPv6 para compatibilidade com versões anteriores. No entanto, a preferência do protocolo IP é configurável por meio dos argumentos da JVM. Para preferir IPv4, a JVM aceita `-Djava.net.preferIPv4Stack=true` e prefere o conjunto IPv6 `-Djava.net.preferIPv6Stack=true`. A configuração `-Djava.net.preferIPv4Stack=true` significa que a JVM não fará mais nenhuma conexão IPv6. **Para Valkey ou Redis OSS, isso inclui aquelas para outras aplicações não Valkey e não Redis OSS.** **Preferências de nível de host** Em geral, se o runtime do cliente ou o cliente não fornecer opções de configuração para definir uma preferência de protocolo IP, ao executar a resolução de DNS, o protocolo IP dependerá da configuração do host. Por padrão, a maioria dos hosts prefere IPv6 em vez de IPv4, mas essa preferência pode ser configurada no nível do host. Isso afetará todas as solicitações de DNS desse host, não apenas aquelas para clusters do ElastiCache. **Hosts Linux** Para Linux, uma preferência de protocolo IP pode ser configurada modificando o arquivo do `gai.conf`. O arquivo do `gai.conf` pode ser encontrado em `/etc/gai.conf`. Se não houver `gai.conf` especificado, um exemplo deve estar disponível em `/usr/share/doc/glibc-common-x.xx/gai.conf`, o qual pode ser copiado em `/etc/gai.conf`, e a configuração padrão não deverá ser comentada. Para atualizar a configuração para preferir IPv4 ao se conectar a um cluster do ElastiCache, atualize a precedência do intervalo CIDR que abrange os IPs do cluster para estar acima da precedência das conexões IPv6 padrão. Por padrão, as conexões IPv6 têm uma precedência de 40. Por exemplo, supondo que o cluster esteja localizado em uma sub-rede com o CIDR 172.31.0.0:0/16, a configuração abaixo faria com que os clientes preferissem conexões IPv4 a esse cluster. ``` 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 ``` Mais detalhes sobre `gai.conf` estão disponíveis na [página principal do Linux](https://man7.org/linux/man-pages/man5/gai.conf.5.html) **Hosts do Windows** O processo para hosts do Windows é semelhante. Para hosts do Windows, você pode executar `netsh interface ipv6 set prefix CIDR_CONTAINING_CLUSTER_IPS PRECEDENCE LABEL`. Isso tem o mesmo resultado que modificar o arquivo `gai.conf` em hosts Linux. Isso atualizará as políticas de preferência para preferir conexões IPv4 em vez de conexões IPv6 para o intervalo CIDR especificado. Por exemplo, supondo que o cluster esteja em uma sub-rede com o CIDR 172.31.0.0:0/16, a execução de `netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15` resultaria na seguinte tabela de precedência, o que faria com que os clientes preferissem IPv4 ao se conectarem ao 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 ```