Microsoft AZ-204: Azure 快取、CDN 和效能 — 學習指南

By Laurynas Brazys · 6 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

屬於 Microsoft Azure Developer Associate AZ-204 — 學習指南. 使用經過驗證的解答練習： Microsoft 考試中心, 或參加限時模擬考試： ExamRoll.io.

概觀

在 Azure 中，要提供快速、可靠的使用者體驗，取決於是否能將內容與狀態放置在靠近使用者的位置、最小化來源負載，並優雅地處理故障。Azure Cache for Redis、Azure CDN 與 Azure Front Door 共同提供了記憶體內加速、邊緣快取，以及具備安全性的全域 anycast 路由。精通 Redis 資料結構與連線模式、CDN 設定檔與快取語意，以及 Front Door 路由與健康狀態探查，能讓您設計出低延遲、具備彈性的應用程式。

Azure Cache for Redis：層級、資料結構、收回原則與模式

Azure Cache for Redis 是一項受控的 Redis 服務，提供次毫秒級的資料存取，並在較高等級中支援常見的 Redis 資料結構與進階功能。

層級：

• Basic：單節點快取，無 SLA 且無資料複寫。適合開發/測試與非關鍵性工作負載。無資料持久化、無叢集化、無 VNet 整合。
• Standard：雙節點主/從架構，具備自動容錯移轉與 SLA。適合生產環境。支援以最小的中斷進行擴大/縮小，但無叢集化或持久化。
• Premium：更高的效能與輸送量、更大的快取大小、Redis 持久化 (RDB 與 AOF)、用於水平擴展的叢集化 (分片)、虛擬網路整合、區域備援 (在支援的區域)，以及用於 DR 的異地複寫。同時也支援排程修補時段與進階安全性。

資料結構與使用時機：

• Strings：基本的鍵/值、計數器、JSON blob；用於速率限制與計數器的原子性 INCR/DECR。
• Hashes：將物件欄位 (例如，使用者設定檔) 存為帶有欄位-值配對的單一鍵，以利部分更新與空間效率。
• Lists：佇列或堆疊，依插入順序排序；搭配 LPUSH/BRPOP 用於簡單的工作佇列。
• Sets：唯一的集合；用於標籤、成員資格檢查、交集運算。
• Sorted Sets：帶有分數的排名；非常適合排行榜與依時間排序的事件。
• Bitmaps/Bitfields：緊湊地追蹤跨位置的布林旗標與計數器。
• HyperLogLog：以固定的記憶體估算基數 (唯一計數)。
• Geospatial：儲存並查詢經緯度座標、半徑搜尋。
• Streams：用於事件擷取與消費者群組的僅附加日誌。

收回原則 (當達到 maxmemory 時套用)：

• volatile-lru：收回最近最少使用且有到期時間的鍵 (Azure Cache for Redis 上的預設值)。
• allkeys-lru：收回最近最少使用的鍵，無論其是否有到期時間。
• volatile-ttl：收回最快到期的鍵。
• volatile-random / allkeys-random：收回隨機的鍵，範圍限定在即將到期或所有鍵。
• noeviction：不收回；會增加記憶體的寫入指令將會失敗並回傳錯誤。
• volatile-lfu / allkeys-lfu：最近最不常使用的收回變體 (適用於較新版的 Redis)。

根據資料的關鍵性與存取模式來選擇收回原則。對於快取，allkeys-lru 或 allkeys-lfu 能提供最佳的命中率。對於混合儲存且已謹慎設定到期時間的場景，volatile-ttl 或 volatile-lru 可以尊重您設定的 TTL。

常見使用案例：

• Session caching：透過 IDistributedCache 或 session 中介軟體儲存使用者 session 狀態。保持鍵的大小精簡，使用與 session 逾時一致的 TTL，並在需要時於邊緣啟用 session affinity。
• Output caching：快取已渲染的頁面片段或完整回應，並以路由與使用者區段為鍵。當內容變更時，使用鍵版本控制或明確的 DEL 來使快取失效。
• Pub/Sub：用於通知或快取失效 fan-out 的近即時訊息傳遞。使用 channels 將變更廣播給多個訂閱者。
• Leaderboards：使用帶有分數的 sorted sets 進行排名；用 ZADD/ZREVRANGE 來更新與讀取前 N 名；使用次要的 sorted sets 來進行時間區間排名。

連線至 Azure Redis：連線字串、StackExchange.Redis 與彈性

