Memorystore for Redis Cluster 的最佳做法

本頁面提供指引，說明如何以最佳方式使用 Memorystore for Redis Cluster。這個頁面也會指出應避免的潛在問題。

注意： 如要查看 Redis 叢集用戶端設定範例，請參閱用戶端程式庫程式碼範例。

記憶體管理最佳做法

本節說明如何管理執行個體記憶體，確保 Memorystore for Redis Cluster 能有效率地為應用程式運作。

記憶體管理概念

• 寫入負載：在 Redis 叢集上新增或更新金鑰的量和速度。視 Redis 用途和應用程式使用模式而定，寫入負載可能介於正常到非常高之間。

• 淘汰政策 - Memorystore for Redis Cluster 使用 volatile-lru 淘汰政策。您可以使用 EXPIRE 等指令，為鍵設定逐出作業。

監控寫入負載正常的叢集

查看 /cluster/memory/maximum_utilization 指標。如果 /cluster/memory/maximum_utilization 為 100% 或更低，表示您使用正常寫入負載時，Redis 叢集運作良好。

不過，如果記憶體用量接近 100%，且您預期資料用量會增加，則應擴充叢集大小，為新資料預留空間。

監控寫入負載高的叢集

查看 /cluster/memory/maximum_utilization 指標。視高寫入負載的嚴重程度而定，叢集可能會在下列門檻發生效能問題：

• 如果 /cluster/memory/maximum_utilization 達到 65% 以上，寫入負載過高可能會導致問題。

• 如果 /cluster/memory/maximum_utilization 達到 85% 以上，中等偏高的寫入負載可能會發生問題。

在這些情況下，您應擴大叢集大小，以提升效能。

如果遇到問題，或擔心執行個體的寫入負載過高，請與Google Cloud 支援團隊聯絡。

調整分片大小

在執行個體中調整分片數量時，應在寫入量較低的期間進行。在寫入負載量高的期間進行擴充，可能會因複製或時段遷移造成的記憶體負擔，導致執行個體記憶體壓力過大。

如果您的 Redis 用途會用到金鑰逐出，縮減叢集大小可能會降低快取命中率。不過，在這種情況下，您不必擔心資料遺失，因為金鑰遭逐出是預料中的事。

如果 Redis 用途不允許遺失金鑰，您只能縮減至仍有足夠空間儲存資料的較小叢集。新的目標分片數應至少是資料所用記憶體的 1.5 倍。換句話說，您應為叢集中目前資料量的 1.5 倍，佈建足夠的分片。您可以使用 /cluster/memory/total_used_memory 指標，查看執行個體中儲存的資料量。

CPU 用量最佳做法

如果發生非預期的區域中斷，由於無法使用的區域中節點容量減少，叢集的 CPU 資源也會減少。建議使用高可用性叢集。每個分片使用兩個副本 (而非每個分片一個副本)，可在中斷期間提供額外的 CPU 資源。此外，建議您管理節點 CPU 使用率，確保節點有足夠的 CPU 額外負荷，可處理因可用區意外中斷而增加的流量。您應使用 /cluster/cpu/maximum_utilization 指標監控主要節點和副本的 CPU 使用率。

視每個節點佈建的副本數量而定，建議採用下列 /cluster/cpu/maximum_utilization CPU 使用率目標：

• 如果每個節點有一個備用資源，當備用資源指定為唯讀備用資源時，主要資源和備用資源的 /cluster/cpu/maximum_utilization 目標值應為 0.5 秒。
• 如果每個節點有兩個副本，主要副本的目標值為 0.8 秒，每個副本的目標值為 0.5 秒。/cluster/cpu/maximum_utilization

如果指標值超出這些建議，建議您增加執行個體中的分片或副本數量。

需要大量資源的 Redis 指令

強烈建議您避免使用耗用大量資源的 Redis 指令。使用這些指令可能會導致下列效能問題：

