Edit

• Web緩存核心技術點需知

• 5.1 HTTP首部控制

• 5.2 基于新鮮度檢測機制：

• 2.1 特征1：時間局部性

• 2.2 特征2：空間局部性

• 2.3 緩存的優點

• 2.4 哪類數據應該被緩存

• 2.5 哪類數據可緩存但不應該被緩存

• 2.6 緩存命中率決定緩存有效性

• 2.7 緩存數據生命周期

• 2.8 緩存處理步驟

• 2.9 緩存和普通數據讀取的區別

• 1. 完整請求流程中緩存設計

• 2. 緩存特征點

• 3. 智能DNS解析（CDN）

• 4. 常見的緩存工具實現

• 5. 常見緩存控制機制

• 6. 常見的HTTP首部字段類型

Web緩存核心技術點需知

序：
該文共約9800字（6章），前5章建議閱讀時長為8分鐘。第6章為知識點整理，可后續檢索回顧。
祝君愉快

近些年，互聯網基礎設備和技術迅猛發展，互聯網玩法日新月異，稍不留神就Out。整體網民的素質也在不斷提升的同時，對互聯網的體驗也提出了新的高度和要求，眾所周知智能背后意味著復雜，體驗好背后也意味著互聯網的架構越復雜。利益當先的前提下，最好的優化就是緩存，緩存在整個互聯網的發展過程中作用可想而知。尤其在中國如此蹩腳的網絡下，南電信北聯通，中間坑的都是付費的用戶和企業。越來越多的證明表明，網站訪問速度越慢，用戶流失的越快，要想加快網站訪問速度，基于此背景條件下，緩存和反向代理更顯的尤為重要。

1. 完整請求流程中緩存設計

從互聯網起始至今緩存都無處不在，從最前端的用戶側開始到服務器架構設計領域均在緩存的設計。
用戶一次完整的訪問簡易流程圖如下：

1.用戶端

系統
基于DNS緩存: 緩解DNS解析壓力，提高解析響應速度

瀏覽器
基于內容緩存: 根據已有規則與服務器交互過程中，非過期文件不再從服務器請求全新內容

DNS（CDN）
基于DNS：基于DNS的智能解析，將用戶的請求解析至距離用戶最近的CDN緩存服務器，圖片，樣式等靜態和常期不變的資源交由CDN響應，緩解RealServer壓力和高峰訪問擁塞。

2.企業端

硬LB
請求經防火墻過濾后，傳遞至后端硬LB服務器，再根據不同場景分發至后端* 軟LB*

軟LB
軟LB再次過濾拆分請求，動靜分離，靜態請求分離至靜態集群，動態請求分發至應用集群。

NoSQL（Cache）
NoSQL：Redis,Memcache,ZeroMQ等NoSQL的出現大大緩解了前端直接穿透對數據庫和分布式文件集群服務器的壓力。靜態文件讀取方面，Squid,Memcache,Varnish等緩存率理想情況下更高達80%以上。

大型成熟的高可用網站拓撲可參考如下-摘自網絡

2. 緩存特征點

并非所有的數據被緩存或需要緩存，緩存是為了解決20%數據被80%的人頻繁訪問的問題而生。數據如希望被緩存往往具備變化緩慢的特征。被緩存的數據往往具備如下特性：

2.1 特征1：時間局部性

緩存的數據往往被打有時間綴，具有定期失效的特征，過期后會從源服務器檢驗請求驗證是否需要重新拉取數據。
某數據被訪問后，該數據往往會再次在短時間內被訪問到。

2.2 特征2：空間局部性

被訪問數據的周邊數據被訪問的概率會比其它常規數據訪問大很多，所以這些訪問數據和其它周邊有可能被訪問的數據通過某種方式集中在一起，以提高數據的被訪問速度，減少數據查找時長。
完成這類功能的工具往往稱為Cache。

2.3 緩存的優點

緩存的優點無需贅述：
1. 節約帶寬
2. 緩存后端服務器請求穿透壓力
3. 降低時延，加速響應

