本文講快取中的內容管理–檔案的刪除。

基本原理

快取系統中的檔案，從無到有是被動產生的。初始狀態，快取系統中是空的，請求過來之後，快取會回源取，然後存在本地。而不像web伺服器，檔案是通過其他的手段（傳統的是通過ftp上傳）來建立的，這個建立檔案的過程對web伺服器來說是無感知的，請求到伺服器以後，server會按照url的路徑跟伺服器配置的docroot來到本機的檔案系統裡去定位相應的檔案，如果存在，那麼迴應200 OK，併發送檔案內容，如果不存在，則迴應404 Not Found。相對來說，快取伺服器自身是不會給響應404的，除非它取源取到的就是404迴應。

檔案一旦被快取伺服器建立，將一直存在。在沒有外界干涉的情況下，檔案有兩種消亡方式。第一就是檔案的快取時間到了。因為任何一個被快取的內容，都是有保鮮時間的。保鮮時間要麼是源給指定的（Expires等相關欄位），要麼源沒有指定，由CDN快取伺服器自身策略給指定的預設時間。檔案一旦過期，快取就會回源驗證原始檔案是否被更新了，如果沒有更新，源站會給出304迴應。更新了的話，則會給200 ok，並回傳相應檔案內容。第二就是快取伺服器本身儲存空間達到了上限，這個時候快取就會通過自己的LRU機制來淘汰“較冷”的內容。

除了這兩種情況外，還有一種特殊情況，就是當前快取的檔案還沒有過期，但是此刻源站已經修改了檔案。那麼在cdn快取中的檔案過期之前，使用者都不能訪問到最新的內容，這個時候就需要通過外界來干預。這裡就用到了一種http請求，方法名叫PURGE。這個方法幾乎已經是快取裡的跟GET，HEAD，POST處於相同地位的重要方法。PURGE請求告訴快取伺服器，該url對應的檔案需要從系統裡刪除。刪除以後，再來的請求，就會由於快取裡不存在相應檔案而去取源。

PURGE請求的產生一般來自CDN系統內部，使用者會通過一些CDN提供的任務系統來告知CDN，自己需要刪除哪些檔案。CDN會通過一定的方式來獲取該任務並生成PURGE請求，來向對應快取服務平臺，發起PURGE請求。在快取系統的配置裡，一般都會對PURGE請求的發起方的ip做限制，如果不做限制，那麼後果可想而知。

PURGE請求如果找到了檔案，並執行了刪除，那麼會收到200 OK。如果檔案還不存在，那麼會收到404 Not Found。這是一般快取伺服器預設的行為。

PURGE請求到達快取伺服器之後，處理流程在全半段跟GET類似，也是根據一定的方式去定位檔案（一般是用請求url的不同成分算出一個key），定位到檔案之後，PURGE請求就跟GET不一樣了。它會將檔案標記為deleted（快取裡都是非同步來實現淘汰的，因為當前要刪除的檔案，可能還有人在訪問，不能立即將相關資訊刪除。當檔案引用計數為0，並且狀態為deleted時，檔案自然會被系統幹掉），來淘汰掉一個檔案。

多副本問題

如果僅僅通過url的可以來PURGE檔案，那麼當存在多副本（同一url對應不同形式的檔案，最常見的是壓縮跟非壓縮）的情況下，就存在問題。所以對於快取存在多副本的情況下，有兩種處理方式，一種就是隻刪除特定副本（例如壓縮和非壓縮的某一種），一種情況就是刪除所有的副本。在實際運作過程中，第二種是預設的。如果處理第二種，那麼就需要在key匹配的基礎上做進一步的處理。在很多的簡單快取實現裡，多副本存放在某個hash表槽位的衝突鏈上（因為key相同），那麼在處理時就需要遍歷整個鏈，每個副本都需要刪除。

nginx的第三方purge模組在處理多副本的問題上存在缺陷，導致單純的使用url來purge會導致不同的副本不能被刪除乾淨。當然出現這個情況的前提是，nginx的快取開啟了vary功能，而該purge模組又沒有對vary提供必要的支援。對於nginx出現的情況，很多小夥伴在發PURGE請求時，都加入了相應的Accept-Encoding頭。這樣就可以清理相應的壓縮副本了。

關於多副本和Vary頭的問題，後面單獨來講吧

分散式問題

這個算是，更廣義上的多副本問題。一般CDN都存在多層結構，使用者直接訪問到的快取伺服器，叫做邊緣層，邊緣層到源站之間一般還有一到兩級的父層。層級越多，回源量就越少，隨之latency會增加。那麼當我們要刪除一個檔案，如果先PURGE了邊緣cache，那麼後續請求就會穿過邊緣cache到達父層，這時由於父層的舊檔案還存在，那麼邊緣又會將舊檔案取走，白忙活。所以面對這種帶有層級的快取架構，一般都是從父層往邊緣逐級PURGE檔案。

那麼所有的問題都解決了？不是。很多CDN的快取節點，邊緣也好，父層也好。都是有叢集的。比如幾臺機器做的叢集，假設有A,B,C,D四臺。一般快取伺服器都會做基於七層的一致性hash，來保證增刪叢集內的機器不會帶來過大的內容遷移。我們看一種情形，如果檔案1.html存在C機器，當C重啟下線，那麼這時你通過http向叢集（往往只是一個vip）發起PURGE請求來刪除1.html，由於C機器的下線，檔案在叢集內就不存在了。你收到404 Not Found，PURGR請求處理完成。隨後，C機器又活過來，重新加入了叢集。那麼舊的1.html檔案，又再次出現在系統內，便帶來了嚴重的問題。

上面討論的這個情景，在http協議下是無解的。必須引入其他的手段來處理。解決方案有很多，首先不能針對VIP發PURGE請求，要對每一個叢集機器內搜有機器的真實IP發PURGE。這樣就不會受叢集架構的影響，每個機器的執行情況可以得到。對應執行結果要有監控，狀態無非三種，成功（200 OK或者404 Not Found），失敗（其他非預期的響應碼），無響應（宕機了）。上層需要收集這些執行情況，並做彙總。這樣才可以保證檔案被徹底處理乾淨。

那麼，PURGE任務的下發和消費，比較好的方案，應該就是訊息隊列了。大家可以自行去研究。