什麼是快取？

快取是將索引鍵/值資料儲存在暫存記憶體中的做法 (例如非關聯式結構化查詢語言 NoSQL 資料庫)，讓應用程式可以比從傳統儲存體更快擷取資料。在 雲端儲存空間結構中，要求通常會跨越網路並存取共用服務，而快取可以協助縮短回應時間，並減少重複工作。

大多數系統會保留完整資料集的長期「事實來源」(也稱為資料庫)，再為常讀取的暫時性子集保留快取。當要求進來時，應用程式會先檢查快取；如果資料在快取中，就會直接快速回傳，而不會再次查詢後端。開發人員也會快取已處理的資料，並重複使用它來比標準查詢更快地回應要求，這些查詢可能來自關聯式資料庫、SQL 資料庫，或開放原始碼 PostgreSQL 資料庫。

1. 將經常讀取的資料放入快取

適合快取的資料包括經常重複讀取且變更不頻繁的資料，例如產品和價格資訊，或是建置成本高的共用靜態資源。

2. 將重複工作的結果放入快取

如果某項作業會轉換資料或執行複雜計算，快取結果可以避免重複計算後續要求。

3. 必要時使用快取層

開發人員會使用多層快取 (「快取層」)，根據需求將不同類型的資料儲存在不同的快取中。新增一個或多個快取層可以改善資料層的輸送量與延遲。

4. 將工作階段狀態保留在接近應用程式的位置，提升應用程式回應速度

記憶體內部存放區常用來短時間保存大量工作階段資料，例如使用者輸入、購物車項目或個人化喜好設定。對於具狀態應用程式，團隊也會將工作階段狀態儲存在快取中，讓應用程式可以保持無狀態。

快取可以透過幾種具體方式提升效能：

• 從記憶體內部快取讀取資料，比從磁碟型存放區存取資料更快。
• 較少的查詢可以減少負載，並降低擴充資料庫基礎結構的需求，進而也能降低成本。
• 快取層可以改善輸送量與延遲，而記憶體內部快取可以在使用量暴增時協助緩解延遲。
• 快取執行個體每秒可以處理數百萬個要求，提供許多資料庫無法比擬的輸送量。

在許多雲端設計中，快取會存放在主要資料存放區 (例如資料庫) 旁邊。主要存放區會在雲端伺服器上保留完整、長期的資料集，而快取則會保留較小、可快速讀取的暫時性子集。

常見的設定是獨立的快取層，或是位於應用程式層或資料庫層中的快取，根據您需要快速讀取的位置來選擇。

有些系統會使用多層快取 (「快取層」)，讓不同類型的資料依需求存在不同的快取中。新增一個或多個快取層可以改善資料層的輸送量與延遲，並透過降低後端負載來減少整體成本。

團隊通常會快取以下幾種類型的資料：

• 經常讀取的資料 (尤其是變更不頻繁的資料)，例如產品或價格資訊，以及建置成本高的共用靜態資源。
• 重複運算，即作業需轉換資料或執行複雜計算，這時快取結果可以避免在以後的要求中再次執行相同的工作。
• 工作階段狀態，適用於具狀態應用程式；將工作階段狀態儲存在快取中有助於讓應用程式層保持無狀態。

應用程式讀取和寫入快取有幾種標準方法。以下是最常見的模式，以及它們在實務上的意義。

• 另行快取：依需求從資料存放區載入資料。
• 直接讀取：從快取讀取，如果需要，快取會從資料存放區擷取資料。
• 直接寫入：寫入快取，然後同步與資料存放區重新同步。
• 回寫 (事後寫入)：寫入快取，然後分批寫回資料存放區。
• 繞過寫入：寫入資料存放區並從快取讀取；快取會依需求更新。

使用快取層可改善輸送量與延遲，因為它會直接從快取服務常見要求，而不是反覆查詢後端存放區。這樣可降低擴充資料庫基礎結構的需求，因為一開始到達資料庫的要求就比較少。

