本頁提供如何充分運用 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 使用率目標：
- 如果每個節點有 1 個副本，主要副本和副本的
/instance/cpu/maximum_utilization值應為 0.5 秒。 - 如果每個節點有 2 個副本，主要執行個體的目標
/instance/cpu/maximum_utilization值應為 0.9 秒，副本則為 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 快照的好處。
如果執行個體未使用副本，請選擇單一可用區執行個體
設定沒有副本的執行個體時，建議採用單一可用區架構，以提升可靠性。原因如下：
將服務中斷的影響降至最低
區域性服務中斷較不會影響執行個體。將所有節點放在單一區域內，區域性中斷影響伺服器的機率就會從 100% 降至 33%。這是因為執行個體所在區域有 33% 的機率會停機，而位於無法使用區域的節點則有 100% 的機率會受到影響。
快速復原
如果發生區域性中斷，系統會簡化復原程序。您可以快速在運作中的區域佈建新執行個體，並重新導向應用程式，盡量減少作業中斷時間。