連線端點與金鑰可在 Azure 入口網站的「存取金鑰」下找到。主要連線字串包含主機、連接埠、TLS 與密碼 (例如，contoso.redis.cache.windows.net:6380,password=…;ssl=True;abortConnect=False)。在生產環境中，務必在 6380 連接埠上使用 TLS。

StackExchange.Redis 最佳實務：

• 每個程序使用一個單一、長生命週期的 ConnectionMultiplexer。它是執行緒安全的，並且能有效率地多工處理請求。建立一次，將其儲存在靜態或 DI 容器中，然後重複使用。
• 設定選項：設定 AbortOnConnectFail=false 以容忍雲端容錯移轉；設定 ConnectRetry 與 ConnectTimeout 以處理暫時性問題；根據工作負載調整 SyncTimeout；使用 KeepAlive 來維持 NAT pinhole。文字格式的範例選項：ssl=True, abortConnect=False, connectRetry=5, connectTimeout=5000。
• 使用非同步方法以避免在高負載下發生執行緒池耗盡。IDatabase 的方法 (StringGetAsync, HashSetAsync, SortedSetAddAsync) 是非阻塞的。
• 處理彈性事件：訂閱 ConnectionFailed、ConnectionRestored 與 ConfigurationChanged 事件，以記錄並觀察拓撲變更與容錯移轉。StackExchange.Redis 會在容錯移轉時自動重新解析主要節點。
• 避免長時間執行的 Lua 指令碼與繁重的交易；偏好使用小型的原子性指令。透過 multiplexer 自然地進行管線化；不要過度批次處理到導致逾時。
• 逾時與重試：不要盲目重試非冪等的指令。針對關鍵寫入，使用冪等模式或 write-through 佇列。
• 序列化：儲存緊湊的酬載 (例如，MessagePack) 以最小化網路流量與記憶體用量。避免巨大的值；偏好使用具備欄位層級存取能力的 hashes。
• 鍵命名：依應用程式/環境加上前綴 (prod:session:{userId}) 以避免衝突並簡化批次操作與清除。
• 安全性：輪替存取金鑰、透過 VNet (Premium) 進行限制，並考慮使用 Private Link 進行私有存取。在生產環境中，不要將「僅允許透過 SSL 存取」設為 false。

Azure CDN：設定檔、端點、來源、最佳化與內容新鮮度

Azure CDN 在邊緣 POP 快取靜態內容，以降低延遲和來源負載。一個 CDN 設定檔會將多個端點和定價層/提供者群組在一起；而一個端點則定義了邊緣主機名稱，並連接到一個或多個來源。

設定檔與端點：

• 在一個設定檔下，為每個應用程式或環境建立一個或多個端點。每個端點都有自己的邊緣主機名稱 (例如 app.azureedge.net)，您可以透過 TLS 將其對應到自訂網域。
• 若有需要，可使用不同的設定檔來隔離帳務，或套用不同的提供者/功能。

來源類型：

• Azure Blob Storage：非常適合靜態網站和大型媒體檔案。啟用靜態網站功能或對應到一個容器；並確保設定了正確的 MIME 類型和快取標頭。
• App Service：用於動態內容或 REST API，其中特定的回應可以被快取。將來源主機標頭設定為您應用程式的主機名稱，並確保使用 HTTPS。
• 自訂來源：任何可公開存取的 HTTP(S) 端點，包括透過公用 IP 或反向代理連線的地端主機。

最佳化類型 (於建立端點時套用)：

• 一般 Web 傳遞：針對大量中小型資產 (HTML、CSS、JS、圖片) 提供平衡的效能，並具備廣泛的 POP 覆蓋範圍。
• 大型檔案下載：針對大型檔案進行最佳化，包含範圍請求 (range request) 的調整、連線管理以及以吞吐量為導向的設定。
• 視訊串流：針對漸進式下載或 HLS/DASH 區段傳遞進行最佳化，保持區段快取的效率並支援位元組範圍請求 (byte-range requests)。

快取規則與清除：

