使用 Memorystore 進行快取

GCP Memorystore 簡介

在 Professional Cloud Developer（PCD） 考試中，只要情境提到次毫秒級延遲、熱門鍵把 Cloud SQL 壓垮、無狀態 Cloud Run 需要 session 儲存、或多個 GKE Pod 之間要共用計數器做限流，答案幾乎都是 Memorystore。Google Cloud 目前共有三種 Memorystore 引擎，考試務必區分：

• Memorystore for Redis — 最早的代管版本，目前支援 Redis 7.2、7.0、6.x、5.0、4.0、3.2，分 Basic（單節點）與 Standard（1 個副本，具 HA）兩種層級。單一實例最大為 300 GB。
• Memorystore for Memcached — 代管 Memcached 1.5/1.6，多節點、多執行緒，無持久化、單節點無 HA，適合純粹的高吞吐量快取。
• Memorystore for Valkey — Google 新推出的代管 Valkey 7.2（Redis 改授權後的開源分支），預設啟用 Cluster Mode，每個分片皆具高可用。

白話文解釋（Plain English Explanation）

快取的差別在於：每次有人問冷知識就翻 500 頁的工具書，與在螢幕邊貼一張寫著前 20 名答案的便利貼。

類比 1 — 餐廳的出餐窗口

你的資料庫（Cloud SQL、Firestore、Spanner）是廚房後方的大型冷藏庫，廚師每跑一趟都要走 30 秒。Memorystore for Redis 就是廚房與洗碗區之間的出餐窗口 — 廚師會把最常用的食材（熱門使用者資料、商品價格、session token）放在這個窗口上。下次有人需要時，只要 0.5 ms 拿到，而不必再走 50 ms 進冷藏庫。當窗口擺滿時，最久沒用到的會被丟掉（allkeys-lru）以騰出空間。

類比 2 — 高速公路的 EZ-Pass 車道

Memorystore for Memcached 像是收費站的 EZ-Pass 車道。沒有花俏的資料結構、沒有持久化、沒有交易紀錄 — 只有一張車牌與餘額對照表。多條車道（多節點，多執行緒）平行運作，一小時可放行上百萬輛車而完全不塞車。但只要收費站斷電，整張表就消失了 — 這沒關係，因為真正的紀錄保存在監理所，不在收費站。

類比 3 — 熱水桶 vs. 即熱式熱水器

Basic Tier 的 Redis 像家裡地下室的一只熱水桶。如果半夜兩點爆掉，要等師傅到府才能恢復熱水。Standard Tier 則是主備兩只熱水桶 — 主桶故障時，副桶數十秒內就接手，洗澡水不會變冷。Valkey Cluster Mode 就是每間浴室都裝一台即熱式熱水器 — 每間（每個 shard）獨立加熱，其中一台壞了，樓下備援機立刻補上同一間的供應。

Memorystore for Redis — Basic 與 Standard Tier 比較

層級是 Redis 上最關鍵的考點。

Basic Tier 特性

• 單節點，沒有副本，不會自動容錯移轉。
• 容量範圍 1 GB 至 300 GB。
• 升級或維護時快取會被清空，實例短暫不可用。
• 價格最便宜，適合非關鍵快取、開發測試、或能容忍冷啟動從主資料庫重建的工作負載。

Standard Tier 特性

• 一個主節點加上位於同區不同可用區的一個副本。
• 當主節點不健康時於數十秒內自動容錯移轉。
• 容量 5 GB 以上時可啟用讀取副本（最多 5 個讀取副本），提供獨立的讀取端點以擴充讀取吞吐量。
• 支援維護時間窗，讓容錯移轉發生於可預期的時段。

如何選擇

正式環境一律以 Standard Tier 為預設。成本約為兩倍記憶體價格，但 SLA 從 Basic 的「無承諾」拉到 99.9%。考試中只要是「客戶端 Cloud Run 應用的 session 儲存」這類情境，答案必然是 Standard Tier，因為 session 遺失等同被登出。

Memorystore for Memcached 深度剖析

