在雲端原生應用程式中快取

提示

此內容摘錄自《建構適用於 Azure 的雲端原生 .NET 應用程式》電子書，您可以在 .NET Docs 找到此電子書，或免費下載可離線閱讀的 PDF。

下載 PDF

快取的優點已是眾所周知。 這項技術的運作方式是將經常存取的資料，從後端資料存放區暫時複製到靠近應用程式的快速儲存體。 快取通常會在以下情況實作...

• 資料保持在相對靜態的狀態。
• 資料存取速度很慢，特別是與快取的速度相比。
• 資料容易發生高層級的爭用。

為什麼？

如 Microsoft 快取指引中所述，快取可提高個別微服務和系統整體的效能、延展性和可用性。 它可降低處理大量並行要求至資料存放區的延遲和爭用。 隨著資料量和使用者數目增加，快取的好處就會越明顯。

當用戶端重複讀取不可變或不常變更的資料時，快取最有效。 範例包含參考資訊 (例如，產品和定價資訊)，或高建構成本的共用靜態資源。

雖然微服務應該是無狀態的，但分散式快取可以在絕對需要時支援並行存取工作階段狀態資料。

避免重複計算時也請考慮快取。 如果作業轉換資料或執行複雜的計算，請快取結果以進行後續要求。

快取架構

雲端原生應用程式通常會實作分散式快取架構。 快取會作為雲端式支援服務裝載，與微服務不同。 圖 5-15 顯示其架構。

圖 5-15：在雲端原生應用程式中快取

在上圖中，請注意快取獨立於微服務之外，並由其共用的方式。 在此案例中，API 閘道會叫用快取。 如第 4 章所述，閘道可作為所有傳入要求的前端。 分散式快取會盡可能傳回快取的資料，以提高系統回應性。 此外，將快取與服務分開，可讓快取獨立相應增加或相應放大，以符合增加的流量需求。

上圖顯示稱為另行快取模式的常見快取模式。 針對傳入要求，您必須先查詢快取 (步驟 #1) 以取得回應。 如果找到，則會立即傳回資料。 如果快取中沒有資料 (稱為快取遺漏)，則會從下游服務中的本機資料庫擷取 (步驟 #2)。 然後，它會寫入快取，以供後續要求使用 (步驟 #3)，並傳回給呼叫端。 請務必注意定期收回快取的資料，讓系統保持及時且一致。

隨著共用快取增多，在多個節點之間分割其資料可能會很有助益。 這樣做有助於將爭用降到最低，並改善延展性。 許多的快取服務支援動態新增 (與移除) 節點，以及重新平衡分割之間資料的功能。 這種方法通常牽涉到叢集。 叢集會將同盟節點的集合，公開為無縫的單一快取。 但內部的資料會分散在節點之間，並遵循某些預先定義的散發策略，以便平均地平衡負載。

Azure Cache for Redis

Azure Cache for Redis 是由 Microsoft 全權管理的安全資料快取和訊息代理程式服務。 作為平台即服務 (PaaS) 供應專案取用，它可提供高輸送量和低延遲的資料存取。 服務可供 Azure 內外的任何應用程式存取。

Azure Cache for Redis 服務會管理跨 Azure 資料中心裝載之開放原始碼 Redis 伺服器的存取權。 此服務可作為提供管理、存取控制和安全性的外觀。 此服務原生支援豐富的資料結構，包括字串、雜湊、清單和集合。 如果您的應用程式已經使用 Redis，搭配 Azure Cache for Redis 使用時，它將會維持原樣運作。

Azure Cache for Redis 不僅是一種簡易快取伺服器。 它可以支援許多案例來增強微服務架構：

• 記憶體內部資料存放區
• 分散式非關聯式資料庫
• 訊息代理程式
• 組態或探索伺服器

針對進階案例，快取資料的複本可以保存至磁碟。 如果發生同時停用主要和複本快取的災難性事件，即可使用最新的快照集重新建構快取。

Azure Redis Cache 可在許多預先定義的組態和定價層中使用。 進階層有許多企業級功能，例如叢集、資料持續性、異地複寫和虛擬網路隔離。

上一個下一個