2.4 哪類數據應該被緩存

1. 熱（區）數據：所謂熱（區）數據就是指經常被訪問到的數據，這類數據被緩存最有價值，緩存命中率高

2.5 哪類數據可緩存但不應該被緩存

1. 用戶賬號密碼信息等數據，該類數據不僅不應該被緩存，反而要被著重保護，這些年發生的撞庫，密碼破解等惡性事件，往往都是因為用戶個人不當心或企業安全意味不足，導致用戶敏感信息流失。

2.6 緩存命中率決定緩存有效性

緩存命中率=hit/(hit+mixx)
hit表示緩存被命中，miss表示沒有命中，也就是緩存項中沒有對應的資源
文檔命中率：從文檔命中的個數進行衡量
字節命中率：從內容命中的大小(字節)進行衡量

2.7 緩存數據生命周期

數據被緩存數并非永久緩存。根據業務所需和服務器容量及用戶行為，各類數據會定期被清理。如王寶強離婚事件，據說因此微博緩存用品橫向擴展一倍服務器來響應該突發熱點事件，但該熱點事情結束后這批服務器是需要下架以節約成本，同時因為熱點事件的結束，該時期的熱點詞及緩存數據將不再被緩存以做清理，該類清理往往需要手動清除，而對于靜態文件圖片，css等文件，則會設置定期清理，總結如下：

緩存清理策略： 1. 緩存項過期：緩存資源往往會被設置有效時長，過期自動清理或失效 2. 緩存空間用盡：緩存空間用盡時，會根據LRU（最近最小使用）算法清理緩存 3. 清理策略設置過長過短都不好，過長數據容易陳舊，過短起不到緩存效果

2.8 緩存處理步驟

2.9 緩存和普通數據讀取的區別

緩存數據是K/V數據，即key/value，緩存的存儲方式一般是以文件到的MD5碼的前某些字符為鍵，做為存儲目錄，存儲目錄一般是多級的，其值則可能是整個MD5碼，也可能時MD5碼減去key所用的字符

k/v存儲的好處是檢索速度速度快，具有冪等性，此處的冪等性指的是，無論查找多少次所消耗的時間都是一樣的。

3. 智能DNS解析（CDN）

“緩存最好的實現方式莫過于CDN”
各軟件緩存功能實則已是用戶請求的最后一環，要想尤佳的體驗，CDN是無上之選，智能解析可以做到將用戶的請求解析到離用戶最近的緩存服務器，緩存命中則直接返回給客戶端，若不命中，有可能請求離自己最近的緩存服務器，而不是直接請求真實的服務器，因為緩存服務器往往是形成一個網絡

對于國內的分裂網絡(電信，聯通，移動)，CDN可以判斷用戶來自于哪各運營商的網絡，解析請求到相應網絡的服務器主機，前提時需要提供web服務運營商需要在不同的的電信運營商部署服務器

GSLB：Globle Servive Load Balance 全局服務負載均衡
部署專用的一臺主機，調度用戶請求到離用戶最近緩存服務器。
有全局也有就局部負載均衡，局部服務負載均很器作用是調度本地緩存服務器

4. 常見的緩存工具實現

squid&varnish
基于http協議提專業的供緩存控制的程序有squid和varnish，squid比較重量級，是個老家伙，不過，老當益壯，而varnish比較輕量，性能和穩定性于squid不相上下

nginx&httpd
nginx和httpd做為提供web服務的程序，同時也提供了簡單的緩存功能，一般在條件允許都因該使用專業的緩存控制軟件，而不使用自帶的緩存功能

5. 常見緩存控制機制

5.1 HTTP首部控制

過期日期（Expires）:

首部格式：Expires:Fri, 20 May 2016 02:03:18 GMT

HTTP1.0版本使用的緩存控制，在響應報文加上Expire首部定義資源的有效日期，其定義的時間為絕對時間，此中控制方式會出現時區差產生的問題

