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 支援團隊聯絡。

調度 shard 資源

調整叢集中的 shard 數量時，應在寫入量較低時進行。在寫入負載偏高的期間調度資源，可能會因複製或槽遷移作業產生的記憶體負擔，導致叢集面臨記憶體壓力。

如果 Redis 用途會使用鍵淘汰功能，縮減叢集大小可能會降低快取命中率。不過，在這種情況下，您不必擔心資料遺失，因為金鑰會如預期遭到剔除。

如果 Redis 用途不允許遺失鍵，則應只縮減至仍有足夠空間容納資料的小型叢集。新的目標 shard 數量應至少為資料所用記憶體的 1.5 倍。換句話說，您應佈建足夠的 shard，以容納叢集資料量的 1.5 倍。您可以使用 /cluster/memory/total_used_memory 指標，查看叢集中儲存的資料量。

CPU 使用率最佳做法

如果發生非預期的可用區服務中斷，叢集的 CPU 資源會減少，因為無法使用可用區中的節點容量。建議使用高可用性叢集。如果每個 shard 使用多個副本 (而非一個副本)，則在服務中斷期間可提供額外的 CPU 資源。每個 shard 最多可有五個副本。

此外，建議您管理節點 CPU 使用率，確保節點有足夠的 CPU 負載，可在可用區發生非預期中斷時，處理因容量損失而產生的額外流量。您應使用主執行緒 CPU 秒數 /cluster/cpu/maximum_utilization 指標，監控主要執行個體和副本的 CPU 使用率。

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

• 如果叢集每個節點有一個副本，請將主要節點的 /cluster/cpu/maximum_utilization 值設為 0.5 秒，副本則設為 0.5 秒。
• 如果叢集每個節點有兩個以上的副本，請將主要節點的 /cluster/cpu/maximum_utilization 值設為 0.9 秒，每個副本則設為 0.5 秒。

如果指標值超過這些建議值，建議您增加叢集中的 shard 數量。如果叢集的副本數量少於五個，您也可以增加副本數量，最多可達五個。

如果叢集的 CPU 使用率偏高，或叢集資源耗盡 (例如連線過多)，叢集可能會運作異常，且外部指標可能會遺失。

需要大量資源的 Redis 指令

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

• 高延遲和用戶端逾時
• 增加記憶體用量的指令導致記憶體壓力
• Redis 主執行緒遭到封鎖，導致節點複製和同步處理期間資料遺失
• 健康狀態檢查、觀測能力和複製功能受限

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

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

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

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

調整門檻的最佳做法

縮放門檻情境可分為以下類別：

• 依記憶體使用率調度資源
• 根據 CPU 使用率調度資源
• 擴充以緩解熱點

如果工作負載需要剔除金鑰，Google 建議不要縮減 CPU 或記憶體使用率。在這類工作負載中，記憶體使用率通常會在自動淘汰前達到最大容量。記憶體用量因而激增，導致縮減作業無法執行。

以下各節將詳細說明常見情境和可能需要調整資源配置的指標門檻。

記憶體使用率調度

如要根據記憶體用量判斷何時應調整資源配置，請監控 /cluster/memory/average_utilization 和 /cluster/memory/maximum_utilization 指標。如要進一步瞭解這些指標，請參閱「支援的監控指標」。

如果叢集符合下列任一條件，請考慮觸發水平擴展作業：

• 叢集的平均記憶體使用率超過建議門檻 (70%)。
• 記憶體使用率最高超過 80%，平均超過 50%。

如果叢集符合下列任一條件，請考慮觸發縮減作業：

• 叢集的平均記憶體使用率低於建議門檻 (50%)。
• 最高記憶體使用率降至 60% 以下，平均記憶體使用率降至 40% 以下。

CPU 使用率調度

如要根據 CPU 使用率判斷何時應調整資源配置，請監控 /cluster/cpu/average_utilization 和 /cluster/cpu/maximum_utilization 指標。

如果叢集符合下列任一條件，請考慮觸發水平擴展作業：

• 叢集的平均 CPU 使用率超過建議門檻 70%。
• CPU 使用率上限超過 80%，平均 CPU 使用率超過 50%。

如果叢集符合下列任一條件，請考慮觸發縮減作業：

• 叢集的平均 CPU 使用率低於建議門檻 (50%)。
• 最高 CPU 使用率降至 60% 以下，平均 CPU 使用率降至 40% 以下。

擴充以緩解熱點

Memorystore for Redis Cluster 會提供相同指標的平均值和最大值變化，您可以使用這些值找出該指標系列的熱點。最大值代表負載最重的叢集節點，平均值則代表整個叢集的負載。如果最大值明顯高於平均值，表示特定節點的負載過高 (熱點)。如要解決這個問題，建議您水平擴展叢集。詳情請參閱「調整叢集容量」。

如果發現平均值和最大值之間有顯著差異，可以對叢集節點執行 INFO memory 和 INFO cpu 指令，直接從叢集收集即時資料。如要進一步瞭解如何使用這些指令，請參閱 Redis 說明文件中的 INFO。

Redis 用戶端最佳做法

應用程式連線至叢集時，必須使用叢集感知 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 探索端點執行叢集探索。探索端點具備高可用性，且會在叢集中的所有節點之間進行負載平衡。此外，探索端點會嘗試將叢集探索要求轉送至具有最新拓撲檢視畫面的節點。

