Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
ElastiCache bewährte Methoden und Caching-Strategien
Im Folgenden finden Sie empfohlene Best Practices für Amazon ElastiCache. Durch die Einhaltung dieser Methoden lassen sich die Performance und Zuverlässigkeit des Caches verbessern.
Themen
- Allgemeine Best Practices
- Unterstützte und eingeschränkte Valkey-, Redis OSS - und Memcached-Befehle
- OSSKonfiguration und Limits von Valkey und Redis
- IPv6Kundenbeispiele für Valkey, Redis OSS und Memcached
- Best Practices für Kunden (Valkey und OSS Redis)
- Bewährte Methoden für Kunden (Memcached)
- TLSaktivierte ElastiCache Dual-Stack-Cluster
- Verwaltung des reservierten Speichers für Valkey und Redis OSS
- Bewährte Methoden bei der Arbeit mit selbst entworfenen Clustern von Valkey und Redis OSS
- Caching-Strategien für Memcached
TLSaktivierte ElastiCache Dual-Stack-Cluster
Wenn für ElastiCache Cluster aktiviert TLS ist, geben die Cluster-Erkennungsfunktionen (cluster slots
cluster shards
, und cluster nodes
für Redis) oder config get cluster
für Memcached statt Hostnamen zurück. IPs Die Hostnamen werden dann verwendet, anstatt eine Verbindung IPs zum ElastiCache Cluster herzustellen und einen Handshake durchzuführen. TLS Das bedeutet, dass Clients nicht vom IP-Discovery-Parameter betroffen sind. Bei TLS aktivierten Clustern hat der IP Discovery-Parameter keine Auswirkung auf das bevorzugte IP-Protokoll. Stattdessen wird das verwendete IP-Protokoll davon bestimmt, welches IP-Protokoll der Client bei der Auflösung von DNS Hostnamen bevorzugt.
Java-Clients
Wenn Sie eine Verbindung von einer Java-Umgebung aus herstellen, die IPv4 sowohl als auch unterstütztIPv6, wird Java aus IPv6 Gründen der Abwärtskompatibilität standardmäßig IPv4 den Vorzug geben. Die IP-Protokollpräferenz kann jedoch über die JVM Argumente konfiguriert werden. Zu bevorzugenIPv4, zu JVM akzeptieren -Djava.net.preferIPv4Stack=true
und zu IPv6 bevorzugen-Djava.net.preferIPv6Stack=true
. Die Einstellung -Djava.net.preferIPv4Stack=true
bedeutet, JVM dass keine IPv6 Verbindungen mehr hergestellt werden. Bei Valkey oder Redis umfasst dies auch die OSS Verbindungen zu anderen Nicht-Valkey- und Nicht-Redis-Anwendungen. OSS
Einstellungen auf Host-Ebene
Wenn der Client oder die Client-Laufzeit keine Konfigurationsoptionen für die Einstellung einer IP-Protokollpräferenz bereitstellt, hängt das IP-Protokoll bei der DNS Auflösung generell von der Konfiguration des Hosts ab. Standardmäßig bevorzugen die meisten Hosts IPv6 gegenüber, IPv4 aber diese Präferenz kann auf Host-Ebene konfiguriert werden. Dies wirkt sich auf alle DNS Anfragen von diesem Host aus, nicht nur auf Anfragen an ElastiCache Cluster.
Linux-Hosts
Für Linux kann eine IP-Protokollpräferenz konfiguriert werden, indem die gai.conf
-Datei geändert wird. Sie finden die gai.conf
-Datei unter /etc/gai.conf
. Wenn keine gai.conf
angegeben ist, sollte ein Beispiel davon /usr/share/doc/glibc-common-x.xx/gai.conf
verfügbar sein, das nach /etc/gai.conf
kopiert werden kann. Die Standardkonfiguration sollte dann unkommentiert sein. Um die Konfiguration zu aktualisieren, die IPv4 bei der Verbindung zu einem ElastiCache Cluster bevorzugt wird, aktualisieren Sie die Priorität für den CIDR Bereich, der den Cluster umfasst, soIPs, dass sie über der Priorität für Standardverbindungen liegt. IPv6 Standardmäßig haben IPv6 Verbindungen eine Priorität von 40. Angenommen, der Cluster befindet sich in einem Subnetz mit CIDR 172.31.0. 0:0 /16, würde die folgende Konfiguration dazu führen, dass Clients Verbindungen zu diesem Cluster bevorzugen. 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
Weitere Informationen zu gai.conf
finden Sie auf der Linux-Hauptseite
Windows-Hosts
Der Prozess für Windows-Hosts ist ähnlich. Für Windows-Hosts können Sie netsh interface ipv6 set prefix CIDR_CONTAINING_CLUSTER_IPS PRECEDENCE LABEL
ausführen. Dies hat den gleichen Effekt wie das Ändern der gai.conf
-Datei für Linux-Hosts.
Dadurch werden die Präferenzrichtlinien aktualisiert, sodass IPv4 Verbindungen Verbindungen für den angegebenen Bereich vorgezogen IPv6 werden. CIDR Wenn beispielsweise angenommen wird, dass sich der Cluster in einem Subnetz befindet, in dem 172.31.0. 0:0 /16 CIDR ausgeführt wird, netsh interface ipv6 set prefix ::ffff:172.31.0.0:0/112 100 15
würde dies zu der folgenden Rangfolgetabelle führen, was dazu führen würde, dass Clients eine Verbindung zum Cluster bevorzugen. 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