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 MB (10^6 個位元組)。
  • 鍵大小不可超過 250 個位元組。在 Python 執行階段,字串大小超過 250 個位元組的鍵將經過雜湊處理 (其他執行階段則有不同的行為)。
  • 「多」批次作業可包含的元素數量不限。呼叫的總大小和擷取資料的總大小不可超過 32 MB。
  • Memcache 鍵不可包含空字元。

快取資料的到期方式

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

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

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

在極少數情況下,值也有可能會因為記憶體壓力以外的原因,在到期時間屆滿前從快取中消失。雖然 Memcache 對於伺服器故障有一定的承受能力,但因為 Memcache 值並非儲存在磁碟中,服務停擺還是可能導致值無法使用。

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

您可以透過 API 或 Google Cloud Platform Console 的 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 Console 會顯示您的應用程式目前使用多少 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 鍵值可能會接收其他並行寫入要求,您必須使用 Memcache Client 物件,其中儲存了支援比較與設定功能的方式所使用的特定狀態資訊。由於 Memcache 函式 get()set() 無狀態,因此無法使用。由於 Client 類別本身並非安全執行緒,因此您也不可在一個以上的執行緒中使用相同的 Client 物件。

擷取索引鍵時,您必須使用支援比較與設定功能的 Memcache Client 方式:gets()get_multi(),並將 for_cas 參數設為 True

更新索引鍵時,您必須使用支援比較與設定功能的 Memcache Client 方式:cas()cas_multi()

其他重要邏輯元件為 App Engine Memcache 服務及其在比較與設定方面的行為。App Engine Memcache 服務是以原子操作方式執行。也就是說,當兩個並行要求 (針對相同的應用程式 ID) 使用 Memcache 時,它們會前往同一個 Memcache 服務執行個體,而 Memcache 服務具有足夠的內部鎖定,因此相同索引鍵的並行要求會正確序列化。具體而言,這表示相同索引鍵的兩個 cas() 要求實際上不會並行執行,服務會先將進來的第一個要求處理完成 (亦即,更新值和時間戳記) 後,再開始處理第二個要求。

如要瞭解如何在 Python 中使用比較與設定功能,請參閱處理並行寫入

最佳做法

以下提供一些使用 Memcache 的最佳做法:

  • 不要讓使用者看到 Memcache API 作業失敗的狀況。 Memcache 作業可能會因各種原因而失敗。應用程式在設計上應能掌控失敗的作業,而不是向使用者暴露這些錯誤。這項指引專門適用於 Set 作業。

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

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

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

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

後續步驟

本頁內容對您是否有任何幫助?請提供意見:

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

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