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à.
I seguenti argomenti forniscono consigli per la risoluzione di errori e problemi che potrebbero verificarsi durante l'utilizzo. ElastiCache Se trovi un problema che non è elencato qui, puoi utilizzare il pulsante di feedback in questa pagina per segnalarlo.
Per ulteriori consigli sulla risoluzione dei problemi e risposte alle domande di supporto più comuni, visita il AWS Knowledge Center
Argomenti
Problemi di connessione
Se non riesci a connetterti alla ElastiCache cache, prendi in considerazione una delle seguenti opzioni:
Utilizzo di TLS: se si verifica un blocco della connessione durante il tentativo di connessione all' ElastiCache endpoint, è possibile che non si stia utilizzando TLS nel client. Se utilizzi ElastiCache Serverless, la crittografia in transito è sempre abilitata. Assicurati che il tuo client utilizzi TLS per connettersi alla cache. Scopri di più sulla connessione a una cache abilitata per TLS.
VPC: le ElastiCache cache sono accessibili solo dall'interno di un VPC. Assicurati che l' EC2 istanza da cui accedi alla cache e alla ElastiCache cache siano create nello stesso VPC. In alternativa, devi abilitare il peering VPC tra il VPC in cui EC2 risiede l'istanza e il VPC in cui stai creando la cache.
Gruppi di sicurezza: ElastiCache utilizza i gruppi di sicurezza per controllare l'accesso alla cache. Considera i seguenti aspetti:
Assicurati che il gruppo di sicurezza utilizzato dalla ElastiCache cache consenta l'accesso in entrata dalla tua EC2 istanza. Vedi qui per scoprire come configurare correttamente le regole in entrata nel tuo gruppo di sicurezza.
Assicurati che il gruppo di sicurezza utilizzato dalla ElastiCache cache consenta l'accesso alle porte della cache (6379 e 6380 per le versioni serverless e 6379 per impostazione predefinita per quelle progettate autonomamente). ElastiCache utilizza queste porte per accettare i comandi Valkey o Redis OSS. Scopri di più su come configurare l'accesso alle porte qui.
Se la connessione continua a essere difficile, consulta Problemi di connessione persistenti gli altri passaggi.
Errori del client Valkey o Redis OSS
ElastiCache Serverless è accessibile solo tramite client che supportano il protocollo in modalità cluster Valkey o Redis OSS. È possibile accedere ai cluster progettati autonomamente dai client in entrambe le modalità, a seconda della configurazione del cluster.
Se riscontri errori nel tuo client, considera quanto segue:
Modalità cluster: se si verificano errori CROSSLOT o errori con il comando SELECT
, è possibile che si stia tentando di accedere a una cache Cluster Mode Enabled con un client Valkey o Redis OSS che non supporta il protocollo Cluster. ElastiCache Serverless supporta solo client che supportano il protocollo cluster Valkey o Redis OSS. Se desideri utilizzare Valkey o Redis OSS in «Cluster Mode Disabled» (CMD), devi progettare il tuo cluster. Errori CROSSLOT: se si verifica l'
ERR CROSSLOT Keys in request don't hash to the same sloterrore, è possibile che si stia tentando di accedere a chiavi che non appartengono allo stesso slot in una cache in modalità Cluster. Come promemoria, ElastiCache Serverless funziona sempre in modalità Cluster. Le operazioni a più chiavi, le transazioni o gli script Lua che coinvolgono più chiavi sono consentite solo se tutte le chiavi coinvolte si trovano nello stesso slot di hash.
Risoluzione dei problemi di latenza elevata in Serverless ElastiCache
Se il tuo carico di lavoro sembra presentare un'elevata latenza, puoi analizzare le SuccessfulWriteRequestLatency metriche CloudWatch SuccessfulReadRequestLatency e per verificare se la latenza è correlata a Serverless. ElastiCache Queste metriche misurano la latenza interna a ElastiCache Serverless: la latenza lato client e i tempi di viaggio di rete tra il client e l'endpoint Serverless non sono inclusi. ElastiCache
Risoluzione dei problemi di latenza lato client
Se notate una latenza elevata sul lato client ma nessun aumento corrispondente CloudWatch SuccessfulReadRequestLatency e SuccessfulWriteRequestLatency metriche che misurano la latenza lato server, considerate quanto segue:
Assicurati che il gruppo di sicurezza consenta l'accesso alle porte 6379 e 6380: ElastiCache Serverless utilizza la porta 6379 per l'endpoint primario e la porta 6380 per l'endpoint del lettore. Alcuni client stabiliscono la connettività a entrambe le porte per ogni nuova connessione, anche se l'applicazione non utilizza la funzionalità Read from Replica. Se il gruppo di sicurezza non consente l'accesso in entrata a entrambe le porte, la creazione della connessione può richiedere più tempo. Scopri di più su come configurare l'accesso alle porte qui.
Risoluzione dei problemi di latenza lato server
Alcune variabilità e i picchi occasionali non dovrebbero essere motivo di preoccupazione. Tuttavia, se la Average statistica mostra un forte aumento e persiste, dovresti controllare la Personal Health Dashboard AWS Health Dashboard e la tua Personal Health Dashboard per ulteriori informazioni. Se necessario, valuta la possibilità di aprire una richiesta di supporto con. Supporto
Prendi in considerazione le seguenti best practice e strategie per ridurre la latenza:
Abilita Read from Replica: se la tua applicazione lo consente, ti consigliamo di abilitare la funzionalità «Read from Replica» nel tuo client Valkey o Redis OSS per scalare le letture e ottenere una latenza inferiore. Se abilitata, ElastiCache Serverless tenta di indirizzare le richieste di lettura verso i nodi della cache di replica che si trovano nella stessa zona di disponibilità (AZ) del client, evitando così la latenza di rete Cross-AZ. Tieni presente che l'attivazione della funzionalità Read from Replica nel client significa che l'applicazione accetta l'eventuale coerenza dei dati. L'applicazione potrebbe ricevere dati più vecchi per qualche tempo se si tenta di leggere dopo aver scritto su una chiave.
Assicurati che l'applicazione sia distribuita nella AZs stessa cache: potresti osservare una maggiore latenza lato client se l'applicazione non è distribuita nella AZs stessa cache. Quando si crea una cache serverless, è possibile fornire le sottoreti da cui l'applicazione accederà alla cache e ElastiCache Serverless crea endpoint VPC in tali sottoreti. Assicurati che l'applicazione sia distribuita nella stessa. AZs In caso contrario, l'applicazione potrebbe subire un hop Cross-AZ quando accede alla cache, con conseguente maggiore latenza lato client.
Riutilizza le connessioni: le richieste ElastiCache serverless vengono effettuate tramite una connessione TCP abilitata per TLS utilizzando il protocollo RESP. L'avvio della connessione (inclusa l'autenticazione della connessione, se configurata) richiede tempo, quindi la latenza della prima richiesta è superiore a quella tipica. Le richieste su una connessione già inizializzata offrono ElastiCache una latenza costantemente bassa. Per questo motivo, dovresti prendere in considerazione l'utilizzo del pool di connessioni o il riutilizzo delle connessioni Valkey o Redis OSS esistenti.
Velocità di scalabilità: ElastiCache Serverless si ridimensiona automaticamente all'aumentare della frequenza delle richieste. Un aumento improvviso e significativo della frequenza di richieste, superiore alla velocità di scalabilità di ElastiCache Serverless, può comportare una latenza elevata per qualche tempo. ElastiCache In genere, Serverless può aumentare rapidamente la frequenza di richieste supportata, impiegando fino a 10-12 minuti per raddoppiare la frequenza delle richieste.
Ispeziona i comandi a esecuzione prolungata: alcuni comandi Valkey o Redis OSS, inclusi gli script Lua o i comandi su strutture di dati di grandi dimensioni, possono essere eseguiti a lungo. Per identificare questi comandi, pubblica metriche a livello di comando. ElastiCache Con ElastiCache Serverless puoi usare le metriche.
BasedECPUsRichieste limitate: quando le richieste vengono limitate in ElastiCache Serverless, è possibile che si verifichi un aumento della latenza lato client nell'applicazione. Quando le richieste vengono limitate in ElastiCache Serverless, dovresti notare un aumento della metrica Serverless. ThrottledRequests ElastiCache Consulta la sezione seguente per la risoluzione dei problemi relativi alle richieste limitate.
Distribuzione uniforme di chiavi e richieste: ElastiCache per Valkey e Redis OSS, una distribuzione non uniforme di chiavi o richieste per slot può comportare un hot slot che può comportare una latenza elevata. ElastiCache Serverless supporta fino a 30.000 al ECPUs secondo (90.000 al ECPUs secondo quando si utilizza Read from Replica) su un singolo slot, in un carico di lavoro che esegue semplici comandi SET/GET. Ti consigliamo di valutare la distribuzione delle chiavi e delle richieste tra gli slot e di garantire una distribuzione uniforme se la frequenza delle richieste supera questo limite.
Risoluzione dei problemi di limitazione in Serverless ElastiCache
Nelle architetture orientate ai servizi e nei sistemi distribuiti, la limitazione della velocità con cui le chiamate API vengono elaborate dai vari componenti del servizio si chiama limitazione (della larghezza di banda della rete). Ciò attenua i picchi, controlla le discrepanze nella velocità di trasmissione dei componenti e consente ripristini più prevedibili in caso di eventi operativi imprevisti. ElastiCache Serverless è progettato per questi tipi di architetture e la maggior parte dei client Valkey o Redis OSS dispone di nuovi tentativi integrati per le richieste limitate. Un certo grado di limitazione (della larghezza di banda della rete) non è necessariamente un problema per l'applicazione, ma una limitazione (della larghezza di banda della rete) persistente di una parte sensibile alla latenza del flusso di lavoro dei dati può influire negativamente sull'esperienza dell'utente e ridurre l'efficienza complessiva del sistema.
Quando le richieste vengono limitate in Serverless, dovresti notare un aumento della metrica ElastiCache Serverless. ThrottledRequests ElastiCache Se notate un numero elevato di richieste limitate, considerate quanto segue:
Velocità di scalabilità: ElastiCache Serverless si ridimensiona automaticamente man mano che si acquisiscono più dati o si aumenta la frequenza delle richieste. Se la tua applicazione è scalabile più velocemente della velocità con cui scalabilità ElastiCache Serverless, le tue richieste potrebbero essere limitate mentre Serverless si ridimensiona per adattarsi al tuo carico di lavoro. ElastiCache ElastiCache In genere, Serverless può aumentare rapidamente le dimensioni di storage, impiegando fino a 10-12 minuti per raddoppiare le dimensioni di archiviazione nella cache.
Distribuzione uniforme di chiavi e richieste: in ElastiCache Valkey e Redis OSS, una distribuzione non uniforme delle chiavi o delle richieste per slot può causare un hot slot. Un hot slot può comportare una limitazione delle richieste se la frequenza delle richieste verso un singolo slot supera i 30.000 al ECPUs secondo, in un carico di lavoro che viene eseguito in modo semplice. SET/GET commands. Similarly, for ElastiCache for Memcached, a hot key can result in throttling of requests if the request rate exceeds 30,000 ECPUs/second
Leggi dalla replica: se l'applicazione lo consente, prendi in considerazione l'utilizzo della funzione «Leggi dalla replica». La maggior parte dei client Valkey o Redis OSS può essere configurata per «scalare le letture» per indirizzare le letture ai nodi di replica. Questa funzionalità consente di scalare il traffico di lettura. Inoltre, ElastiCache Serverless indirizza automaticamente la lettura dalle richieste di replica ai nodi nella stessa zona di disponibilità dell'applicazione, con conseguente riduzione della latenza. Quando Read from Replica è abilitato, è possibile ottenere fino a 90.000 unità al ECPUs secondo su un singolo slot, per carichi di lavoro con semplici comandi SET/GET.
Argomenti correlati
