本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
常見疑難排解步驟和最佳做法
連線問題
如果您無法連線到 ElastiCache 快取記憶體，請考慮下列其中一項：
使用 TLS：如果您在嘗試連接到 ElastiCache 端點時遇到掛斷連接，則可能沒有在客戶端中使用 TLS。如果您使用的是 ElastiCache 無伺服器，傳輸中的加密一律會啟用。確定您的用戶端使用 TLS 連線至快取。在這裡進一步了解如何連線至啟用 TLS 的快取。
VPC： ElastiCache 快取只能從 VPC 內存取。確保您從中存取快取和快取的 EC2 執行個體是在 ElastiCache 相同的 VPC 中建立的。或者，您必須在 EC2 執行個體所在的 VPC 和建立快取的 VPC 之間啟用 VPC 對等。
安全性群組：ElastiCache 使用安全性群組來控制快取的存取。考慮下列各項：
Redis 的 OSS 用戶端錯誤
ElastiCache 無伺服器只能使用支援 Redis OSS 叢集模式通訊協定的 Redis OSS 用戶端來存取。根據叢集配置，可以從 Redis OSS 用戶端以任一模式存取自行設計的叢集。
如果您的用戶端發生 Redis OSS 錯誤，請考慮下列事項：
叢集模式：如果您在使用 SELE CT
Redis OSS 命令時遇到 CROSSLOT 錯誤或錯誤，您可能會嘗試使用不支援 Redis OSS 叢集通訊協定的 Redis OSS 用戶端來存取已啟用叢集模式的快取。 ElastiCache 無伺服器僅支援支援 Redis OSS 叢集通訊協定的 Redis OSS 用戶端。如果要在「叢集模式停用」(CMD) 中使用 Redis OSS，則必須設計自己的叢集。 CROSSLOT 錯誤：如果您遇到
ERR CROSSLOT Keys in request don't hash to the same slot錯誤，您可能正在嘗試存取不屬於叢集模式快取中相同插槽的金鑰。提醒您， ElastiCache 無伺服器一律以叢集模式運作。只有當涉及的所有密鑰都在相同的哈希插槽中時，才允許涉及多個密鑰的多鍵操作，事務或 Lua 腳本。
如需設定 Redis OSS 用戶端的其他最佳作法，請參閱此部落格文章
疑難排解 ElastiCache 無伺服器中的高延遲
如果您的工作負載出現高延遲，您可以分析 CloudWatch SuccessfulReadRequestLatency和SuccessfulWriteRequestLatency指標，以檢查延遲是否與 ElastiCache 無伺服器相關。這些指標會測量 ElastiCache 無伺服器內部的延遲時間-不包括用戶端和 ElastiCache 無伺服器端點之間的用戶端延遲和網路行程時間。
疑難排解用戶端
如果您注意到用戶端的延遲提高，但沒有相應的增加CloudWatch SuccessfulReadRequestLatency和測量伺服器端延遲的SuccessfulWriteRequestLatency指標，請考慮下列事項：
確定安全性群組允許存取連接埠 6379 和 6380： ElastiCache 無伺服器使用 6379 連接埠作為主要端點，而 6380 連接埠則用於讀取器端點。某些用戶端會為每個新連線建立兩個連接埠的連線，即使您的應用程式未使用「從複本讀取」功能也一樣。如果您的安全性群組不允許對這兩個連接埠進行輸入存取，則建立連線可能需要更長的時間。在這裡進一步了解如何設定連接埠存取。
疑難排解伺服器
一些變異性和偶爾的尖峰不應該是引起關注的原因。但是，如果Average統計數據顯示急劇增加並持續存在，則應檢查 AWS Health Dashboard 和您的 Personal Health Dashboard 以獲取更多信息。如有必要，請考慮使用 AWS Support.
請考慮下列減少延遲的最佳做法和策略：
啟用從複本讀取：如果您的應用程式允許，建議您在 Redis OSS 用戶端中啟用「從複本讀取」功能來擴展讀取並降低延遲。啟用時， ElastiCache 無伺服器會嘗試將讀取請求路由到與用戶端位於相同可用區域 (AZ) 的複本快取節點，以避免跨可用區域網路延遲。請注意，在用戶端中啟用「從複本讀取」功能表示您的應用程式會接受資料的最終一致性。如果您在寫入金鑰後嘗試讀取，您的應用程式可能會在一段時間內收到較舊的資料。
確保您的應用程序部署在與緩存相同的 AZ 中：如果您的應用程序未部署在與緩存相同的 AZ 中，則可能會發現更高的客戶端延遲。建立無伺服器快取時，您可以提供應用程式存取快取的子網路，而 ElastiCache 無伺服器會在這些子網路中建立 VPC Endpoint。確定您的應用程式部署在相同的 AZ 中。否則，您的應用程式可能會在存取快取時產生跨 AZ 躍點，從而導致用戶端延遲較高。
重複使用連線：ElastiCache 無伺服器要求是透過使用 RESP 通訊協定，透過啟用 TLS 的 TCP 連線進行。啟動連接（包括驗證連接，如果配置）需要一些時間，因此第一個請求的延遲比典型更高。透過已初始化連線的要求可提供一致 ElastiCache的低延遲。因此，您應該考慮使用連線集區或重複使用現有 Redis OSS 連線。
擴展速度：ElastiCache 無伺服器會隨著您的請求率增加而自動擴展。如果要求率突然大幅增加，比 ElastiCache 無伺服器擴充速度快，可能會導致延遲提高一段時間。 ElastiCache 無伺服器通常可以快速提高支援的要求率，最多需要 10 到 12 分鐘才能將請求率提高一倍。
檢查長時間執行的命令：部分 Redis OSS 命令 (包括 Lua 指令碼或大型資料結構上的命令) 可能會執行很長時間。若要識別這些指令，請 ElastiCache 發佈指令層級度量。使用ElastiCache 無伺服器，您可以使用指
BasedECPUs標。限制要求：在 ElastiCache 無伺服器中限制要求時，您可能會遇到應用程式用戶端延遲增加的情況。在 ElastiCache 無伺服器中限制要求時，您應該會看到無伺服器指標有所增加ThrottledRequestsElastiCache 。請檢閱以下章節以進行節流請求的疑難排解。
金鑰和要求的統一散佈：在 ElastiCache (Redis OSS) 中，每個插槽的金鑰或要求分配不均勻可能會導致熱插槽，進而導致延遲提升。 ElastiCache 在執行簡單 SET/GET 命令的工作負載中，無伺服器在單一插槽上最多支援每秒 30,000 個 ECP (使用「從複本讀取」時/秒為 90,000 個 ECP)。我們建議您評估金鑰和跨插槽的要求分配，並在您的請求率超過此限制時確保一致的分配。
疑難排解無伺服器中的節流問題 ElastiCache
在服務導向架構和分散式系統中，限制各種服務元件處理 API 呼叫的速率稱為限流。這樣可以平滑尖峰、控制元件輸送量的不相符，並在發生意外的操作事件時提供更可預測的復原。 ElastiCache 無伺服器專為這些類型的架構而設計，而且大多數 Redis OSS 用戶端都內建了針對節流要求的重試。某種程度的限流對應用程式來說不一定是問題，但資料工作流程中對延遲敏感的部分如果持續遭到限流，可能會對使用者體驗造成負面影響，並降低系統的整體效率。
在 ElastiCache 無伺服器中限制要求時，您應該會看到無伺服器指標有所增加ThrottledRequestsElastiCache 。如果您注意到大量限制的要求，請考慮下列事項：
擴展速度：ElastiCache 無伺服器會隨著您擷取更多資料或提高請求速率而自動擴展。如果您的應用程式擴展速度快於無伺服器擴展的速度，則 ElastiCache 無伺服器擴展以適應您的工作負載時 ElastiCache ，您的請求可能會受到限制。 ElastiCache 無伺服器通常可以快速增加儲存大小，最多需要 10-12 分鐘才能將快取中的儲存大小增加一倍。
金鑰和要求的統一分佈：在 ElastiCache (Redis OSS) 中，每個插槽的金鑰或要求分配不均勻可能會導致熱插槽。如果在執行簡單 SET/GET 命令的工作負載中，單一插槽的要求速率超過每秒 30,000 ECP，熱插槽可能會導致請求節流。
從複本讀取：如果應用程式允許，請考慮使用「從複本讀取」功能。大多數 Redis OSS 用戶端都可以設定為「縮放讀取」，以將讀取導向複本節點。此功能可讓您擴展讀取流量。此外， ElastiCache 無伺服器會自動將讀取從複本請求路由到與應用程式相同的可用區域中的節點，從而降低延遲。啟用「從複本讀取」時，對於使用簡單 SET/GET 命令的工作負載，您可以在單一插槽上達到最多 90,000 個 ECP。
相關主題