Memorystore for Memcached 是大規模純鍵值快取的主力。

架構與容量

• 一個實例由1 至 20 個節點組成。
• 每個節點可配置 1 GB 至 256 GB 記憶體、1 至 32 vCPU，靠加節點水平擴充。
• 單一實例最大記憶體為 5 TB（20 節點 × 256 GB）。
• 客戶端透過 Auto Discovery 協定（連接埠 11211）取得節點列表，再以一致性雜湊把鍵分散到各節點。

與 Redis 的取捨

• 無持久化 — Memcached 純記憶體，節點重啟即清空。
• 無副本 — 失去節點等於失去該節點所負責的鍵。
• 無進階資料結構 — 只有字串。沒有 list、set、sorted set、stream，也沒有 Pub/Sub。
• 單節點多執行緒 — Memcached 能用滿所有 vCPU，而 Redis 單節點的指令執行基本上是單執行緒。

考試上挑 Memcached 的情境

• 讀多寫少的查詢結果快取。
• session 快取，且 session 丟失可接受。
• 強調「線性水平擴充」與「不需要資料結構」的情境。

Memorystore for Valkey — 新的預設選擇

2024 年 Redis 改授權後，Linux Foundation 將引擎分支為 Valkey。Google 把 Memorystore for Valkey 納入產品線時做了一些刻意與舊版 Redis 服務不同的設計。

引擎與拓樸

• 上線時只支援 Valkey 7.2。
• 永遠啟用 Cluster Mode：每個實例由 1 至 250 個分片組成，每分片含一個主節點加 0、1 或 2 個副本。
• 實例總記憶體上限可達 14.5 TiB。
• 原生跨可用區 HA — 副本永遠位於與主節點不同的可用區。

何時選 Valkey 而非 Redis

• 需要超過 300 GB（這是 Redis 服務的上限）。
• 想一開始就有 Cluster Mode，又不想動用 Redis Enterprise 自己管理拓樸。
• 想留在 OSI 認可的開源授權分支上 — Valkey 採 BSD-3，而 Redis 7.4 之後改用 RSALv2/SSPL。

遷移注意事項

• 多數 Redis 客戶端（go-redis、redis-py、jedis、ioredis、lettuce）能直接接 Valkey 的 wire protocol。
• Lua 腳本與 MULTI/EXEC 交易行為一致。
• Redis Stack 模組（RediSearch、RedisJSON）並未內建於 Memorystore for Valkey — 情境若提到 JSON 搜尋，多半是指向自架或 Redis Enterprise 移轉。

容錯移轉行為與 SLA

Redis Standard Tier 的容錯移轉

當主節點不健康時，Memorystore 會把另一個可用區的副本拉升為主節點。官方目標是 60 秒以內完成容錯移轉，實務上常見 15–30 秒。端點 IP 與連接埠不變，客戶端只會看到一次連線重置。

讀取副本的容錯移轉

Standard Tier 開啟讀取副本後，讀取端點會以區域層級的 DNS round-robin 分散連線。若其中一個副本故障，流量會在數秒內排空到其他健康副本，主端點不受影響。

Valkey 分片容錯移轉

Valkey 每個分片獨立進行容錯移轉。分片 7 的主節點故障時，只會把分片 7 的副本拉升，完全不影響分片 1–6 或 8–250。支援 Cluster 的客戶端會透過 MOVED 與 ASK 回應自動處理重新導向。

RDB 與 AOF 持久化

雖然 Memorystore 首要任務是快取，但 Redis 與 Valkey 引擎支援兩種持久化模式可在完全重啟後重建狀態。

RDB 快照

• RDB 是把某一時間點的二進位快照寫入 Google 代管的 Cloud Storage Bucket。
• 快照間隔可設為 1 小時、6 小時、12 小時或 24 小時。
• 快照採壓縮，並以 Google 代管金鑰靜態加密（支援的層級可使用 CMEK）。
• 完全重啟或兩個節點同時失效時，Memorystore 會從最近一份 RDB 還原 — 也就是說最多會遺失一個快照間隔的寫入。