偵測及處理無回應的連線

強烈建議您設定用戶端應用程式，偵測 Memorystore for Redis Cluster 連線是否無回應。偵測到無回應的連線時，用戶端必須重設連線。為建構彈性應用程式，建議您採用下列用戶端設定：

• 設定 TCP 保持運作參數：設定 TCP keepalive time、TCP keepalive interval 和 TCP keepalive probes 參數，讓用戶端主動偵測並捨棄無回應的連線，即使連線處於閒置狀態也一樣。舉例來說，如果將 TCP keepalive time 參數設為 30 秒、TCP keepalive interval 設為 10 秒，並將 TCP keepalive probes 設為 3，用戶端就會在一分鐘內重設無回應的閒置連線。
• 設定 TCP 使用者逾時：在用戶端設定這項逾時，重設有未完成要求且停止回應的連線。舉例來說，如果將逾時時間設為 15 秒，用戶端會在 15 秒後重設有未完成要求且無回應的連線。

持續性最佳做法

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

RDB 持續性及新增副本

如要使用 RDB 快照備份叢集，或在叢集中新增副本，請採用下列最佳做法，以獲得最佳效果：

記憶體管理

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

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

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

如要解決這個問題，請採取下列任一做法，減少叢集的記憶體用量：

• 將叢集的記憶體用量降低至節點允許記憶體上限的 80% 以下。
• 調整叢集的節點類型，增加記憶體。

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

過時快照

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

RDB 快照對效能的影響

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

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

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

新增副本

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

單一可用區叢集的使用時機

如果將叢集設為不使用副本，建議您使用單一可用區叢集。原因如下：

成本和效能

如果您的主要目標是盡可能降低成本，並為位於相同區域的用戶端提供最佳效能，建議您選擇單一可用區叢集。

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

選擇單一可用區叢集時，可用區中斷較不可能影響叢集。將所有節點放在單一可用區，可用區中斷影響伺服器的機率會從 100% 降至 33%。叢集所在可用區故障的機率為 33%，而位於無法使用可用區的節點受到影響的機率為 100%。

快速復原

如果單一可用區叢集發生可用區中斷，Memorystore for Redis Cluster 會簡化資料復原作業。您可以在正常運作的可用區中快速佈建新叢集，並重新導向應用程式，盡可能減少作業中斷。

容量規劃最佳做法

為確保您能成功佈建資源並建構彈性架構，建議您採用下列容量規劃最佳做法：

• 在多個位置部署：如果因暫時性資源限制而無法在偏好的可用區建立叢集，請嘗試在同一區域的其他可用區或不同區域建立叢集。
• 使用跨區域存取權：設定用戶端，存取位於不同區域的叢集。如果因本機資源限制而需要在不同區域佈建叢集，用戶端可以連線至該叢集。
• 使用跨區域複製：如要將替代區域中的次要叢集升級為主要讀取或寫入叢集，以便進行災難復原，請執行切換作業。

萵苣最佳做法

本節說明使用 Lettuce 連線至叢集的最佳做法。

更新參數值

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

啟用傳輸層安全標準 (TLS)

本節說明使用傳輸層安全標準 (TLS) 的安全性優勢和效能影響，並提供啟用建議。

安全優勢

使用 TLS 可享有下列安全性優勢：

• Identity and Access Management (IAM) 驗證：TLS 會使用這類驗證，防範伺服器詐騙攻擊，例如中間人攻擊。
• 傳輸中加密：Google Cloud的內建加密功能可在基礎架構層級保護 Google 網路內的流量。不過，這需要信任 Google 的主機和網路堆疊。雖然這項加密功能預設為啟用，且不會影響使用者體驗，但並非端對端加密。另一方面，TLS 則是在應用程式層使用傳輸中加密。這項端對端加密功能可讓您進一步控管加密金鑰和程序。
• 驗證權杖保護：如果您使用 IAM 驗證，啟用 TLS 可大幅降低驗證權杖外洩的風險。

效能影響

TLS 會以下列方式影響效能：

• 建立連線：已建立 TLS 工作階段的用戶端和伺服器可以繼續工作階段，不必重複在用戶端和伺服器之間建立連線的資源密集程序。啟用 TLS 恢復功能，可減少在用戶端和伺服器之間建立連線的負擔。

  如果未建立 TLS 恢復功能，建立連線會耗用大量資源。無論是新連線還是現有連線，用戶端與伺服器之間的多個連線都可能導致連線逾時。這可能會造成雪球效應，因為 Memorystore for Redis Cluster 會嘗試重新建立逾時的連線，進而增加建立連線時使用的資源。

• 加密及解密資料：資料加密和解密涉及 CPU 密集作業，會影響用戶端和伺服器。這可能會降低叢集容量，並增加叢集延遲時間。

建議

考慮是否啟用 TLS 時，建議您評估安全性政策，同時考量 TLS 的優缺點。如果選擇啟用 TLS，請注意下列事項：

• 啟用 TLS 恢復功能可減輕建立連線的負擔。只有在初始連線時，才需要用戶端和伺服器之間的連線。不過，如果用戶端叢集大小突然擴大，可能會因為每個新用戶端主機的初始完整交握，而導致短暫中斷。
• 雖然部分用戶端程式庫可能未提供啟用 TLS 的內建控制項，但您可以使用自訂程式碼，將這項功能整合至叢集。