前幾天我們處理了 Database Index、Cache、Replication、Sharding。但即使
Backend 與 Database 很快，全球 User 還是可能因為 Network Distance
覺得網站很慢。
今天要解決：
如何讓全球不同地區的 User 都快速取得網站內容？
答案之一就是 CDN（Content Delivery Network）。
Latency 可以簡單理解成：
從發出 Request 到取得 Response，需要等待多久。
Latency 可能來自 Network Distance、Routing、Server Processing、Database
Query 等。今天 CDN 主要改善 Network Distance 帶來的 Latency。
**RTT（Round Trip Time）**就是資料從 Client 到 Server，再回到 Client
所花的時間：
Client → Server → Client
距離越遠，Network RTT 通常越值得注意。
Static Content 是不需要每次即時計算、很多 User
取得的內容相同，例如：
Images
CSS
JavaScript
Fonts
Videos
Dynamic Content 則可能依 User 或即時資料產生：
/users/123/profile
/orders
/bank/account/balance
Static Content 通常非常適合 CDN Cache；Dynamic Content 則需要更仔細的
Cache Policy。
Origin Server 就是真正保存或產生原始 Content 的來源。
沒有 CDN：
User → Origin Server
所有全球 User 都直接向 Origin 取得內容。
圖片與影片也常放在 Object Storage。Object Storage 可以理解成專門保存
Images、Videos、Documents 等 File/Object 的 Storage System。
CDN = Content Delivery Network。
核心：
不要讓全世界 User 都跑到同一個遠端 Origin，而是在不同地區放置可以提供
Content 的 Server。
Origin Server
USA
│
┌─────────────┼─────────────┐
↓ ↓ ↓
Taiwan Edge Japan Edge Europe Edge
↓ ↓ ↓
Taiwan User Japan User Europe User
Edge Server 是 CDN 部署在靠近 User 的 Server。
Edge Location 則是這些 Edge Server 所在的 CDN 地理節點，例如
Boston、Tokyo、Taipei、Singapore、London。
核心概念：
User
↓
Nearby Edge
而不是每次：
User
↓
Far-away Origin
假設 Taiwan User 要下載：
product123.jpg
第一次 Edge 沒有：
User
↓
Taiwan Edge
↓ Cache Miss
Origin
↓
取得圖片
↓
Edge Cache
↓
User
下一個 User：
User
↓
Taiwan Edge
↓ Cache Hit
Response
這和 Redis 的 Cache Hit / Miss 概念非常相似。
當 Edge Cache Miss 時，CDN 主動去 Origin 取得 Content，這個流程常稱為：
Origin Pull
Edge Cache Miss
↓
Origin Pull
↓
Origin
↓
Content
↓
Edge Cache
Redis：
User → Backend → Redis → Database
通常靠近 Backend，用來降低 Database Load 或 Application Latency。
CDN：
User → CDN Edge → Origin
更靠近 User，用來降低 Network Latency 與 Origin Traffic。
Redis CDN
通常靠近 Backend User
常 Cache DB Result / App Data Image / CSS / JS / Video
主要降低 DB Load Network Latency / Origin Load
Location Data Center Global Edge
簡化記法：
Redis → Backend-side Cache
CDN → Edge Cache
TTL = Time To Live，也就是 Cache 可以保存多久。
logo.png
TTL = 24 hours
Trade-off：
Long TTL
→ Less Origin Traffic
→ Higher Stale Content Risk
Short TTL
→ Fresher Content
→ More Origin Traffic
如果 Origin 更新 product.jpg，但 Edge 還保存舊版本，User
可能繼續看到舊圖片。
這又是 Cache Invalidation 問題。
常見方式之一是改變 URL：
product-v1.jpg
product-v2.jpg
Frontend Build 也常看到：
main.a8f392.js
main.f781bc.js
File Content 改變後，Hash/Fingerprint 改變，URL 也改變。Browser 與 CDN
就會視為新的 Resource。
這種透過改變 Resource URL 避免舊 Cache 的方式常稱為：
Cache Busting
背後可能使用 DNS、Network Routing、Anycast 等技術。
今天不需要一次學完，只要先理解：
CDN Provider 會嘗試把 Request 導向合適的 Edge Location。
不一定只是地理距離最近，也可能考慮 Network Latency、Capacity 與
Availability。
Anycast 可以先理解成：
相同 IP Address 可以由不同地理位置的 Network Location 提供服務，再由
Network Routing 把 User 導向合適節點。
Same IP
│
┌─────────┼─────────┐
↓ ↓ ↓
Boston Tokyo London
今天只需要理解它的目的，不需要深入 Routing Protocol。
Bandwidth 可以簡單理解成：
一段時間內 Network 可以傳輸多少資料。
可以用道路類比：
Latency → 車從 A 到 B 要多久
Bandwidth → 道路同時可以運多少資料
兩者不是同一件事。
CDN 可以降低 User 到 Content 的距離，也可以降低 Origin 的 Bandwidth
Pressure。
可能的 Failure：
Edge Failure
Regional Outage
Provider Outage
DNS Problem
可能的方向：
Fallback to Origin
Multi-CDN
Retry
Alternative Region
但如果所有 CDN Traffic 突然回 Origin：
Huge Traffic → Origin
Origin 可能被打爆，形成 Cascading Failure。
可以，但要看資料特性。
例如 News Homepage 每 30 秒更新一次，可以考慮短 TTL。
但：
/bank/account/balance
是 User-specific 且要求新鮮度很高的資料，就不能讓所有 User 共用相同
Cache。
真正要問的是：
Response 能不能安全地 Cache？可以 Cache 多久？哪些 User 可以共用？
除了 Redis Cache、CDN Cache，Browser 本身也能 Cache
CSS、JS、Images、Fonts。
完整流程可能是：
Browser Cache
↓ Miss
CDN Cache
↓ Miss
Origin
這就是 Multi-Layer Caching。
每一層都可能有自己的 TTL、Invalidation 與 Consistency 問題。
假設：
Web Application Server 在美國，但台灣、日本、歐洲 User
都抱怨圖片很慢，怎麼改善？
先判斷：
Backend 慢？
Database 慢？
還是 Network Distance？
如果主要問題是：
Static Images
Global Users
Long Network Distance
CDN 是合理方向。
User
↓
Nearby Edge
↓
Cache Hit?
├── Yes → Return
└── No → Origin → Cache Edge → Return
再主動討論：
TTL
Cache Invalidation
Versioned URL
Origin Failure
CDN Failure
會比只回答 Use CDN 完整很多。
User
↓
CDN
↓
Load Balancer
↓
Backend Servers
↓
Redis
↓
Shard Router
↓
Database Shards
但不要把這張圖當成固定答案。
正確順序仍然是：
Requirement
↓
Bottleneck
↓
Solution
↓
Trade-off
1. Latency 是什麼？
2. RTT 是什麼？
3. Static vs Dynamic Content？
4. Origin Server 是什麼？
5. Object Storage 是什麼？
6. CDN 是什麼？
7. Edge Server 是什麼？
8. Edge Location 是什麼？
9. CDN Cache Hit / Miss？
10. Origin Pull 是什麼？
11. CDN 為什麼降低 Latency？
12. CDN 為什麼降低 Origin Load？
13. Redis Cache vs CDN？
14. CDN TTL 的 Trade-off？
15. Cache Invalidation？
16. Cache Busting / Versioned URL？
17. Anycast 是什麼？
18. Bandwidth vs Latency？
19. CDN 掛掉怎麼辦？
20. Dynamic Content 可以用 CDN 嗎？
21. Browser Cache vs CDN Cache？
22. Private Data 為什麼要小心 CDN Cache？
23. 全球 User 圖片很慢，你會怎麼分析？
CDN 核心：
User
↓
Nearby Edge
↓
Cached Content
主要幫助：
Reduce Network Latency
Reduce Origin Traffic
Reduce Origin Bandwidth Usage
Improve Global Content Delivery
但也帶來：
Cache Invalidation
Stale Content
TTL Design
CDN Failure
Security / Privacy
最重要的一句：
CDN 的核心不是單純「Cache 圖片」，而是把 Content 放到更靠近 User 的
Edge，降低 Network Distance 與 Origin Load。
假設 User Place Order 後，Backend 還要：
Create Order
Update Inventory
Send Email
Generate Invoice
Send Notification
Record Analytics
如果全部塞在同一個 Request 裡，User 可能等很久；Email Service
掛掉時，也不應該讓整個 Order 一定失敗。
下一篇：
Day 11｜Message Queue：為什麼大型系統不把所有工作都塞在同一個
Request？
我們會先從零解釋：
Synchronous
Asynchronous
Producer
Consumer
Queue
再進入：
Message Queue
Kafka
RabbitMQ
Event
Retry
Dead Letter Queue
At-least-once Delivery
Idempotency
繼續把系統從「可以 Scale」推進到「可以可靠地處理大量工作」。
iThome鐵人賽
看影片追技術