AOF（Append-Only File）

• AOF 由 Memorystore for Valkey 支援（部分 Redis Cluster 設定亦可），將每個指令寫入只追加的紀錄檔。
• 同步策略沿用上游 Redis：always（每個指令）、everysec（每秒，預設）、no（交由 OS 決定）。
• AOF 能把 RPO 壓到一秒內，代價是寫入放大。

如何選

把持久化當成快取暖啟動的保險，不要當成主資料庫。即使 AOF 設為 always，真正的紀錄仍應落在 Cloud SQL、Firestore 或 Spanner。考試中持久化的正確情境是「降低區域重啟後的冷啟動時間」，不是「儲存使用者關鍵資料」。

記憶體管理與汰換政策

當 Memorystore 實例達到 maxmemory 限制時，Redis 會依汰換政策騰出空間。

考試應掌握的政策

• noeviction — 滿了就直接回傳錯誤，永不靜默丟鍵時使用。
• allkeys-lru — 從整個鍵空間中淘汰最近最少使用的鍵。通用快取最常見的選擇。
• allkeys-lfu — 淘汰最不常使用的鍵，適合「某些鍵很熱但少被重存取」的工作負載。
• volatile-lru — 只淘汰有設定 TTL 的鍵中最近最少使用者，沒有 EXPIRE 的鍵會被保護。
• volatile-lfu — 同上但用 LFU 統計。
• volatile-ttl — 優先淘汰剩餘 TTL 最短的鍵。
• allkeys-random / volatile-random — 隨機挑選，主要用於壓測。

設定方式

在建立或更新實例時透過 maxmemory-policy 參數設定：

gcloud redis instances update my-cache \
  --region=us-central1 \
  --update-redis-config maxmemory-policy=allkeys-lru

預設值與陷阱

Memorystore for Redis 預設為 volatile-lru。若你的應用程式從不設 TTL，volatile-lru 等於 noeviction，記憶體滿了之後寫入就會開始失敗。解法是程式碼設預設 TTL，或改成 allkeys-lru。

讀取副本與 Cluster Mode

讀取副本（Redis Standard Tier）

• 容量 5 GB 以上的實例最多可開 5 個讀取副本。
• 每個副本以非同步方式跟隨主節點。
• 另有獨立的讀取端點（區域層級的負載平衡 DNS 名稱）分散連線到所有副本。
• 讀取可能是過期幾毫秒的資料 — 寫入後立即讀取的流程絕對不要用讀取端點。

Cluster Mode

• Memorystore for Redis Cluster 與 Memorystore for Valkey 都提供真正的 Cluster Mode。
• 以雜湊槽（0–16383，標準 Redis 演算法）把鍵空間切分到多個分片。
• 客戶端必須支援 Cluster Mode（驅動設定 cluster-enabled: true）才能處理 MOVED 與 ASK 重新導向。
• 跨分片的多鍵操作需要使用 hash tag — 鍵用 {tag} 包住會雜湊到同一槽。沒有 hash tag 時，MGET user:1 user:2 可能跨分片而失敗。

擴充方式

• 垂直擴充 — 更換實例大小以加記憶體。
• 水平擴充 — Redis Cluster 與 Valkey 可以線上加分片，不必清空快取。
• 讀取副本只擴充讀取吞吐量，不會增加寫入吞吐量。

資安 — AUTH、傳輸中加密、IAM

AUTH

• AUTH 是 Redis 的密碼機制。實例啟用 AUTH 時 Memorystore 會產生 128 字元的隨機 token。
• 透過下列指令取得密碼：

gcloud redis instances get-auth-string my-cache --region=us-central1

• 客戶端連線後立即送出 AUTH <password>。

傳輸中加密（TLS）

• Memorystore for Redis 與 Valkey 提供伺服器端驗證的 TLS。
• 伺服器憑證由 Memorystore 自簽 CA 發出 — 透過 gcloud redis instances describe 下載並 pin 在客戶端 TLS 設定中。
• Memcached 在 Memorystore 並不支援 TLS，只能靠 VPC 層級的控制做隔離。

