本頁面提供如何充分運用 Memorystore for Valkey 的指南。這個頁面也會指出應避免的潛在問題。
記憶體管理最佳做法
本節說明管理執行個體記憶體的策略，確保 Memorystore for Valkey 能有效率地為應用程式運作。
記憶體管理概念
記憶體用量：執行個體使用的記憶體量。你擁有固定的記憶體容量。您可以透過指標監控記憶體用量。
淘汰政策：Memorystore for Valkey 使用
volatile-lru淘汰政策。您可以使用 Valkey 指令 (例如EXPIRE指令) 設定鍵的逐出作業。
監控執行個體的記憶體用量
如要監控 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 - 如果每個節點有兩個以上的副本，主要副本的
/instance/cpu/maximum_utilization值應為 0.9 秒，每個副本的/instance/cpu/maximum_utilization值應為 0.5 秒。
如果指標值超出這些建議，建議您擴大執行個體中的分片數量。如果執行個體的備用資源少於五個，您也可以增加備用資源數量，最多可增加至五個。
需要大量資源的 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 探索端點執行節點探索。探索端點具備高可用性，且會在執行個體的所有節點之間進行負載平衡。此外，探索端點會嘗試將節點探索要求，路徑導向具有最新拓撲檢視畫面的節點。
已停用叢集模式的執行個體
連線至已停用叢集模式的執行個體時，應用程式必須連線至主要端點，才能寫入執行個體及擷取最新寫入內容。應用程式也可以連線至讀取器端點，從副本讀取資料，並將流量與主要節點隔離。
持續性最佳做法
本節說明持續性的最佳做法。
RDB 持久性與新增副本
如要使用 RDB 快照備份執行個體，或在執行個體中新增副本，建議採用下列最佳做法：
記憶體管理
RDB 快照會使用程序分叉和「寫入時複製」機制，擷取節點資料的快照。視節點的寫入模式而定，節點使用的記憶體會隨著寫入觸及的頁面遭到複製而增加。記憶體用量最多可達節點中資料大小的兩倍。
為確保節點有足夠的記憶體來完成快照，請將 maxmemory 設為節點容量的 80%，保留 20% 做為額外負擔。除了監控快照之外，這項記憶體負擔也有助於管理工作負載，確保快照順利建立。此外，新增副本時，請盡可能降低寫入流量。詳情請參閱「監控執行個體的記憶體用量」。
過時的快照
從過時的快照還原節點可能會導致應用程式發生效能問題，因為應用程式會嘗試協調大量過時的鍵，或資料庫的其他變更 (例如結構定義變更)。如果擔心從過時的快照還原，可以停用 RDB 持續性功能。重新啟用持續性後，系統會在下一個排定的快照間隔建立快照。
RDB 快照對效能的影響
視工作負載模式而定，RDB 快照可能會影響執行個體效能，並增加應用程式的延遲時間。如果您可以接受較低的快照頻率，可以將 RDB 快照排定在執行個體流量較低的時段執行，盡量減少對效能的影響。
舉例來說，如果執行個體在凌晨 1 點到 4 點的流量較低，您可以將開始時間設為凌晨 3 點，間隔設為 24 小時。
如果系統負載量穩定，且需要頻繁建立快照，請仔細評估效能影響，並權衡使用 RDB 快照對工作負載的好處。
新增副本
新增副本時，需要 RDB 快照。如要進一步瞭解 RDB 快照，請參閱「記憶體管理」一文。
如果執行個體未使用副本，請選擇單一可用區執行個體
設定沒有副本的執行個體時，建議採用單一可用區架構，以提升可靠性。原因如下：
將服務中斷的影響降至最低
區域性服務中斷較不會影響執行個體。將所有節點放在單一區域內，區域性中斷影響伺服器的機率就會從 100% 降至 33%。這是因為執行個體所在區域有 33% 的機率會停機，而位於無法使用區域的節點則有 100% 的機率會受到影響。
快速復原
如果發生區域性中斷，系統會簡化復原程序。您可以快速在運作中的區域佈建新執行個體，並重新導向應用程式，盡量減少作業中斷。
啟用傳輸層安全標準 (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，但您可以使用自訂程式碼，將這項功能整合至執行個體。