如果說訪問量上升對網站性能有很大考驗，那突發事件，則是檢驗網站架構的試金石。從某 L 和某 G 談戀愛，至某 W 和某 M 離婚，到某 F 和某 Z“官宣“事件，都導致某 SNS 網站宕機崩潰，無法為廣大網民提供正常服務。互聯網圈有一句比較有名謎之反問：
你的網站能承受幾個明星出軌？
由此可見，想做好一個網站，遠遠沒有看起來那么簡單。
無論你將 WEB 前端進行何種方式的優化，是頁面動靜分離？各種文件壓縮算法？還是將 Web Server 從老牌 Apache 換成性能之王 Nginx(以及其變種)？在絕對的訪問量面前，一切都變得脆弱無比，不堪一擊！更可怕的是，除了熱點爆料會導致海量、合法的用戶訪問請求，還有隱藏在暗處的黑客們源源不斷發起的各種 DDoS/HTTP Flood 攻擊，這些都會分分鐘讓你的網站瞬間癱瘓。無論是合法的，還是非法的，這些流量就像一支龐然大軍，具有摧枯拉朽的絕對實力。
因此，在互聯網+追求合作共贏的時代，熱門網站更加需要專業團隊的安全保障。安全防護類產品可在網站前面砌起一座城墻，將流量大軍擋在城門之外，同時將被訪問網站的真實服務器隱藏起來，只接受少量、合法的流量的請求訪問。專業團隊固然能夠提供 DDoS／CC／WAF 等各種防護手段來過濾異常流量，但這不是我們今天的主題，我們要說的，是在防護的同時對網站的優化手段：CDN 緩存優化。
首先讓我們來看一張 CDN 的整體架構圖：
我們知道，對網站請求返回的文件，有動態文件和靜態文件兩類。所謂靜態文件，具有一個特點，有點類似數學中“冪等”的概念。請求靜態文件好比擲骰子，每次都能擲到六點。而請求動態文件，則不然，這次擲到六點，下次可能是五點，也可能是一點。所以，對于靜態文件，只要在 Web Server 上不更新，在響應同樣的請求時（主要是 HTTP GET 請求），不管請求多少次，都會返回一樣的文件內容。動態文件則反之，對于每個請求（HTTP GET／POST），都可能會返回不一樣的文件內容。Web Server 返回的圖片，文檔，點播視頻，一般都是靜態文件，而像 html，php，jsp 文件，一般都是動態文件。
靜態文件都可以被 CDN 系統緩存下來，甚至某些動態文件，也可以在很短時間（比如 1 秒內）將其看成是靜態的，從而緩存下來。一旦這些文件被緩存到 CDN 系統中，那流量大軍期望通過攻擊這些文件從而達到使網站宕機的目的，難度將大大提升，甚至毫無希望！
我們知道，CDN 系統是分布式的。就拿云防護來說，我們在全國各地都部署了緩存節點，每個節點都有同一份文件的拷貝，流量通過智能 DNS 系統調度，用戶會優先訪問距離自己最近的緩存文件，從而得到想獲取的內容。這樣，從全國各地發起集中涌現到源站的突增流量，就被分散到了各地的分布式節點上。在文件過期之前，Web Server 甚至不會感知到這些訪問請求。這就好比，靜態文件真身坐鎮大本營，各分身負責接待這些流量小分隊。當分身能正常分發給訪客時，其真身可以高枕無憂。
但這并不是萬無一失的完美解決方案，我們還需要考慮到緩存文件會過期的可能性。這就好比，我們的真身在一段時間后（從幾分鐘到幾天不等），任期結束了，換了一位新的繼任者。此時，CDN 緩存節點需要重新向 Web Server 重新發起請求，獲取新文件，生成新的分身。另外，當網站剛接入 CDN 緩存系統時，也是需要向 Web Server 發起請求拷貝文件的。此時此刻，如果有流量部隊剛好“造訪”，CDN 緩存節點沒法直接響應，只能將流量導向 Web Server，在這短暫的瞬間，Web Server 中的真身會被暴露，其可能會被打垮！
如果緩存過期了，就真的無計可施了嗎？
當然不是！
云防護 CDN 系統早已考慮到了這種情況，并有至少三種解決對策：
（1）通過建立緩存父層將回源流量進行收斂。
我們把 CDN 緩存節點向 Web Server 發起的請求稱為回源請求，將 Web Server 稱為源站。當靜態文件過期時，緩存節點不直接回源，而是先請求上一級的緩存節點，由上一級的緩存節點回源。這是一個樹型結構，父層節點在頂層。大量緩存節點在葉子處，它們訪問父層，再由少量的父層節點回源。通過這樣的層級收斂，將大量的緩存節點請求，轉化成少量的父節點回源請求，從而大大減小源站的壓力。
（2）緩存節點至父層合并回源。
大量的緩存節點向父層(或源站)發起請求時，也勢必會給父層節點造成很大的壓力。針對這種情況，云防護有自研的解決方案，可將同一個文件的大量并發請求，合并成一個或者少量請求返回給父層，從而使父層的請求數大大減少，緩解父層壓力。而這種技術，父緩存節點是無感知的。我們將這個技術稱之為“合并回源”。目前 Squid/Apache Traffic Server 等開源軟件，都采用了這種技術。
（3）條件回源。
當緩存節點發現文件過期時，常規做法是重新下載整個文件，覆蓋舊文件。在文件體積比較小的情況下，這種方式問題不大；可一旦文件體積過大，大量的文件更新，對服務器也是一種考驗。此時，我們會啟用條件回源：當緩存節點認為緩存文件過期時，源站文件可能并未真正更新，只是到了例行的過期檢查時間點而已。此時，我們會在 HTTP 頭部攜帶特定的信息，來詢問源站是否真的更新了文件。事實經驗告訴我們，在大部分情況下，源站文件并沒有真正更新。通過這種方法我們可以避免粗暴無用的重復下載整個文件。
這樣看來，在大部分情況下你都無需擔心了。但還有這樣一種情況可能發生，那就是 Web Server 由于種種原因，無法提供正常服務了（比如由于自身原因，出現短暫宕機）！而此時靜態文件又恰好過期，這樣一來，緩存節點的流量會導向源站，源站又不能正常提供服務，在訪客看來，網站就無法訪問了。
這可怎么辦呢？！
不用怕！
云防護系統也同樣考慮到了這種情況，并至少提供以下三種解決方案：
（1）使用舊緩存文件
當緩存節點回源時，源站有故障，會返回異常頁面，如 502/504，或超時等。此時，緩存節點直接使用舊文件響應訪客。在訪客看來，能正常訪問到內容，并不會感知到源站出現故障。此外，我們還會對舊文件強制延長一個短的過期時間，防止短時間內出現頻繁回源的情況。
（2）永久在線
對于開啟此功能的網站，云防護會通過自研的爬蟲程序，定期抓取客戶源站的內容，緩存到我們的數據服務器上，我們稱之為“鏡像”。當源站出現問題時，緩存節點也可以將訪問請求導向“鏡像”文件，從而正常響應數據給訪客。
（3）重保只讀
和永久在線原理類似，重保只讀也是通過爬蟲生成“鏡像”文件。只是，此時“鏡像”可以充當源站使用（偽源站），源站在重保只讀期間，可完全關閉。所有的請求或攻擊，都不會導向真正的源站，這樣即可保證重要時期源站不會因攻擊或訪問量過大而出現問題。
當然，以上策略都是可能有損的。前面講過，對動態文件的請求是非冪等的，即使強制緩存起來，也沒有大太作用。另外像 SNS 網站有較強的交互性，除了下載以外，還會上傳文件（HTTP POST/PUT）。這些數據，目前都沒有辦法用以上策略解決。當 Web Server 出現問題時，還需要網站盡快針對自身問題從根源上進行修復。
至此，CDN 緩存系統和 Web Server 各司其職，相得益彰。你不知道的是，云防護 CDN 緩存內部其實還有許多其他方面的優化：
（1）Range 請求的緩存及回源合并。
（2）熱點文件分級緩存。
（3）全鏈路 IPv6 的支持。
（4）全鏈路 HTTP2 等協議的支持。
（5）基于日志的分析與監控。
（6）基于監控的動態父層設計。
所有這些，都是為了一個共同的目標：最大程度的為客戶網站提供防護！接入云防護，安全無憂~