靜態加密

• 所有 RDB 與 AOF 製品預設以 Google 代管金鑰靜態加密。
• 在 Redis Standard Tier 與 Memorystore for Valkey 上可使用 CMEK（透過 Cloud KMS 的客戶代管金鑰）。

IAM

• Memorystore 的 IAM 控制的是實例管理（建立、刪除、設定）— 角色如 roles/redis.admin、roles/redis.editor、roles/redis.viewer。
• 資料平面存取（GET/SET 指令）不走 IAM，而是靠 AUTH 與網路控制。

Private Services Access 與 VPC 連線

Memorystore 實例一律使用私有 IP，沒有公有端點。

Private Services Access（PSA）

• Memorystore for Redis 與 Valkey Cluster 會從你在 VPC 中保留的 Private Services Access 區段配發 IP。
• 每個 VPC 只需設定 PSA 一次：

gcloud compute addresses create google-managed-services-default \
  --global --purpose=VPC_PEERING --prefix-length=16 \
  --network=default

gcloud services vpc-peerings connect \
  --service=servicenetworking.googleapis.com \
  --ranges=google-managed-services-default --network=default

• 設定完之後，該 VPC 內所有 Memorystore 實例都會從保留區段配發 IP。

從 Cloud Run 連線

• Cloud Run 跑在 Google 代管的租戶網路，不在你的 VPC 中。
• 從 Cloud Run 連到 Memorystore 必須掛 Serverless VPC Access Connector（第二代 Cloud Run 亦可使用 Direct VPC Egress）。
• Egress 設為 all-traffic 會讓所有出站流量走你的 VPC；設為 private-ranges-only 即足以連到 Memorystore，因為其 IP 屬於 RFC1918。

從 GKE 連線

• 區域型 GKE 叢集本來就在 VPC 內，Pod 可直接透過節點主 IP 連線到 Memorystore。
• 請使用 VPC-native（alias IP）叢集；舊版路由式叢集會撞到 MTU 與路由數量限制。
• 多叢集環境下，請確認所有叢集都對同一個 Memorystore PSA 區段做 peering，或把實例放在 Private Service Connect 端點之後做每叢集隔離。

從地端連線

• 地端連線到 Memorystore 只能透過 Cloud VPN 或 Cloud Interconnect，並設定自訂路由通告將 PSA 區段加入通告範圍。

常見快取模式

PCD 考試會考三種經典快取模式，有時直接點名，有時靠行為描述。

Cache-aside（lazy loading）

1. 應用程式先讀 Memorystore。
2. Miss 時改讀主資料庫（Cloud SQL、Firestore）。
3. 將值寫回 Memorystore 並設定 TTL。
4. 主資料庫被寫入時，可選擇作廢對應的快取鍵。

這是 Cloud Run 與 GKE 上最常見的預設方案，因為快取用到才填，能撐住完整快取被清空的情境 — 最糟情況只是冷啟動延遲一陣，不會資料遺失。

Write-through

1. 應用程式寫入 Memorystore。
2. Memorystore（或 app 包裝層）同步寫入資料庫。
3. 讀取永遠先打 Memorystore。

優點：快取永遠暖且與資料庫一致。缺點：寫入延遲是快取加資料庫的總和，Memorystore 故障時連寫入也斷。

Write-behind（write-back）

1. 應用程式只寫 Memorystore。
2. 背景 worker（Cloud Functions、Cloud Run job、或 in-app goroutine）非同步把寫入刷回資料庫。

優點：寫入延遲最低。缺點：Memorystore 在刷回前掉資料就遺失寫入 — 僅當資料可重建或遺失預算寬鬆時可接受。

考試中的選擇邏輯

• 「讀多寫少的商品型錄，偶有更新」→ 帶 TTL 的 cache-aside。
• 「快取與資料庫的強一致性是關鍵」→ write-through。
• 「突發性寫入工作負載，可接受最終一致性」→ write-behind，常以 Pub/Sub 作為快取與資料庫之間的耐久佇列。