對於使用量會暴增的應用程式，記憶體內部快取可將經常要求的資料保留在更接近使用所在位置，進而降低延遲。

在選擇工作流程時，請先參考以下做法：

• 如果應用程式可以決定儲存內容，以及重新整理時間，請優先使用另行快取。
• 如果您希望快取在需要時從資料存放區擷取資料，請優先使用直接讀取。
• 如果寫入行為很重要，而且您想要明確的重新同步方法，請考慮直接寫入或回寫。

快取可提升應用程式效能，因為從記憶體內部快取讀取資料比從磁碟型資料存放區讀取更快。當快取服務更多要求時，系統傳送至後端的查詢就會變少，這可降低擴充資料庫基礎結構的需求，並減少相關成本。

您通常能從快取獲得的好處

• 因為經常要求的資料來自更快的層，所以常見讀取的延遲會降低。
• 因為快取可減少資料庫查詢，並降低過度佈建資料庫執行個體的壓力，所以資料庫負載與成本會降低。
• 因為與許多資料庫相比，快取可處理非常高的要求量，所以更容易預測輸送量。
• 在高輸送量期間，記憶體內部快取能降低延遲，因此可以更平順地應對流量尖峰。

快取有助於減少重複工作。重複讀取或建立成本較高的資料，可以只儲存一次並重複使用。如果某個作業會執行複雜計算或轉換資料，快取結果可減少後續要求的重複計算。

常見「適合快取」的候選資料類型

• 變更不頻繁的資料 (例如產品與價格資訊)。
• 建立成本很高的共用靜態資源。
• 會重複計算的作業結果。

網站：更快的頁面載入與更少的往返次數

許多網站會快取頁面輸出 (例如 HTML 和用戶端指令碼)，讓伺服器不必每次都重新執行頁面程式碼，而是直接回傳快取的輸出。快取也可透過 Web 快取與網路快取支援 Web 多媒體案例，例如內容傳遞網路 (CDN)。

網站上的一般用途

• 快取完整頁面輸出，以供重複檢視。
• 透過網路/CDN 快取來快取靜態資產。

應用程式和 API：更快讀取共用資料

應用程式通常會在快取中儲存暫時性的子集，以便快速擷取，而主要資料庫則會保留完整的長期資料集。將已處理的資料進行快取並重複使用，可以比標準的資料庫查詢更快地回應要求。

常見的應用程式模式

• 快取經常讀取的參考資料 (例如價格)，以減少重複呼叫資料庫。
• 快取計算結果，以避免重複執行昂貴的工作。

伺服器與服務：擴展讀取能力並緩解流量尖峰

團隊通常會新增一或多個快取層，以改善輸送量與延遲，從快取服務常見查詢，並降低資料庫負載。當使用量暴增且輸送量需求提高時，記憶體內部快取可以幫助緩解這些時期的延遲。

這是最有幫助的地方

• 高讀取量端點，其中經常要求相同的金鑰。
• 會出現週期性流量高峰的系統。

商務系統：工作階段狀態與共用作業資料

快取常用來將大量短期存在的工作階段資料 (例如使用者輸入或個人化喜好設定) 儲存在記憶體內部存放區中。有些團隊也會將工作階段狀態儲存在快取中，讓具狀態應用程式可讓應用程式層保持無狀態。對於作業系統來說，變更不頻繁的資料 (例如產品與價格資訊) 是常見的快取目標。

可對應到商務工作負載的範例

• Web 與行動裝置應用程式的工作階段資料 (短期存在、大量)。
• 經常讀取的作業參考資料 (價格、共用資源)。

瀏覽器快取會在使用者裝置上儲存靜態資源的複本，因此再次造訪時可重複使用這些檔案，而不必重新下載。

常見使用案例

• 靜態網站資產，例如影像、CSS 檔案和 JavaScript 檔案。
• 減少就之前擷取過的資源向來源伺服器重複要求。