• 延遲時間長和用戶端逾時
• 因指令增加記憶體用量而導致記憶體壓力
• 節點複製和同步處理期間發生資料遺失，因為 Redis 主執行緒遭到封鎖
• 健康狀態檢查資源不足、可觀測性和複製

下表列出耗用大量資源的 Redis 指令示例，並提供耗用資源較少的替代方案。

提示：除了耗用大量資源外，隨著資料總大小增加，使用這些指令的成本也會提高。

如要找出您使用的長時間執行指令，請使用 SLOWLOG。這項工具會列出執行時間最長的指令，因此，您會知道造成延遲問題的指令。如要判斷這些指令的資源效率替代方案，請參閱下表。

類別	耗用大量資源的指令	資源效率替代方案
針對整個鍵空間執行	KEYS	SCAN
針對可變長度鍵集執行	LRANGE	限制查詢所用範圍的大小。
	ZRANGE	限制查詢所用範圍的大小。
	HGETALL	HSCAN
	SMEMBERS	SSCAN
封鎖指令碼執行作業	EVAL	請確保指令碼不會無限期執行。
	EVALSHA	請確保指令碼不會無限期執行。
移除檔案和連結	DELETE	UNLINK
發布及訂閱	PUBLISH	SPUBLISH
	SUBSCRIBE	SSUBSCRIBE

Redis 用戶端最佳做法

連線至 Memorystore for Redis Cluster 執行個體時，應用程式必須使用叢集感知 Redis 用戶端。如需叢集感知型用戶端和範例設定，請參閱「用戶端程式庫程式碼範例」。客戶必須維護雜湊值位置對應叢集中節點的地圖，才能將要求傳送至正確的節點，並避免叢集重新導向造成的效能負擔。

用戶端對應

在下列情況下，客戶必須取得完整的時段清單和對應節點：

• 初始化用戶端時，必須填入節點對應的初始時段。

• 當伺服器傳送 MOVED 重新導向時，例如在容錯移轉情況下，當前主要節點服務的所有時段都由副本接管，或重新分片時，時段會從來源主要節點移至目標主要節點。

• 當伺服器傳回 CLUSTERDOWN 錯誤，或與特定伺服器的連線持續逾時時。

• 伺服器傳回 READONLY 錯誤時，如果主要項目降級為副本，就可能會發生這種情況。

• 此外，用戶端應定期重新整理拓撲，讓用戶端保持暖機狀態，以因應任何變更，並瞭解可能不會導致伺服器重新導向/發生錯誤的變更，例如新增副本節點時。請注意，拓撲重新整理時也應關閉任何過時的連線，以減少在指令執行階段處理連線失敗的需求。

發掘顧客

用戶端通常會向 Redis 伺服器發出 CLUSTER SLOT、CLUSTER NODE 或 CLUSTER SHARDS 指令，進行用戶端探索。建議使用 CLUSTER SHARDS 指令。CLUSTER SHARDS 取代 CLUSTER SLOTS 指令 (已淘汰)，可更有效率地擴充叢集。

叢集用戶端探索指令的回覆大小會因叢集大小和拓撲而異。節點越多的大型叢集會產生較大的回應。因此，請務必確保執行叢集拓撲探索的用戶端數量不會無限增加。

這些拓撲重新整理作業在 Redis 伺服器上代價高昂，但對應用程式可用性而言也很重要。因此，請務必確保每個用戶端在任何時間點都只發出單一探索要求 (並將結果快取在記憶體中)，且發出要求的用戶端數量受到限制，以免伺服器負載過重。

舉例來說，當用戶端應用程式啟動或與伺服器失去連線，且必須執行叢集探索時，常見的錯誤是用戶端應用程式會發出多個重新連線和探索要求，但不會在重試時加入指數輪詢。這可能會導致 Redis 伺服器長時間沒有回應，造成 CPU 使用率極高。

避免 Redis 上的探索作業過載