維運面 — 監控、維護、成本

監控

Memorystore 會把指標送到 Cloud Monitoring，前綴為 redis.googleapis.com/ 與 memcache.googleapis.com/。重要指標：

• redis.googleapis.com/stats/memory/usage_ratio — 目前使用量相對 maxmemory 的比例。
• redis.googleapis.com/stats/cpu_utilization — Redis 引擎單核心的使用率。
• redis.googleapis.com/clients/connected — 總連線數，預設上限為 65,000。
• redis.googleapis.com/keyspace/hits 與 keyspace/misses — 用以計算命中率。

建議在 記憶體使用率 80% 與 CPU 75% 觸發警示，以免 CPU 被淘汰邏輯吃光。

維護時間窗

每個 Standard Tier 與 Valkey 實例都有一小時的每週維護時間窗，Google 會在該時段做修補。可選擇星期幾與小時。維護期間先修補副本，再用受控容錯移轉修補主節點。

成本最佳化

• 以工作集而非整體資料量訂容量。若 5 GB 的熱門鍵能服務 99% 請求，5 GB Standard 優於 50 GB Basic。
• 讀取吞吐瓶頸時應加讀取副本，而不是把主節點記憶體加倍。
• 純鍵值高 RPS 情境下，Memcached 按節點計費的方式比 Redis Standard Tier 便宜。

常見問題（FAQs）

Q1：什麼時候該選 Memorystore for Valkey 而不是 Memorystore for Redis？

A1：當總記憶體需求超過 300 GB、需要從第一天就跑 Cluster Mode、或想留在 BSD-3 授權分支時，就選 Valkey。Valkey 7.2 與多數 Redis 客戶端 wire 相容，移轉多半只是改連線字串。

Q2：Memorystore 支援客戶端 TLS 嗎？

A2：是，Memorystore for Redis 與 Memorystore for Valkey 都支援伺服器端驗證的 TLS。建立實例時啟用，再以 gcloud redis instances describe 下載伺服器 CA 並 pin 在客戶端。Memorystore 上的 Memcached 不支援 TLS，請改在 VPC 層做防護。

Q3：如何從 Cloud Run 連線到 Memorystore？

A3：Cloud Run 無法直接連到私有 IP。請加掛 Serverless VPC Access Connector（或在第二代 Cloud Run 上使用 Direct VPC Egress），並把連接器的子網路指向 Memorystore 所在的 VPC，Cloud Run 服務就能透過連接器連到 Memorystore 端點。

Q4：預設汰換政策是什麼？為何重要？

A4：Memorystore for Redis 預設為 volatile-lru，只會淘汰設過 TTL 的鍵。若程式碼從不設 TTL，記憶體用滿後寫入會以「OOM command not allowed when used memory > 'maxmemory'」失敗。解法是以 EXPIRE 為鍵設 TTL，或把政策改成 allkeys-lru。

Q5：能不能把 Memorystore 當訊息中介？

A5：Redis Pub/Sub 在 Memorystore 上能跑，但是最多一次送達且無持久化 — 訂閱端斷線期間的訊息全部遺失。需要耐久訊息一律使用 Google Cloud Pub/Sub。Redis Pub/Sub 只適合短暫的扇出訊號（快取失效、即時在線狀態）。

Q6：Memorystore 單一實例最大可開多大？

A6：Memorystore for Redis 上限為 300 GB。Memorystore for Memcached 單一實例上限 5 TB（20 節點 × 256 GB）。Memorystore for Valkey 透過 Cluster Mode 可達 14.5 TiB（最多 250 個分片）。

Q7：Memorystore 會幫我備份資料嗎？

A7：Memorystore for Redis 與 Valkey 支援 RDB 快照，間隔可選 1、6、12 或 24 小時，存放於 Google 代管的 Cloud Storage；Valkey 另外支援 AOF 持久化。Memcached 沒有持久化，節點重啟即清空。