Cache-Control:

首部格式：Cache-Control: max-age=600

HTTP1.1版本才添加的緩存控制機制，其在請求報文或響應報文首部添加一個cache-control的首部，用于定義資源的緩存最大時長，是相對于響應報文首部中的date首部定義的時間。
一般響應報文首部會同時有Expires首部和Cache-control首部

Cache-Control首部相關指令：

cache-request-directive=no-cache 不接受緩存響應
                                no-store 不緩存在本地
                                max-age  緩存最大有效時長       
                                min-fresh        cache-response-directive=public                                 private                                 no-cache                                 no-store                                 must-revalidate
                                 max-age
        no-cache：可緩存，但用戶每次請求都需要先到上游服務器做緩存檢驗

請求報文緩存控制首部

用于發送請求報文時，明確提示所請求的服務器自己是否接收緩存數據或只接收哪類數據（這種情況可能無效，因為緩存代理可能時多級的，可能到了第一個緩存服務器就結束了）

響應報文緩存控制首部

用于發送響應報文時，明確標示響應的數據是屬于哪種類型

小結：基于過期時間的緩存控制，只要緩存命中且在有效期內，都將以緩存數據響應用戶，否則就請求上游服務器獲取資源

5.2 基于新鮮度檢測機制：

有效性再驗證：revalidate

用戶第一次請求的資源被緩存之后，當用戶再次請求時，緩存服務器會先與后端緩存服務器做緩存有效性校驗，就有如下情況：
(1)如果原始內容沒有發生改變，則僅響應首部，不響應body部分(響應碼304)
(2)如果原始內容發生改變，則正常響應(響應碼200)
(3)如果原始內容消失，則響應404

條件式請求首部

If-Modifified-Since: 基于原始內容的最近一次修改的時間戳進行驗證，如果發生改變，則200響應，否則304響應

If-Unmodified-Since: 基于原始內容的最近一次修改的時間戳進行驗證，如果沒有發生改變，則304響應，否則200響應

If-Match: 使用標簽(Etag)進行有效性檢驗，標簽吻合，說明內容沒有發生改變，以304響應此次的標簽可以理解為文件的校驗碼，只要文件發生改變，則校驗碼必定發生改變

If-None-Match: 使用標簽(Etag)進行有效性檢驗，標簽不吻合，則以200正常
響應，否則以304響應

********小結******** *(1)基于新鮮度檢測機制的緩存控制有個缺點，緩存服務器對于客戶端的每次請求，都要做有效性驗證，這樣雖然保證了響應客戶端的內容的新鮮度，但也造成了麻煩，所以就有了過期時間控制和新鮮度控制兩種控制機制的結合： *(2)只要緩存沒有過期，都以緩存內容響應用戶，若緩存過期，則需要向后端服務器做有效性驗證，如果原始內容沒有發生改變，則繼續以緩存內容響應用戶，若原始內容發生改變，則取得原始內容先緩存再響應客戶端 *(3)其實瀏覽器也會將內容緩存在本地，用戶再次對同一資源請求時，瀏覽器和緩存服務器之間會基于標簽(**Etag**)進行有效性檢測，請求的內容沒有發生，則由瀏覽器緩直接響應，否則就以上述的各緩存控制機制給予響應

6. 常見的HTTP首部字段類型

• 通用首部字段（General Header Fields）: 請求報文和響應報文兩方都會使用的首部；

• 請求首部字段（Request Header Fields）: 從客戶端向服務器發送請求報文時使用的首部。補充了請求的附加內容，客戶端的信息，響應內容相關的優先級等信息。

• 響應首部字段（Response Header Fields）: 從服務器向客戶端返回響應報文時使用的首部。補充了響應的附加內容，也會要求客戶端附加額外的內容信息。

• 實體首部字段（Entity Header Fields）: 針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的信息。

HTTP常用首部字段預覽表

通用首部字段

請求首部字段

響應首部字段

實體首部字段

cookie服務首部字段

set-cookie字段屬性