• 全域和自訂快取規則讓您可以根據路徑、副檔名、請求方法和查詢字串行為來控制 TTL。在標準層，您可以在端點的快取設定中配置規則；Premium 層級則增加了進階規則引擎。
• 您可以透過 portal、CLI 或 REST API，使用帶有萬用字元的路徑 (例如 /images/*) 來清除無效內容。清除動作會傳播到所有 POP；請使用目標式清除來最小化衝擊範圍。Premium 層級支援預載 (preload) 功能來暖快取 (warming caches)。

內容新鮮度控制：

• TTL：CDN 預設會遵循來源的 Cache-Control 和 Expires 標頭。您可以使用規則來覆寫或設定最小/最大 TTL。對於不可變資產，請提供 Cache-Control: public,max-age=31536000,immutable 標頭以最大化快取命中率。
• Cache-Control 指令：no-store 和 private 不會被 CDN 快取；must-revalidate 和 s-maxage 則允許進行精細的共用快取控制。建議使用 s-maxage 來設定 CDN 專用的 TTL，同時為瀏覽器保留一個較保守的 max-age。
• 查詢字串快取行為：您可以選擇忽略查詢字串 (每個路徑只有一個快取物件)、快取每個唯一的 URL (每個查詢字串組合都分開快取)，或是在有查詢字串時略過快取。對於有版本號的資產 (例如 app.css?v=hash)，請選擇快取每個唯一的 URL。對於分析參數 (如 utm_)，則應忽略查詢字串以提高命中率。
• Vary 與壓縮：在進行壓縮時，請確保設定了 Vary: Accept-Encoding 標頭；CDN 會根據每個 Vary 鍵值快取不同的版本。為文字資產啟用 CDN 壓縮以減少頻寬使用。

Azure Front Door：全域路由、健康狀態、安全性與親和性

Azure Front Door 提供以 anycast 為基礎的第七層 (Layer 7) 全域負載平衡、動態網站加速，以及整合式 WAF。它透過路由和保護動態流量來輔助 CDN，同時在 Standard/Premium 版中可選擇性地快取靜態內容。

路由規則：

• 匹配傳入的主機名稱和路徑模式，並將流量路由到一個來源群組 (後端集區)。可為每條規則套用路徑重寫、標頭轉換、重新導向及通訊協定設定。
• 當您希望在應用程式邊緣進行更嚴格的控制時，可在路由層級 (Standard/Premium) 設定快取，以對靜態或半靜態資產進行邊緣快取。
• 在多個來源之間使用以優先順序為基礎的容錯移轉和加權負載平衡，並可選擇性地搭配地理篩選 (geo-filtering) 進行特定區域的路由。

健康狀態探查與後端健康狀態：

• 定義探查路徑、通訊協定、間隔時間以及預期的 HTTP 狀態碼。探查會從多個邊緣位置執行，以判斷來源的健康狀態。
• Front Door 使用健康狀態將流量導向至健康且低延遲的來源。調整逾時時間和取樣大小以避免狀態抖動 (flapping)；確保探查端點是輕量級且未被快取的。

WAF 整合：

• 將一個 WAF 原則附加到您的 Front Door，以強制執行針對常見 Web 漏洞的受控規則集，並新增用於 IP 限制、地理封鎖或請求大小限制的自訂規則。
• 使用機器人防護和速率限制在邊緣吸收濫用流量，以保留來源的容量。

工作階段親和性：

• 當您的應用程式需要連續的請求命中同一個後端時 (例如，非分散式工作階段狀態)，請啟用工作階段親和性。Front Door 會注入一個親和性 cookie，並將同一工作階段中的後續請求路由到路由規則內選定的後端。
• 盡可能優先選用無狀態設計或由 Redis 支援的工作階段狀態以避免使用親和性；若必須使用，請謹慎界定親和性的範圍並設定適當的 cookie TTL。

與 CDN 的協同運作：

• CDN 應用於提供具有長 TTL 的靜態資產 (圖片、腳本、媒體)；Front Door 則透過 WAF、TLS 終止和路徑式路由來處理動態請求。這種分工可以最大化快取命中率並最小化動態延遲。
• 對於無法快取的 API 或頁面，請保持較低的 TTL 或繞過快取；對於半靜態的 HTML，可考慮使用較短的 TTL 並搭配變更時清除 (purge-on-change) 的工作流程。

實務問題情境

Mozilla 正在為其附加元件探索功能推出一個全球性的微型網站，預計在發布期間會有高流量尖峰。他們需要快速的靜態資產交付、具備彈性的動態 API，以及全球範圍內安全、低延遲的使用者互動。

1. 使用 Front Door 作為全域進入點與安全防護

• 建立一個帶有自訂網域和受控 TLS 的 Front Door Standard 設定檔。定義路由規則：將

undefined

路由至 App Service API 來源群組，並將

undefined

路由至 CDN 端點主機名稱。

• 理由：Anycast 路由將使用者帶到最近的邊緣節點；Front Door 上的 WAF 在流量到達來源前攔截惡意模式；路徑式路由清楚地分離了動態和靜態流量。

2. WAF 原則與速率限制

• 附加一個啟用受控規則集的 WAF 原則，並新增一條自訂規則來節流 (throttle) 對

undefined

的過量

undefined

請求。

• 理由：保護 API 免受 OWASP 等級的攻擊和濫用行為的用戶端侵擾，在流量尖峰期間保留來源的容量。

3. 健康狀態探查與來源群組

• 設定 API 來源群組，使其包含位於不同區域的兩個 App Service 執行個體。在

undefined

上使用健康狀態探查，預期狀態碼為

undefined

，間隔為 10 秒。將一個區域的優先順序設為 1，另一個設為 2，以實現容錯移轉。

• 理由：確保在主要區域效能下降時能自動進行區域性容錯移轉；探查能獨立於快取回應來偵測健康狀態。

4. 由 Redis 支援的工作階段與輸出快取

• 部署 Azure Cache for Redis Standard 版，並將 API 與

undefined

整合，以儲存最少的工作階段狀態以及常見 API 回應 (例如，熱門附加元件列表) 的短生命週期輸出片段，TTL 設定為 60-300 秒。

• 理由：在將狀態移出 Web 層的同時，減少了 API 延遲和資料庫負載；短 TTL 能在無需手動使其失效的情況下保持資料的新鮮度。

5. 使用 Redis 資料結構建置排行榜

• 針對每個類別使用一個 Redis 排序集 (sorted set) (例如，

undefined

) 來維護基於下載量的排名。透過一個佇列消費者 (queue consumer) 非同步地更新分數，並提供讀取 API 來讀取前 N 筆條目。

• 理由：排序集提供

undefined

的更新效率和快速的範圍讀取，非常適合需要高讀取並行性的即時排行榜。

6. 使用 StackExchange.Redis 確保連線恢復能力

• 初始化一個單例 (singleton) 的

undefined

，設定

undefined

、

undefined

、

undefined

，以及合理的逾時時間。處理

undefined

/

undefined

事件以提高可觀測性，並在使用非同步 API 的同時將

undefined

設定得足夠高以應對突發流量。

• 理由：確保無縫的容錯移轉處理，並避免在暫時性的網路事件或 Redis 容錯移轉期間發生全域性的服務中斷。

7. 為靜態資產配置 CDN 並採取積極快取策略

• 建立一個 Azure CDN 設定檔和端點，針對「一般 Web 傳遞」進行優化，並以儲存體帳戶靜態網站作為來源。設定快取規則以遵循來源標頭，但對

undefined

路徑覆寫為 7 天的 TTL，並啟用壓縮。將查詢字串快取設定為「快取每個唯一的 URL」，並為資產加上指紋 (fingerprint) (例如

undefined

)。

• 理由：邊緣快取能在全球範圍內快速交付資產；加上指紋的作法允許使用長 TTL，同時在部署時能即時更新；壓縮則減少了傳輸大小。

8. 在 CI/CD 中整合清除程序

• 新增一個部署步驟，在發布時清除 HTML 和 JSON 清單檔的 CDN 路徑 (例如

undefined

,

undefined

)，並在支援的層級中預先載入關鍵頁面以暖化快取。

• 理由：確保使用者能快速獲取最新的 HTML，同時保持不可變的資產被快取；預先載入可減少部署後的冷啟動延遲。

9. 僅在必要時使用 Front Door 的工作階段親和性

• 保持 API 無狀態，並依賴 Redis 處理工作階段狀態；對

undefined

路由停用 Front Door 的工作階段親和性。對於一個需要親和性的舊版管理工具，則在

undefined

路徑上啟用它，並設定一個較短的 TTL。

• 理由：為大多數使用者最大化負載分佈和可快取性，同時將親和性的使用限制在最小的必要範圍內。

此架構使用 Front Door 進行安全、智慧的邊緣路由和 WAF 防護，使用 Azure CDN 進行高命中率的靜態內容傳遞並提供精確的資料新鮮度控制，並利用 Azure Cache for Redis 來卸載熱門讀取、維護低延遲的工作階段和排行榜資料，以及平穩地吸收流量尖峰。

← Azure 事件驅動和訊息解決方案 · 所有領域 · Azure 監視、診斷和 DevOps 整合 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Microsoft →