先看一下策略調整後瞬間的流量圖：
為了提高使用者體驗，增大快取放大比，同時又要避免客戶報障，在做cache時可謂是煞費苦心，大檔案、小檔案分離，在小檔案裡又把動態內容和靜態內容分離，能存的東西基本上全部存了，唯有動態內容一直沒下手，按照之前的策略，動態內容直接**，1:1的進出，可是某些局方就是不消停，非要達到某個放大比，沒折了，在動態內容裡面動一下刀吧。
在動刀之前，先做分析，對能存的動態內容和ats的快取策略做了大量測試，受益匪淺。當前ats的快取策略完全按照http協議規定，採用最保守的快取方式，即只對有明確生命週期快取頭的資訊進行儲存，動態、cookie、authorization、no-cache一律不存，ats中對應的配置引數就不寫了。為了保證質量，直接把帶cookie、和授權的動態內容略過了，原因就是風險太大，剩餘的有這幾類可以嘗試：
1、有明確生命週期頭的動態url等內容；（我們假設**的頭資訊是可信的）
2、沒有明確頭生命週期頭的靜態url、動態url等，包括沒有任何資訊的或只有last-modified頭的等資訊。
對於第1類，很好處理，ats有相應的引數，開啟即可：
對於第2類，處理起來，就是個技術活了，首先線上對於頭資訊的必要條件是：
只有放開對這個的限制，才能把第2類給納括進來，所以把其設定為0是第一必要，設定好後怎麼保證其正常服務呢，比如說驗證碼，他在設定的時候就是沒有頭資訊，保守的策略肯定是正常服務，但這麼一放開肯定報障。經分析，ats對於沒有頭資訊內容的快取時間走的是最大最小快取時間來確保的，兩條時間引數如下:
對於只有last-modified頭的資訊是通過老化因子計算出來的，老化因子引數如下：
終於算是乙個小圓滿，並不是線上的引數就這麼穩定了，後續根據業務情況還是需要調整測試的的，不過這也是樂趣所在吧。
所有的調整是乙個平衡，當前的調整：1、增加了磁碟讀寫io；2、增加了cpu的負載。
本文出自 「奔跑的linux」 部落格，請務必保留此出處
ATS快取資料結構
httptunnel類 資料傳輸驅動器 data transfer driver 包含乙個生產者 producer 集合，每個生產者連線到乙個或是多個消費者 comsumer 隧道 tunnel 處理事件和緩衝區以便資料能從生產者移動到消費者，資料會盡可能儲存在引用計數型別的緩衝區中。只有資料發生變...
ATS快取資料結構
httptunnel類 資料傳輸驅動器 data transfer driver 包含乙個生產者 producer 集合，每個生產者連線到乙個或是多個消費者 comsumer 隧道 tunnel 處理事件和緩衝區以便資料能從生產者移動到消費者，資料會盡可能儲存在引用計數型別的緩衝區中。只有資料發生變...
HTTP 快取策略
瀏覽器一般快取 css js等靜態檔案，因為這些檔案的更新頻率相對來說比較低，合理利用瀏覽器的快取對 的效能提公升有很大幫助。http快取分為兩部分，分別是本地快取和快取協商，當本地快取不生效時會啟用快取協商。http快取主要由http協議的頭 header 資訊來制定。本地快取 本地快取是指瀏覽器...