本頁面提供 Memorystore for Valkey 的最佳使用指南。本頁也會指出應避免的潛在問題。
記憶體管理最佳做法
本節說明管理執行個體記憶體的策略,確保 Memorystore for Valkey 能有效率地為應用程式運作。
記憶體管理概念
記憶體用量:執行個體使用的記憶體量。記憶體容量固定。您可以使用指標監控記憶體用量。
淘汰政策:Memorystore for Valkey 採用
volatile-lru淘汰政策。您可以使用 Valkey 指令 (例如EXPIRE指令) 設定鍵的淘汰。
監控執行個體的記憶體用量
如要監控 Memorystore for Valkey 執行個體的記憶體用量,建議您查看 /instance/memory/maximum_utilization 指標。如果執行個體的記憶體用量接近 80%,且您預期資料用量會增加,請擴大執行個體,為新資料騰出空間。
如果執行個體的記憶體用量偏高,請採取下列措施來提升效能:
如果發生問題,請與 Google Cloud 客戶服務 團隊聯絡。
在啟用叢集模式時調度 shard 資源
調整執行個體中的 shard 數量時,建議在寫入量較低時進行。在高用量期間調度資源,可能會因為複製或運算單元遷移作業造成的記憶體負擔,導致執行個體面臨記憶體壓力。
如果 Valkey 用途會使用鍵排除,縮減至較小的執行個體大小可能會降低快取命中率。不過,在這種情況下,您不必擔心資料遺失,因為金鑰淘汰是預期行為。
如果 Valkey 用途不允許遺失鍵,請務必縮減至仍有足夠空間容納資料的小型執行個體。新的目標 shard 數量應至少為資料所用記憶體的 1.5 倍。換句話說,您應佈建足夠的 shard,以容納執行個體中 1.5 倍的資料量。您可以使用 /instance/memory/total_used_memory 指標,查看執行個體中儲存的資料量。
CPU 使用率最佳做法
如果可用區意外中斷服務,執行個體會因無法使用可用區中的節點而失去容量,導致 CPU 資源減少。建議使用高可用性執行個體。如果每個 shard 使用多個副本 (而非一個副本),則在服務中斷期間可提供額外的 CPU 資源。每個 shard 最多可有五個副本。
此外,建議您管理節點 CPU 使用率,確保節點有足夠的 CPU 負載,可在可用區發生非預期中斷時,處理因容量損失而產生的額外流量。您應使用主執行緒 CPU 秒數 /instance/cpu/maximum_utilization 指標,監控主要執行個體和副本的 CPU 使用率。
視您為每個節點佈建的副本數量而定,建議您採用下列 /instance/cpu/maximum_utilization CPU 使用率目標:
- 如果執行個體每個節點有一個副本,請將主要節點的
/instance/cpu/maximum_utilization值設為 0.5 秒,副本則設為 0.5 秒。 - 如果執行個體每個節點有兩個以上的副本,請將主要節點的
/instance/cpu/maximum_utilization值設為 0.9 秒,每個副本則設為 0.5 秒。
如果指標值超過這些建議值,建議您增加執行個體中的 shard 數量。如果執行個體的副本數量少於五個,您也可以增加副本數量,最多可達五個。
如果執行個體的 CPU 使用率偏高,或執行個體的資源耗盡 (例如連線過多),執行個體可能會發生異常行為,且外部指標可能會遺失。
需要大量資源的 Valkey 指令
強烈建議您避免使用會耗用大量資源的 Valkey 指令。使用這些指令可能會導致下列效能問題:
- 高延遲和用戶端逾時
- 增加記憶體用量的指令導致記憶體壓力
- Valkey 主執行緒遭到封鎖,導致節點複製和同步處理期間資料遺失
- 健康狀態檢查、觀測能力和複製功能受限
下表列出耗用大量資源的 Valkey 指令範例,並提供節省資源的替代方案。
| 類別 | 資源密集型指令 | 資源效率替代方案 |
|---|---|---|
| 針對整個鍵空間執行 | KEYS |
SCAN |
| 執行可變長度金鑰集 | LRANGE |
限制查詢使用的範圍大小。 |
ZRANGE |
限制查詢使用的範圍大小。 | |
HGETALL |
HSCAN |
|
SMEMBERS |
SSCAN |
|
| 封鎖指令碼執行 | EVAL |
確認指令碼不會無限期執行。 |
EVALSHA |
確認指令碼不會無限期執行。 | |
| 移除檔案和連結 | DELETE |
UNLINK |
| 發布及訂閱 | PUBLISH |
SPUBLISH |
SUBSCRIBE |
SSUBSCRIBE |
調整門檻的最佳做法
縮放門檻情境可分為以下類別:
- 依記憶體使用率調度資源
- 根據 CPU 使用率調度資源
- 擴充以緩解熱點
如果工作負載需要剔除金鑰,Google 建議不要縮減 CPU 或記憶體使用率。在這類工作負載中,記憶體使用率通常會在自動淘汰前達到最大容量。記憶體用量因而激增,導致縮減作業無法執行。
以下各節將詳細說明常見情境和可能需要調整資源配置的指標門檻。
記憶體使用率調度
如要根據記憶體用量判斷何時應調整資源配置,請監控 /instance/memory/average_utilization 和 /instance/memory/maximum_utilization 指標。如要進一步瞭解這些指標,請參閱「支援的監控指標」。
如果執行個體符合下列任一條件,請考慮觸發水平擴展作業:
- 執行個體的平均記憶體使用率超過建議門檻 (70%)。
- 記憶體使用率最高超過 80%,平均超過 50%。
如果執行個體符合下列任一條件,建議您觸發縮減作業:
- 執行個體的平均記憶體使用率低於建議門檻 (50%)。
- 最高記憶體使用率降至 60% 以下,平均記憶體使用率降至 40% 以下。
CPU 使用率調度
如要根據 CPU 使用率判斷何時應調整資源配置,請監控 /instance/cpu/average_utilization 和 /instance/cpu/maximum_utilization 指標。
如果執行個體符合下列任一條件,請考慮觸發水平擴展作業:
- 執行個體的平均 CPU 使用率超過建議門檻 70%。
- CPU 使用率上限超過 80%,平均 CPU 使用率超過 50%。
如果執行個體符合下列任一條件,建議您觸發縮減作業:
- 執行個體的平均 CPU 使用率低於建議門檻 (50%)。
- 最高 CPU 使用率降至 60% 以下,平均 CPU 使用率降至 40% 以下。
擴充以緩解熱點
Memorystore for Valkey 會提供相同指標的平均值和最大值變化,您可以使用這些值找出該指標系列的熱點。最大值代表負載最重的執行個體節點,平均值則代表整個執行個體的負載。如果最大值明顯高於平均值,表示特定節點的負載過高 (熱點)。如要解決這個問題,建議您水平擴展執行個體。詳情請參閱「調整執行個體容量」。
如果發現平均值和最大值之間有顯著差異,可以對執行個體節點執行 INFO memory 和 INFO cpu 指令,直接從執行個體收集即時資料。如要進一步瞭解如何使用這些指令,請參閱 Valkey 說明文件中的 INFO。
Valkey 用戶端最佳做法
避免 Valkey 連線超載
為減輕連線突然大量湧入造成的影響,建議您採取下列做法:
決定最適合您的用戶端連線集區大小。建議每個用戶端一開始先為每個 Valkey 節點建立一個連線。接著,您可以進行基準測試,看看增加連線數量是否有幫助,同時不超過允許的連線數量上限。
如果用戶端因伺服器逾時而與伺服器中斷連線,請使用指數輪詢和抖動重試。這有助於避免多個用戶端同時對伺服器造成過載。
偵測及處理無回應的連線
強烈建議您設定用戶端應用程式,偵測 Memorystore for Valkey 連線是否沒有回應。偵測到無回應的連線時,用戶端必須重設連線。為建構彈性應用程式,建議您採用下列用戶端設定:
- 設定 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 秒後重設有未完成要求且無回應的連線。
已啟用叢集模式的執行個體
連線至 Memorystore for Valkey 叢集模式已啟用的執行個體時,應用程式必須使用支援叢集的 Valkey 用戶端。如需叢集感知用戶端和設定範例,請參閱「用戶端程式庫程式碼範例」。用戶端必須維護雜湊槽與執行個體中對應節點的對應關係,才能將要求傳送至正確的節點。這可避免重新導向造成的效能負擔。
用戶端對應
在下列情況下,用戶端必須取得完整的運算單元清單和對應節點:
用戶端初始化時,必須填入初始運算單元與節點的對應關係。
從伺服器收到
MOVED重新導向時,例如在容錯移轉時,前一個主要節點提供的所有槽位都由副本接管,或是在槽位從來源主要節點移至目標主要節點時重新分區。從伺服器收到
CLUSTERDOWN錯誤,或與特定伺服器的連線持續逾時。從伺服器收到
READONLY錯誤時。如果主要執行個體降級為副本,就可能發生這種情況。此外,用戶端應定期重新整理拓撲,以便為任何變更做好準備,並瞭解可能不會導致伺服器重新導向或錯誤的變更,例如新增副本節點。請注意,在拓撲重新整理期間,也應關閉所有過時連線,減少在指令執行階段處理失敗連線的需求。
用戶端探索
用戶端探索通常是透過向 Valkey 伺服器發出 SLOTS、NODES 或 CLUSTER SHARDS 指令來完成。建議使用 CLUSTER SHARDS 指令。CLUSTER SHARDS 會取代 SLOTS 指令 (已淘汰),提供更有效率且可擴充的執行個體表示法。
用戶端探索指令的回應大小,可能會因執行個體大小和拓撲而異。節點較多的大型執行個體會產生較大的回應。因此,請務必確保執行節點拓撲探索的用戶端數量不會無限增加。
這些節點拓撲重新整理作業在 Valkey 伺服器上會耗用大量資源,但對應用程式可用性也很重要。因此,請務必確保每個用戶端在任何指定時間只提出一項探索要求 (並將結果快取至記憶體),且提出要求的用戶端數量應保持在一定範圍內,以免伺服器超載。
舉例來說,當用戶端應用程式啟動或與伺服器中斷連線,且必須執行節點探索時,常見的錯誤是用戶端應用程式發出多個重新連線和探索要求,但未在重試時加入指數輪詢。這可能會導致 Valkey 伺服器長時間沒有回應,造成 CPU 使用率極高。
使用探索端點探索節點
使用 Memorystore for Valkey 探索端點執行節點探索。探索端點具備高可用性,且會在執行個體的所有節點之間進行負載平衡。此外,探索端點會嘗試將節點探索要求轉送至具有最新拓撲檢視畫面的節點。
已停用叢集模式的執行個體
應用程式連線至已停用叢集模式的執行個體時,必須連線至主要端點,才能寫入執行個體並擷取最新寫入內容。應用程式也可以連線至讀取器端點,從副本讀取資料,並隔離主要節點的流量。
已停用叢集模式的執行個體只有一個 shard,因此不會使用記憶體內拓撲。因此不適用拓撲重新整理。
在容錯移轉和維護事件期間,與執行個體的連線會中斷。為確保應用程式在這些事件後能成功重新連線,請實作指數輪詢重試機制。
對執行個體進行維護時,您可以使用「先建立再刪除」策略。如要進一步瞭解這項策略,請參閱「先建立再刪除的生命週期策略」。
如果使用這項策略,可能會收到下列錯誤訊息:
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 可享有下列安全性優勢:
- Identity and Access Management (IAM) 驗證:TLS 會使用這類驗證,防範伺服器詐騙攻擊,例如中間人攻擊。
- 傳輸中加密:Google Cloud的內建加密功能可在基礎架構層級保護 Google 網路內的流量。不過,這需要信任 Google 的主機和網路堆疊。雖然這項加密功能預設為啟用,且不會影響使用者體驗,但並非端對端加密。另一方面,TLS 則是在應用程式層使用傳輸中加密。這項端對端加密功能可讓您進一步控管加密金鑰和程序。
- 驗證權杖保護:如果您使用 IAM 驗證,啟用 TLS 可大幅降低驗證權杖外洩的風險。
效能影響
TLS 會以下列方式影響效能:
建立連線:已建立 TLS 工作階段的用戶端和伺服器可以繼續工作階段,不必重複在用戶端和伺服器之間建立連線的資源密集程序。啟用 TLS 恢復功能,可減少在用戶端和伺服器之間建立連線的負擔。
如果未建立 TLS 恢復功能,建立連線會耗用大量資源。無論是新連線還是現有連線,用戶端與伺服器之間的多個連線都可能導致連線逾時。這可能會造成雪球效應,因為 Memorystore for Valkey 會嘗試重新建立逾時的連線,進而增加建立連線時使用的資源。
加密及解密資料:資料加密和解密涉及 CPU 密集作業,會影響用戶端和伺服器。這可能會降低執行個體的容量,並增加執行個體的延遲時間。
建議
考慮是否啟用 TLS 時,建議您評估安全性政策,同時考量 TLS 的優缺點。如果選擇啟用 TLS,請注意下列事項:
- 啟用 TLS 恢復功能可減輕建立連線的負擔。只有在初始連線時,才需要用戶端和伺服器之間的連線。不過,如果用戶端執行個體大小突然擴大,可能會因為每個新用戶端主機的初始完整交握,而導致短暫中斷。
- 雖然部分用戶端程式庫可能未提供內建控制項來啟用 TLS,但您可以使用自訂程式碼將這項功能整合至執行個體。