本頁提供如何充分運用 Memorystore for Valkey 的指南，並指出應避免的潛在問題。
記憶體管理最佳做法
本節說明如何管理執行個體記憶體，確保 Memorystore for Valkey 能有效支援應用程式。
記憶體管理概念
記憶體用量：執行個體使用的記憶體量。記憶體容量是固定的，您可以透過指標監控記憶體用量。
淘汰政策：Memorystore for Valkey 使用
volatile-lru淘汰政策。您可以使用EXPIRE等 Valkey 指令，為鍵設定淘汰政策。
監控執行個體的記憶體用量
如要監控 Memorystore for Valkey 執行個體的記憶體用量，建議查看 /instance/memory/maximum_utilization 指標。如果執行個體的記憶體用量接近 80%，且您預期資料用量會增加，請擴充執行個體的大小，為新資料預留空間。
如果執行個體的記憶體用量偏高，請按照下列步驟提升效能：
如果發生問題，請洽詢Google Cloud 客戶服務。
在已啟用叢集模式的環境中調整分片大小
調整執行個體中的分片數量時，建議您在寫入量較低時進行調整。在用量高峰期擴充執行個體時，複製或節點遷移作業造成的記憶體負擔，可能會導致執行個體記憶體壓力過大。
如果您的 Valkey 用途會用到鍵逐出功能，縮小執行個體大小可能會降低快取命中率。不過，在這種情況下，您不必擔心資料遺失，因為鍵逐出是預期行為。
在不想遺失鍵的 Valkey 用例中，您應只縮減至仍有足夠空間儲存資料的較小執行個體。新的目標分片計數應至少是資料所用記憶體的 1.5 倍。換句話說，您應為執行個體中的資料量 1.5 倍佈建足夠的分片。您可以使用 /instance/memory/total_used_memory 指標，查看執行個體中儲存的資料量。
CPU 使用率最佳做法
如果發生非預期的可用區服務中斷，由於無法使用的可用區中節點容量減少，執行個體的 CPU 資源也會減少。建議您使用高可用性執行個體。使用多個分片副本 (而非每個分片一個副本)，可在發生中斷時提供額外的 CPU 資源。每個分片最多可有五個副本。
此外，我們建議您管理節點 CPU 使用率，確保節點有足夠的 CPU 額外負荷，可處理因意外區域性中斷而損失容量時的額外流量。您應使用「主執行緒 CPU 秒數」/instance/cpu/maximum_utilization指標，監控主要節點和副本的 CPU 使用率。
視每個節點佈建的副本數量而定，建議採用下列 /instance/cpu/maximum_utilization CPU 使用率目標：
- 如果每個節點有一個副本，主要節點和副本的目標值都是 0.5 秒。
/instance/cpu/maximum_utilization - 如果每個節點有兩個以上的副本，主要副本的目標值為 0.9 秒，每個副本的目標值為 0.5 秒。
/instance/cpu/maximum_utilization
如果指標值超過這些建議，建議您增加執行個體中的分片數量。如果執行個體的副本少於五個，您也可以增加副本數量，最多可達五個副本。
需要大量資源的 Valkey 指令
強烈建議您避免使用耗用大量資源的 Valkey 指令。使用這些指令可能會導致下列效能問題：
- 延遲時間長和用戶端逾時
- 因指令增加記憶體用量而導致記憶體壓力
- 節點複製和同步處理期間發生資料遺失，因為 Valkey 主執行緒遭到封鎖
- 健康狀態檢查、可觀測性和複製作業遭到延遲
下表列出耗用大量資源的 Valkey 指令示例，並提供資源效率高的替代方案。
| 類別 | 耗用大量資源的指令 | 資源效率較高的替代方案 |
|---|---|---|
| 針對整個鍵空間執行 | KEYS |
SCAN |
| 針對可變長度鍵集執行 | LRANGE |
限制查詢所用範圍的大小。 |
ZRANGE |
限制查詢所用範圍的大小。 | |
HGETALL |
HSCAN |
|
SMEMBERS |
SSCAN |
|
| 封鎖指令碼執行作業 | EVAL |
確認指令碼不會無限期執行。 |
EVALSHA |
確認指令碼不會無限期執行。 | |
| 移除檔案和連結 | DELETE |
UNLINK |
| 發布及訂閱 | PUBLISH |
SPUBLISH |
SUBSCRIBE |
SSUBSCRIBE |
Valkey 用戶端最佳做法
避免 Valkey 連線過載
為減輕連線突然湧入造成的影響，建議採取下列做法：
決定最適合您的用戶端連線集區大小。每個用戶端的良好起始大小是每個 Valkey 節點一個連線。接著，您可以進行基準化，看看增加連線數是否有幫助，但不要超過允許的連線數上限。
如果伺服器逾時導致用戶端與伺服器中斷連線，請使用指數輪詢重試，並加入隨機延遲，避免多個用戶端同時造成伺服器過載。
適用於已啟用叢集模式的執行個體
連線至啟用叢集模式的 Memorystore for Valkey 執行個體時，應用程式必須使用叢集感知 Valkey 用戶端。如需叢集感知用戶端和範例設定，請參閱「用戶端程式庫程式碼範例」。用戶端必須維護雜湊值區對應執行個體中相應節點的地圖，才能將要求傳送至正確的節點。這樣可避免重新導向造成的效能負擔。
用戶端對應
在下列情況下，客戶必須取得完整的時段清單和對應節點：
初始化用戶端時，必須填入節點對應的初始時段。
當伺服器傳送
MOVED重新導向時，例如在容錯移轉情況下，當前主要節點服務的所有時段都由副本接管，或重新分片時，時段會從來源主要節點移至目標主要節點。當伺服器傳回
CLUSTERDOWN錯誤，或連線至特定伺服器時持續發生逾時問題。從伺服器收到
READONLY錯誤。如果主要項目降級為副本，就可能發生這種情況。此外，用戶端應定期重新整理拓撲，讓用戶端為任何變更做好準備，並瞭解可能不會導致伺服器重新導向或發生錯誤的變更，例如新增副本節點時。請注意，拓撲重新整理時也應關閉任何過時的連線，以減少在指令執行階段處理連線失敗的需求。
發掘客戶
通常是向 Valkey 伺服器發出 SLOTS、NODES 或 CLUSTER SHARDS 指令，進行用戶端探索。建議使用 CLUSTER SHARDS 指令。CLUSTER SHARDS 會取代 SLOTS 指令 (已淘汰)，提供執行個體更有效率且可擴充的表示法。
用戶端探索指令的回應大小會因執行個體大小和拓撲而異。節點較多的較大執行個體會產生較大的回應。因此，請務必確保執行節點拓撲探索的用戶端數量不會無限增加。
這些節點拓撲重新整理作業在 Valkey 伺服器上非常耗費資源，但對應用程式可用性而言也很重要。因此，請務必確保每個用戶端在任何時間點都只發出單一探索要求 (並將結果快取在記憶體中)，且發出要求的用戶端數量受到限制，以免伺服器過載。
舉例來說，當用戶端應用程式啟動或與伺服器失去連線，且必須執行節點探索時，常見的錯誤是用戶端應用程式會發出多個重新連線和探索要求，但重試時不會新增指數輪詢。這可能會導致 Valkey 伺服器長時間沒有回應，並造成 CPU 使用率極高。
使用探索端點探索節點
使用 Memorystore for Valkey 探索端點執行節點探索。探索端點具有高可用性，且會在執行個體的所有節點之間進行負載平衡。此外，探索端點會嘗試將節點探索要求，路由至具有最新拓撲檢視畫面的節點。
適用於已停用叢集模式的執行個體
連線至已停用叢集模式的執行個體時，應用程式必須連線至主要端點，才能寫入執行個體及擷取最新寫入內容。應用程式也可以連線至讀取器端點，從副本讀取資料，並將流量與主要節點隔離。
如果您在維護執行個體時使用 create-before-destroy 策略，可能會收到下列錯誤訊息：
READONLY You can't write against a read only replica.
如要解決這個問題，請停止連線至執行個體，然後重新建立連線。
持續性最佳做法
本節說明持續性的最佳做法。
RDB 持久性與新增備用資源
如要使用 RDB 快照備份執行個體，或在執行個體中新增副本，建議採用下列最佳做法：
記憶體管理
RDB 快照會使用程序分叉和「寫入時複製」機制，擷取節點資料的快照。視節點的寫入模式而定，節點使用的記憶體會隨著寫入觸及的頁面遭到複製而增加。記憶體用量最多可達節點中資料大小的兩倍。
為確保節點有足夠的記憶體可完成快照，請將 maxmemory 設為節點容量的 80%，保留 20% 做為額外負擔。除了監控快照，這項記憶體額外負擔也有助於管理工作負載，順利建立快照。此外，新增副本時，請盡可能降低寫入流量。詳情請參閱「監控執行個體的記憶體用量」。
過時的快照
從過時的快照還原節點時，應用程式會嘗試調解大量過時的鍵，或資料庫的其他變更 (例如結構定義變更)，因此可能會發生效能問題。如果擔心從過時的快照還原，可以停用 RDB 持續性功能。重新啟用持續性後，系統會在下一個排定的快照間隔建立快照。
RDB 快照對效能的影響
視工作負載模式而定，RDB 快照可能會影響執行個體的效能，並增加應用程式的延遲時間。如果您可以接受較低的快照頻率，不妨將快照排定在執行個體流量較低的時段執行，盡量減少 RDB 快照對效能的影響。
舉例來說，如果執行個體在凌晨 1 點到 4 點的流量較低，您可以將開始時間設為凌晨 3 點，間隔設為 24 小時。
如果系統負載量持續增加，且需要頻繁建立快照，建議您仔細評估效能影響，並權衡使用 RDB 快照對工作負載的好處。
新增副本
新增副本需要 RDB 快照。如要進一步瞭解 RDB 快照，請參閱「記憶體管理」。
單一區域執行個體的使用時機
如果設定執行個體時不使用副本，建議您使用單一可用區執行個體。原因如下：
費用和效能
如果主要目標是為位於相同區域的客戶盡量降低成本並提供最佳效能，建議您選擇單一可用區執行個體。
將服務中斷的影響降至最低
選擇單一可用區執行個體時，可用區中斷較不會影響執行個體。將所有節點放在單一區域內，區域性服務中斷影響伺服器的機率就會從 100% 降至 33%。執行個體所在區域有 33% 的機率會停機，而位於無法使用區域的節點則有 100% 的機率會受到影響。
快速復原
如果單一可用區執行個體發生可用區服務中斷情形，Memorystore for Valkey 可簡化資料復原程序。您可以在運作正常的可用區中快速佈建新執行個體，並重新導向應用程式，盡量減少作業中斷時間。
啟用傳輸層安全標準 (TLS)
本節說明使用傳輸層安全標準 (TLS) 的安全性優點和效能影響，並提供啟用建議。
安全防護福利
使用 TLS 可享有下列安全性優點：
- 身分與存取權管理 (IAM) 驗證：傳輸層安全標準 (TLS) 會使用這類驗證來防範伺服器詐騙攻擊，例如中間人攻擊。
- 傳輸加密： Google Cloud的內建加密功能可在基礎架構層級保護 Google 網路內的流量。不過，這需要信任 Google 的主機和網路堆疊。雖然這項加密功能預設為啟用，且使用者不會察覺，但並非端對端加密。另一方面，TLS 則是在應用程式層使用傳輸中資料加密。這種端對端加密方式可讓您進一步控管加密金鑰和程序。
- 驗證權杖保護： 如果您使用 IAM 驗證，啟用 TLS 可將驗證權杖曝光和洩漏的風險降到最低。
效能影響
傳輸層安全標準 (TLS) 會對效能造成以下影響：
建立連線：建立 TLS 工作階段後，用戶端和伺服器即可繼續執行工作階段，不必重複建立用戶端與伺服器連線的資源密集程序。啟用 TLS 繼續作業後，即可減少建立用戶端與伺服器連線的負擔。
如果未建立 TLS 續傳，建立連線就會耗用大量資源。無論是新連線還是現有連線，用戶端與伺服器之間的多個連線都可能導致連線逾時。這可能會造成雪球效應，因為 Memorystore for Valkey 會嘗試重新建立逾時連線，進而增加建立連線時使用的資源。
加密及解密資料： 資料加密和解密作業需要大量 CPU 資源，會影響用戶端和伺服器。這可能會降低執行個體的容量，並增加執行個體的延遲時間。
建議
考慮是否啟用 TLS 時，建議您評估安全性政策，同時考量 TLS 的優點和缺點。如果您選擇啟用 TLS，請注意下列事項：
- 啟用 TLS 續傳功能可減輕建立連線的作業負擔。用戶端與伺服器之間的連線僅用於初始連線。不過，如果用戶端執行個體大小突然擴充，可能會導致短暫中斷，這是因為每個新用戶端主機都會進行初始完整交握。
- 雖然部分用戶端程式庫可能未提供內建控制項來啟用 TLS，但您可以使用自訂程式碼，將這項功能整合至執行個體。