伺服器端快取會在遠端執行商務服務的流程進行，而不是在使用者的裝置上。伺服器端快取通常分為私人 (僅供單一應用程式執行個體使用) 或共用 (供多個應用程式執行個體使用)。

常見使用案例

• 單一流程內的私人記憶體內部快取，可儲存少量靜態資料。
• 共用快取服務，可讓多個應用程式執行個體讀取相同的快取值，並避免各執行個體出現「不同版本」的情況。
• 經常讀取但很少修改的資料 (例如產品與價格參考資料)。

CDN 會在更接近使用者的邊緣伺服器上快取內容，因此要求不一定都要回到來源。不同於瀏覽器快取 (單一使用者)，CDN 快取是共用的，因此一位使用者的要求會先填入內容，之後另一位使用者則可接收內容。

常見使用案例

• 從邊緣位置共用可快取內容的傳遞，以減少對來源的要求。
• 靜態資源，因為靠近使用者而受益 (與瀏覽器快取的資產類似，但可在使用者之間共用)。

快取不只是一種雲端運算模式，硬體和記憶體層也會使用它。

CPU 快取是一種位於處理器附近 (或處理器上的)小型快速記憶體區域，可儲存常用資料與指示的複本，以減少等待主記憶體的時間。

記憶體 (記憶體內部) 快取是最簡單的軟體快取類型：它是位於單一流程位址空間中的記憶體內部存放區，並由該流程直接存取。

常見使用案例

• CPU 快取：重複存取相同的指示/資料，而不必頻繁存取主要記憶體。
• 記憶體內部快取：在單一執行中的服務內，快速讀取少量、相對靜態的資料。

分散式快取會跨越多部伺服器，因此快取容量和交易處理能力都能超過單一機器。許多共用快取服務會使用伺服器叢集，並將快取資料分散到整個叢集；若要擴充快取，只要新增更多伺服器即可。有些分散式設計也會分層快取，因此某一層發生遺漏時，會從上游提供者提取，然後將結果儲存在本機，供下一次要求使用。

常見使用案例

• 多個應用程式執行個體和機器的共用快取層。
• 需要快取容量和輸送量超過單一主機的工作負載。
• 分層快取設定會在遺漏時從上游擷取，然後保留本機複本供後續要求使用。

快取會將經常存取的資料放在更接近使用位置的地方，這可改善回應時間，並協助系統處理更多並行要求。它也能減少原始資料存放區的競爭，例如資料庫連線數有限時。

在分散式應用程式中，快取通常會發生在多個位置，例如用戶端 (如瀏覽器) 和伺服器端 (在應用程式或共用快取服務中)。

從小處著手，專注於能帶來最明確回報的資料：

• 快取將讀取量高、擷取速度慢且變更不頻繁的資料 (例如參考資料)。
• 決定資料何時進入快取：
  • 首次要求後按需快取，因此只會儲存實際使用到使用的內容。
  • 如果預期某些項目在初期會被要求，可以在啟動時預先填入 (植入) 部分項目，同時留意原始存放區在啟動時的負載。
• 選擇您可以管理的模式。另行快取模式很常見，其指引強調過期、收回與一致性對結果的影響。

快取通常會保留主要存放區中的資料複本，因此需要留意新鮮度：

• 使用到期原則來限制資料在重新整理前，可在快取中保留的時間。
• 當快取已滿，請留意收回行為 (許多系統預設會收回最近最少使用的項目)。
• 請勿將快取當成重要資料的唯一存放位置。請將事實來源保留在永續性儲存體中，這樣即使快取無法使用，系統仍可繼續運作。
• 如果無法存取快取，則規劃一條後援路徑，回到原始資料存放區，並在讀取發生時重新填入快取。

快取是現代系統的核心建構區塊，因為它適用於多種結構，從單一服務到分散式應用程式和邊緣傳遞都適用。若要取得受控的記憶體內部快取雲端提供者，您可以探索 Azure。