本頁提供 App Engine Memcache 服務總覽。在處理某些工作時，高效能且可擴充的網路應用程式通常會優先使用記憶體內建的分散式資料快取，或是以此替代完善的永久儲存空間。為了滿足這項需求，App Engine 提供記憶體快取服務。如要瞭解如何設定、監控及使用 Memcache 服務，請參閱使用 Memcache 一文。
使用記憶體快取的時機
記憶體快取的用途之一為加快一般資料儲存庫的查詢速度。如果很多要求都使用同樣參數進行相同查詢，而且網站不需要立即顯示結果變更，應用程式就可以在 Memcache 中快取結果。如此一來，後續要求就可以先查看 Memcache，然後只有在找不到結果、或是暫存的結果因為逾期而消除的情況下，才去執行資料儲存庫查詢。工作階段資料、使用者偏好設定和其他網頁查詢傳回的資料都很適合使用快取。
用 Memcache 儲存其他暫存值可能很管用。但是，如果您只打算將值儲存在 Memcache，而不另於其他永久儲存空間備份；您就必須確保突然無法使用這些暫存值時，您的應用程式仍可保持正常運作。Memcache 中的值可能會隨時到期，也可能會在針對值所設的期限到達前就過期。舉例來說，如果使用者的工作階段會因為資料突然消失，變成運作不良，那麼資料除了存放在 Memcache，可能也應該儲存在資料儲存庫。
服務層級
App Engine 支援兩種層級的 Memcache 服務：
共用 Memcache 是 App Engine 應用程式預設的免費層級。這項服務會盡可能提供快取容量，並且依據採用該服務的所有 App Engine 應用程式的整體需求來做適當的調整。
專屬 Memcache 可提供應用程式專用的固定快取容量。這項服務按快取大小的 GB 時數收取費用，且必須啟用計費功能。能夠控管快取大小代表您的應用程式能以接近預期的方式運作，減少從費用較高的持久儲存空間中讀取資料的次數。
兩種 Memcache 服務層級都使用相同的 API。如要為您的應用程式設定 Memcache 服務，請參閱使用 Memcache 一文。
下表大致列出了兩種 Memcache 服務類別的差異：
| 功能 | 專屬 Memcache | 共用 Memcache |
|---|---|---|
| 價格 | 每 GB 每小時 $0.06 美元 | 免費 |
| 容量 |
|
不保證容量 |
| 成效 | 每秒每 GB 高達 1 萬次讀取或 5 千次寫入 (專用) (項目 < 1KB)。詳情請參閱快取統計資料。 | 不保證 |
| 持久可用的儲存空間 | 否 | 否 |
| 服務水準協議 | 無 | 無 |
專屬 Memcache 的計費方式是以每 15 分鐘為單位遞增。如果您使用美元以外的貨幣付費，則會按照 Cloud Platform SKU 頁面列出的相應貨幣價格計費。
如果您的應用程式需要更多 Memcache 容量，歡迎聯絡我們的銷售團隊。
限制
以下為 Memcache 服務的使用限制：
- 快取資料值的大小上限為 1 MiB (2^20 位元組) 減鍵值大小減實作所需空間，約為 73 位元組。
- 鍵大小不可超過 250 個位元組。在 Java 執行階段，物件或字串大小超過 250 個位元組的鍵會經過雜湊處理 (其他執行階段則有不同的行為)。
- 「多」批次作業可包含的元素數量不限。呼叫的總大小和擷取資料的總大小不可超過 32 MB。
- Memcache 鍵不可包含空位元組。
建議做法與最佳做法
使用 Memcache 時，建議您設計應用程式以便：
處理快取值無法隨時使用的情況。
- Memcache 不屬於耐久儲存空間。根據撤銷政策，系統會在快取填滿時撤銷鍵。變更快取設定或執行資料中心維護作業也可能會清除所有或部分的快取。
- Memcache 可能會暫時無法使用。Memcache 作業可能會因各種原因而失敗，包括變更快取設定或執行資料中心維護作業。應用程式在設計上應能掌控失敗的作業，而不是向使用者暴露這些錯誤。這項指引專門適用於 Set 作業。
盡可能使用 API 的批次處理功能。
- 這樣做可提高應用程式的效能與效率，特別是對於小型項目。
將負載分配至整個 Memcache 鍵空間。
以單一或一小組 Memcache 項目代表不成比例的流量，會妨礙應用程式的資源調度。這項指引適用於每秒作業數和頻寬。經常明確地分割資料，即可減緩這種問題。
例如，您可以將經常更新的計數器分割成數個鍵，在您需要總計時才讀回這些鍵並加總。同樣的，您可以將每個 HTTP 要求必須讀取的資料跨多個鍵分成 50 萬份，然後使用單一批次 API 呼叫將資料讀回。(更好的方法是快取執行個體記憶體中的值)。對專屬 Memcache 而言，單一鍵的尖峰存取率應該比每 GB 速率低 1-2 個級別。
保留自己的鍵，以便從快取中擷取值。
- Memcache 並未提供列出索引鍵的方法。由於快取的特性，如果不中斷快取，就無法列出鍵。此外，某些語言 (例如 Python) 會對長鍵進行雜湊運算，而應用程式只會知道原始鍵。
可用的 API
App Engine Memcache 支援兩種介面：低層級 Memcache API 與 JCache 規格。以下幾節提供關於每個介面的詳細資訊。
低層級 API
與 JCache 相比，低層級 Memcache API 支援的功能更多。相關例子包括：
- 自動增加及減少整數計數器值。
- 公開更多快取統計資料，例如存取近期最少用到的項目後經過的時間，以及快取中所有項目的總大小。
- 檢查並設定作業以根據條件儲存資料。
- 使用 AsyncMemcacheService，以非同步的方式執行 Memcache 作業。
低階 API 提供 MemcacheService 和 AsyncMemcacheService，可用於存取 Memcache 服務。這個 API 的功能比 JCache 提供的 API 豐富。
如要瞭解低層級 Memcache API 的同步與非同步使用範例，請參閱 Memcache 範例一文。
JCache
App Engine Java SDK 支援 JCache API。JCache 可為快取資料提供類似於地圖的介面。您可以使用鍵在快取中儲存及擷取值，鍵和值可以是任一種 Serializable 類型或類別。詳情請參閱使用 Memcache 一文。
不支援的 JCache 功能
JCache 不支援下列功能：
- JCache listener API 針對可在處理應用程式 API 呼叫期間執行的接聽程式 (例如
onPut和onRemove接聽程式) 提供部分支援，但不支援需要背景處理的事件監聽器 (例如onEvict)。 - 應用程式可以測試快取是否包含指定的鍵，但無法測試快取是否包含指定的值 (不支援
containsValue())。 - 應用程式無法傾印快取的鍵或值內容。
- 應用程式無法手動重設快取統計資料。
put()方法不會傳回鍵之前已知的值，而是一律傳回null。
快取資料的到期方式
Memcache 包含鍵/值組合。記憶體中的鍵/值組合會隨著寫入及擷取快取中的項目而隨時變更。
根據預設，Memcache 會盡可能一直保留本身儲存的資料值。如果有新值加入快取中，而快取記憶體不足時，系統就會撤銷快取中的值。因為記憶體壓力而必須撤銷值時，會先撤銷近期最少用到的值。
應用程式在儲存值時，可以提供值的到期時間。時間的表示方式可以是從加入值那時起的相對秒數，也可以是未來的絕對 Unix 紀元時間 (從 1970 年 1 月 1 日午夜開始的秒數)。系統最晚會在這個時間將值撤銷，但也可能會基於其他原因提早撤銷。逐步增加現有鍵中儲存的值並不會更新值的到期時間。
在極少數情況下，值也有可能會因為記憶體壓力以外的原因，在到期時間屆滿前從快取中消失。雖然 Memcache 對於伺服器故障有一定的承受能力，但因為 Memcache 值並非儲存在磁碟中，服務停擺還是可能導致值無法使用。
一般來說，您不應該預期應用程式能永遠使用快取值。
您可以透過 API 或 Google Cloud 主控台的 Memcache 專區清除應用程式的所有快取。
快取統計資料
依項目大小區分的每秒作業數
專屬 Memcache 以每秒每 GB 的作業數來計算速率，一項作業的定義為存取一次個別快取項目，例如 get、set 或 delete。作業速率會因項目大小而異，約略如下表所示。超過這些級別可能會提高 API 延遲時間或發生錯誤。
下表提供快取每 GB 持續且專屬的 get-hit 或 set 作業數上限。請注意，get-hit 作業代表 get 呼叫會尋找特定鍵儲存的值，並傳回該值。
| 項目大小 (KB) | 最高 get-hit 作業數/秒 |
最高 set 作業數/秒 |
|---|---|---|
| ≤1 | 10,000 | 5,000 |
| 100 | 2,000 | 1,000 |
| 512 | 500 | 250 |
如果應用程式的快取設定為多個 GB，理論上可達到的匯總作業率應為 GB 數乘以每 GB 速率。舉例來說，某個應用程式的快取設定為 5 GB，可在大小為 1 KB 項目上達到每秒 50,000 個 Memcache 作業。如要達到這個層級，必須將負載妥善分配至整個 Memcache 鍵空間。
上述限制的適用情況是，每個 IO 模式擇一執行讀取「或」寫入作業。如果同時執行讀取「及」寫入作業，相關限制就會浮動調整。執行讀取的作業愈多，可執行的寫入作業就會變少，反之亦然。以下示例列出 IOPS 在每 1 GB 的快取中同時讀取及寫入 1 KB 值的上限：
| 讀取 IOPS | 寫入 IOPS |
|---|---|
| 10000 | 0 |
| 8000 | 1000 |
| 5000 | 2500 |
| 1000 | 4500 |
| 0 | 5000 |
Memcache 運算單元 (MCU)
Memcache 總處理量的變更依據為您存取的項目大小，以及您想在項目上執行的作業。大致來說，費用與作業互相關聯，您可以使用名為「Memcache 運算單位 (MCU)」的單位，估計專屬 Memcache 可提供的預期流量。MCU 的定義為專屬 Memcache 每秒每 GB 預期可提供 10,000 個 MCU。 Google Cloud 控制台會顯示您的應用程式目前使用多少 MCU。
請注意，MCU 的統計資料為概略預估值，而且其並非線性單位。每項讀取或寫入值的快取作業都有相對應的 MCU 費用，視值的大小而定。set 的 MCU 費用取決於值的大小，是成功執行 get-hit 作業所花費用的 2 倍。
| 值項目大小 (KB) | get-hit 的 MCU 費用 |
set 的 MCU 費用 |
|---|---|---|
| ≤1 | 1.0 | 2.0 |
| 2 | 1.3 | 2.6 |
| 10 | 1.7 | 3.4 |
| 100 | 5.0 | 10.0 |
| 512 | 20.0 | 40.0 |
| 1024 | 50.0 | 100.0 |
不讀取或寫入值的作業有固定的 MCU 費用：
| 作業 | MCU |
|---|---|
get-miss |
1.0 |
delete |
2.0 |
increment |
2.0 |
flush |
100.0 |
stats |
100.0 |
請注意，get-miss 作業代表 get，找不到指定鍵儲存的值。
後續步驟
- 如要瞭解如何設定、監控及使用 Memcache，請參閱「使用 Memcache」一文。