自建CDN技術選型：Squid Varnish Nginx
CDN的全稱是Content Delivery Network，即內容分發網絡。其基本思路是盡可能避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快、更穩定。
使用CDN有3個好處
- 優化跨ISP網絡訪問速度，在國內大聯通和大電信之間是世界上最遠的距離，在國外，中國和其他地區很平行，用cdn可以優化全球響應速度
- 節約流量成本，CDN機房都一般都放在帶寬便宜的小城市，帶寬成本大概是BGP機房的1/3
- 快速提升性能，對于結構復雜的系統，部署CDN可以在不改動代碼段情況提升網站整體性能，立竿見影
市面上有很多CDN供應商，比較著名有：
- Akamai (全球***)
- chinacache
- webluker
- cloudflare
- chinacache
如果需要自己搭建CDN系統，有3種主流方案可以選擇
- squid
- varnish
- nginx+memcache
典型用戶
- Squid http://www.squid-cache.org，大多數CDN供應商都用squid
- varnish http://www.varnish-cache.org,用戶較少，sina微博在用
- nginx+memcache 搜狐CDN集群,淘寶的部分業務
存儲共享
對于大規模網站的CDN，存儲共享是個強需求。為了消除單點，不可能只使用一臺CDN服務器，如果只是簡單做負載均衡，單臺CDN server 上需要存儲全部數據，存儲利用率太低了
- squid支持幾個實例并聯，實際使用的人不多
- varnish 只能用單實例
- nginx+memcache 天然的分布式存儲
當然，采用squid/varnish 也有解決辦法: 需要在它們前面部署一個支持url hash的負載均衡設備(硬件，軟件均可，比如說haproxy)
內存存儲的代價
如果CDN把緩存放在內存當中，固然性能會有提升，但是當服務遭遇故障重啟之后，全部數據都會丟失需要重建，這個時候
- 會給后端應用服務器帶來很大的短時壓力
- 服務需要較長的時間才能完全恢復
而實際運行當中，由于各種原因，CDN服務重啟的概率相當高。
一個很悲劇的事實
對動態網頁使用CDN，無論squid還是varnish都不能直接用，都需定制代碼。
例如 varnish 會判斷response的header，如果發現里面有set-cookie項，它就認為這個頁面不應該被緩存。對于規模龐大/OOP封裝嚴密的網站，普通程序員根本意識不到調用哪一個fucntion會輸出set-cookie，這個會導致CDN命中率急劇降低。但你也無力去對每行代碼做code review，沒有辦法，只能去修改varnish代碼了，這又引入一個新的維護成本. Squid也有這個問題
purge效率
purge就是CDN刪除緩存項的接口，國內的UGC網站，因為嚴厲的內容檢查制度和泛濫的垃圾廣告，刪帖子刪圖片特別頻繁，某些網站可能高達40%（發100個貼，有40個帖子可能被刪除或者修改)，所以對purge的效率有要求。
squid和varnish purge效率都達不到國內這種強度要求，nginx+memcache purge性能 要好很多
在當前的中國,遇到突發事件，你要不及時刪除指定的鏈接，你的老板就可能會去拍下面這種相片
某門戶網站曾經發生過，某個鏈接怎么也刪不掉，一慌張把CDN所有緩存都刪了重啟，導致內網流量瞬間暴漲，各業務線的服務器全線報警，集體罵娘。
推薦CDN方案
- 中小型網站直接買服務就好，現在CDN已經進按需付費的云計算模式了，性價比是可以準確計算的
- 外地部署單點，推薦用squid
- 準備在公司內部實施私有云戰略，推薦nginx+memcache
不建議使用varnish
以前的工作中，我力主把一個CDN集群從squid遷移到varnish，持續運行了2年，就是如上感受,嚴重不推薦.
