Memcache 總覽

本頁提供 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 美元 免費
容量
us-central
1 至 100 GB
其他地區
1 至 20 GB
不保證容量
效能 每秒每 GB 高達 1 萬次讀取或 5 千次寫入 (專用) (項目 < 1KB)。詳情請參閱快取統計資料 不保證
持久可用的儲存空間
服務水準協議

專屬 Memcache 的計費方式是以每 15 分鐘為單位遞增。如果您使用美元以外的貨幣進行付款,系統將按照 Cloud Platform SKU 頁面上列出的相應貨幣價格來計費。

如果您的應用程式需要更多 Memcache 容量,歡迎聯絡我們的銷售團隊

限制

以下為 Memcache 服務的使用限制:

  • 快取資料值的大小上限為 1 MiB (2^20 位元組) 減鍵大小減實作所需空間,約為 73 位元組。
  • 鍵大小不可超過 250 個位元組。在 Java 執行階段,物件或字串大小超過 250 個位元組的鍵會經過雜湊處理 (其他執行階段則有不同的行為)。
  • 「多」批次作業可包含的元素數量不限。呼叫的總大小和擷取資料的總大小不可超過 32 MB。
  • Memcache 鍵不可包含空位元組。

可用的 API

App Engine Memcache 支援兩種介面:低層級 Memcache API 與 JCache 規格。以下幾節提供關於每個介面的詳細資訊。

低層級 API

與 JCache 相比,低層級 Memcache API 支援的功能更多。範例如下:

  • 自動增加及減少整數計數器值。
  • 公開更多的快取統計資料,例如存取近期最少用到的項目後經過的時間,以及快取中所有項目的總大小。
  • 檢查並設定作業以根據條件儲存資料。
  • 使用 AsyncMemcacheService,以非同步的方式執行 Memcache 作業。

低層級 API 針對存取 Memcache 服務提供 MemcacheServiceAsyncMemcacheService。這個 API 的功能比 JCache 提供的 API 豐富。

如要瞭解低層級 Memcache API 的同步與非同步使用範例,請參閱 Memcache 範例一文。

JCache

App Engine Java SDK 支援 JCache API。JCache 可為快取資料提供類似於地圖的介面。您可以使用鍵在快取中儲存及擷取值,鍵和值可以是任一種 Serializable 類型或類別。詳情請參閱使用 Memcache 一文。

不支援的 JCache 功能

JCache 不支援下列功能:

  • JCache listener API 針對可在處理應用程式 API 呼叫期間執行的接聽程式 (例如 onPutonRemove 接聽程式) 提供部分支援,但不支援需要背景處理的接聽程式 (例如 onEvict)。
  • 應用程式可以測試快取是否包含指定的鍵,但無法測試快取是否包含指定的值 (不支援 containsValue())。
  • 應用程式無法傾印快取的鍵或值內容。
  • 應用程式無法手動重設快取統計資料。
  • put() 方法不會傳回鍵之前已知的值,而是一律傳回 null

快取資料的到期方式

Memcache 包含鍵/值組合。記憶體中的鍵/值組合會隨著寫入及擷取快取中的項目而隨時變更。

根據預設,Memcache 會盡可能一直保留本身儲存的資料值。如果有新值加入快取中,而快取記憶體不足時,系統就會撤銷快取中的值。因為記憶體壓力而必須撤銷值時,會先撤銷近期最少用到的值。

應用程式在儲存值時能提供值的到期時間,方式包含使用秒數 (相對於加入值的時間),或是使用未來的絕對 Unix 紀元時間 (從 1970 年 1 月 1 日午夜開始的秒數)。系統最晚會在這個時間將值撤銷,但也可能會基於其他原因提早撤銷。逐步增加現有鍵中儲存的值並不會更新值的到期時間。

在極少數情況下,值也有可能會因為記憶體壓力以外的原因,在到期時間屆滿前從快取中消失。雖然 Memcache 對於伺服器故障情況具有較大的反應彈性,但 Memcache 值不會儲存在磁碟中,因此服務停擺會導致值無法使用。

一般來說,您不應該預期應用程式能永遠使用快取值。

您可以透過 API 或 Google Cloud Platform 主控台的 Memcache 專區清除應用程式的所有快取。

快取統計資料

依項目大小區分的每秒作業數

專屬 Memcache 以每秒每 GB 的作業數來計算速率,一項作業的定義為存取一次個別快取項目,例如 getsetdelete。作業速率會因項目大小而異,如下表所示。超過這些級別可能會提高 API 延遲時間或發生錯誤。

下表提供快取每 GB 持續且專屬的 get-hitset 作業數上限。請注意,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 鍵空間,如 App Engine 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 Platform 主控台會顯示您的應用程式目前使用多少 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 API 作業失敗的狀況。 Memcache 作業可能會因各種原因而失敗。應用程式在設計上應能掌控失敗的作業,而不是向使用者暴露這些錯誤。這項指引專門適用於 Set 作業。

  • 盡可能使用 API 的批次處理功能,特別是對於小型項目。這樣做可提高應用程式的效能與效率。

  • 將負載分配至整個 Memcache 鍵空間。 以單一或一小組 Memcache 項目代表不成比例的流量,會妨礙應用程式的資源調度。這項指引適用於每秒作業數和頻寬。經常明確地分割資料,即可減緩這種問題。

    例如,您可以將經常更新的計數器分割成數個鍵,在您需要總計時才讀回這些鍵並加總。同樣的,您可以將每個 HTTP 要求必須讀取的資料跨多個鍵分成 50 萬份,然後使用單一批次 API 呼叫將資料讀回。(更好的方法是快取執行個體記憶體中的值)。對專屬 Memcache 而言,單一鍵的尖峰存取率應該比每 GB 速率低 1-2 個級別。

如需深入瞭解並行、效能及遷移的詳細資訊和最佳做法,包括在不同程式設計語言間共用 Memcache,請參閱 App Engine Memcache 最佳做法一文。

後續步驟

  • 如要瞭解如何設定、監控及使用 Memcache,請參閱使用 Memcache 一文。
本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Java 適用的 App Engine 標準環境