為減輕連線和探索要求突然湧入所造成的影響，建議採取下列做法：

• 實作大小有限且較小的用戶端連線集區，限制用戶端應用程式的並行連入連線數。

• 如果用戶端因逾時而與伺服器中斷連線，請使用指數輪詢和隨機延遲重試。這有助於避免多個用戶端同時對伺服器造成負擔。

• 使用 Memorystore for Redis Cluster 探索端點執行叢集探索。探索端點具備高可用性，且叢集內所有節點都會進行負載平衡。此外，探索端點會嘗試將叢集探索要求轉送至具有最新拓撲檢視畫面的節點。

持續性最佳做法

本節說明持續性的最佳做法。

RDB 持久性與新增副本

如要使用 RDB 快照備份執行個體，或在執行個體中新增副本，建議採用下列最佳做法：

記憶體管理

RDB 快照會使用程序分叉和「寫入時複製」機制，擷取節點資料的快照。視節點的寫入模式而定，節點使用的記憶體會隨著寫入觸及的頁面遭到複製而增加。記憶體用量最多可達節點中資料大小的兩倍。

為確保節點有足夠的記憶體來完成快照，請將 maxmemory 維持或設為節點容量的 80%，保留 20% 做為額外負擔。除了監控快照之外，這項記憶體負荷也有助於管理工作負載，確保快照順利建立。此外，新增副本時，請盡可能降低寫入流量。詳情請參閱「監控寫入負載高的叢集」。

注意：如果叢集使用的記憶體超過上限的 80%，您就無法在該叢集中新增副本，否則作業會失敗並顯示錯誤訊息。

如要解決這個問題，請透過下列任一方式減少叢集的記憶體用量：

• 將叢集的記憶體用量降低至節點最大允許記憶體的 80% 以下。
• 擴充叢集的節點類型，增加記憶體容量。

叢集的記憶體用量低於 80% 門檻後，請再次新增副本。

過時的快照

從過時快照還原節點可能會導致應用程式發生效能問題，因為應用程式會嘗試調解大量過時的鍵，或資料庫的其他變更 (例如結構定義變更)。如果擔心從過時的快照還原，可以停用 RDB 持續性功能。重新啟用持續性後，系統會在下一個排定的快照間隔建立快照。

RDB 快照對效能的影響

視工作負載模式而定，RDB 快照可能會影響執行個體效能，並增加應用程式的延遲時間。如果您可以接受較低的快照頻率，可以將 RDB 快照排定在執行個體流量較低的時段執行，盡量減少對效能的影響。

舉例來說，如果執行個體在凌晨 1 點到 4 點的流量較低，您可以將開始時間設為凌晨 3 點，間隔設為 24 小時。

如果系統負載量穩定，且需要頻繁建立快照，請仔細評估效能影響，並權衡使用 RDB 快照對工作負載的好處。

新增副本

新增副本時，需要 RDB 快照。如要進一步瞭解 RDB 快照，請參閱「記憶體管理」一文。

如果執行個體未使用副本，請選擇單一可用區執行個體

設定沒有副本的執行個體時，建議採用單一可用區架構，以提升可靠性。原因如下：

將服務中斷的影響降至最低

區域性服務中斷較不會影響執行個體。將所有節點放在單一區域內，區域性中斷影響伺服器的機率就會從 100% 降至 33%。這是因為執行個體所在區域有 33% 的機率會停機，而位於無法使用區域的節點則有 100% 的機率會受到影響。

快速復原

如果發生區域性中斷，系統會簡化復原程序。您可以快速在運作中的區域佈建新執行個體，並重新導向應用程式，盡量減少作業中斷。

Lettuce 最佳做法

本節說明使用 Lettuce 連線至 Memorystore for Redis Cluster 執行個體的最佳做法。

更新參數值

使用 Lettuce 時，請將 validateClusterNodeMembership 參數變更為 false。否則，拓撲變更時可能會發生unknownPartition錯誤。