Web開發系列(七)：快取，CDN
摘要：
快取
如果有一個GET請求，每秒鐘有10k請求，但是10s鍾才需要重新整理一次，你會讓內容伺服器不停地處理這類請求嗎？
不會，這10秒內的100k次請求帶來的計算都是毫無意義的，浪費了CPU資源，並且還可能為內容伺服器之後的資料庫
帶來了不必要的壓力。所以我們需要引入一個概念：快取。
...
快取
如果有一個GET請求，每秒鐘有10k請求，但是10s鍾才需要重新整理一次，你會讓內容伺服器不停地處理這類請求嗎？ 不會，這10秒內的100k次請求帶來的計算都是毫無意義的，浪費了CPU資源，並且還可能為內容伺服器之後的資料庫 帶來了不必要的壓力。所以我們需要引入一個概念：快取。
我們在每次處理請求之前，檢查一下記憶體中是否已經產生了結果，如果是，那麼直接返回結果，否則，計算，返回結果並且 同時將結果放入記憶體中以便重複利用。這顯然已經不是和計算機作業系統級別的快取是同一個概念了，web開發中的快取 通常是指對靜態資源，請求響應等的儲存以便節省CPU資源。
在實際生產中，我們一般使用Redis作為快取容器，Redis是一個高效能的K-V資料庫，我們把快取定義好一個key，內容則 放在value中，通常我們還會為key設定過期時間，這樣再通過上面的手段便可以大量的節省內容伺服器的無用計算。在Redis 火爆之前，一般都會使用memcached，不過我沒有用過。
CDN
如果你的客戶，或者說請求來源於全球，但是你的網站伺服器只在中國有，那麼來自美國的使用者可能會感覺請求非常的慢， 因為網路質量的問題，一個網路請求可能要跨越太平洋來到中國，帶上伺服器給出的響應回去。那麼有沒有什麼好辦法可以讓 全球的使用者都得到最快的響應呢？有，把你的伺服器部署到全球各個地方，然後通過DNS做負載均衡，解析到最近的伺服器， 這樣全球的使用者的請求都會打到離他最近的地方。這種技術就叫CDN。
一般情況下CDN伺服器都會快取住源伺服器的響應，並且定時重新整理。但是CDN僅限於可以快取的內容例如變化不頻繁的網頁， 如果是頻繁變化，或者每個請求得到的響應都不一樣，則不適用，例如面向APP或者前端的API介面響應。
參考：
- ofollow,noindex" target="_blank">https://en.wikipedia.org/wiki/Content_delivery_network