nginx proxy_cache 緩存配置

前言:

由於本人工作原因,涉及到網絡直播領域,其中視頻的回放下載,涉及到了一些視頻下載方面的技術。針對於一個完整視頻的下載,目前市面上的主流做法是,先將整個視頻流切片,存儲到文件服務器中,在用戶需要觀看回放視頻時。通過一個視頻回源服務器,去文件服務器中逐個請求切片,返回給用戶播放。

今天着重探討的是關於回源服務器緩存的配置以及合理的緩存策略。

通過給回源服務器配置緩存的案例,詳細講解一整套緩存配置機制,並且可沿用到其他任何緩存配置場景中。


今天的講解分爲四點:

  • 回源服務器的工作是啥

  • 爲啥需要給回源服務器加緩存

  • 如何配置緩存

  • 如何針對業務場景配置完備的緩存機制


回源服務器的工作:

回源服務器在下面敘述中簡稱:源站

如圖所示,在文件下載的過程中,橫跨在cdn與文件服務器之間,作爲下載樞紐。



源站架構:源站是nginx+PHP的webserver架構,如圖所示:



但如果源站只是簡單的收到請求,然後下載資源,再返回,勢必會存在以下幾點不夠優化的問題:

1、cdn可能存在多次回源現象

2、源站對同一資源的多次下載,存在網絡流量帶寬浪費,以及不必要的耗時。

所以爲了優化這些問題,需要給源站做一層緩存。緩存策略採用nginx自帶的proxy_cache模塊。


proxy_cache原理:

proxy_cache模塊的工作原理如圖所示:



如何配置proxy_cache模塊

在nginx.conf文件中添加如下代碼:

[plain] view plain copy

  1. http{  

  2.     ......  

  3.     proxy_cache_path/data/nginx/tmp-test levels=1:2 keys_zone=tmp-test:100m inactive=7d max_size=1000g;  

  4. }  

代碼說明:

proxy_cache_path緩存文件路徑

levels設置緩存文件目錄層次;levels=1:2表示兩級目錄

keys_zone設置緩存名字和共享內存大小

inactive在指定時間內沒人訪問則被刪除

max_size最大緩存空間,如果緩存空間滿,默認覆蓋掉緩存時間最長的資源。


當配置好之後,重啓nginx,如果不報錯,則配置的proxy_cache會生效


查看  proxy_cache_path /data/nginx/目錄,

會發現生成了tmp-test文件夾。


如何使用proxy_cache

在你對應的nginx vhost server配置文件中添加如下代碼:

[plain] view plain copy

  1. location /tmp-test/ {  

  2.   proxy_cache tmp-test;  

  3.   proxy_cache_valid  200 206 304 301 302 10d;  

  4.   proxy_cache_key $uri;  

  5.   proxy_set_header Host $host:$server_port;  

  6.   proxy_set_header X-Real-IP $remote_addr;  

  7.   proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;  

  8.   proxy_passhttp://127.0.0.1:8081/media_store.php/tmp-test/;  

  9. }  

配置項介紹:

Proxy_cache tmp-test 使用名爲tmp-test的對應緩存配置

proxy_cache_valid  200 206 304 301 302 10d;httpcode200…的緩存10

proxy_cache_key $uri 定義緩存唯一key,通過唯一key來進行hash存取

proxy_set_header 自定義http header頭,用於發送給後端真實服務器。

proxy_pass 指代理後轉發的路徑,注意是否需要最後的/


到這裏,最基本的proxy_cache功能就配置成功了。當uri成功匹配到該location,則proxy_cache就會生效。


添加proxy_cache之後,請求過程的變化:

1、第一次訪問:



第一次訪問,proxy_cache並沒有找到對應的緩存文件(未命中緩存MISS),所以當第一次請求完成的同時,proxy_cache會保持緩存:

2、保存緩存,如圖所示:


3、同一個url第二次訪問,當同一個文件再次到達源站,proxy_cache就會找到其對應的緩存文件(命中緩存HIT)直接返回給請求端,無需再執行php程序,如圖所示:


提出疑問:

到此,就完成了最基本的proxy_cache配置和訪問過程介紹,但是最基本的配置,往往無法滿足我們的業務需求,我們往往會提出以下幾點疑問和需求:

  1. 需要主動清理緩存文件

  2. 寫入路徑爲一塊磁盤,如果磁盤打滿該怎麼解決?

  3. 如何讓源站支持斷點續傳,以及斷點續傳的緩存策略

  4. 如果請求端 range 請求(分片下載)一個大資源,同樣的uri,如何區別請求?

  5. 還需要告訴請求端,資源的過期時間

  6. 日誌統計,如何配置命中與不命中字段,如何做統計?

面對以上疑問,我們一個一個解決。


問題一:主動清理緩存

採用:nginx  proxy_cache_purge 模塊 ,該模塊與proxy_cache成對出現,功能正好相反。

設計方法:在nginx中,另啓一個server,當需要清理響應資源的緩存時,在本機訪問這個server。

例如:

訪問 127.0.0.1:8083/tmp-test/TL39ef7ea6d8e8d48e87a30c43b8f75e30.txt 即可清理該資源的緩存文件。

配置方法:

[plain] view plain copy

  1. location /tmp-test/ {  

  2.                 allow 127.0.0.1; //只允許本機訪問  

  3.                 deny all; //禁止其他所有ip  

  4.                 proxy_cache_purge tmp-test $uri;  //清理緩存  

  5.         }  

proxy_cache_purge:緩存清理模塊

tmp-test:指定的key_zone

$uri:指定的生成key的參數

proxy_cache_purge緩存清理過程,如圖所示:



問題二:緩存文件強磁盤打滿該怎麼辦?

由於寫入路徑爲一個單一目錄,只能寫入一塊磁盤。一塊磁盤很快就會被打滿,解決該問題有如下兩種方法:

1、將多塊磁盤做磁盤陣列? 缺點是:減小了實際的存儲空間。

2、巧妙得運用proxy_cache_path的目錄結構,由於levels=1:2,這導致緩存文件的目錄結構爲兩層,每層目錄名,都是由hash函數生成。如圖所示:


總共含有16*16*16=4096個文件目錄。對該一級目錄進行軟連接,分別將0-f軟連接到你所需要的指定磁盤目錄上,如圖所示:


通過軟鏈的方法,實現:將不同盤下的目錄作爲真正存放數據的路徑,解決了多盤利用,單盤被打滿的問題。


問題三:支持range(斷點續傳)

添加上緩存代理之後,客戶端發起的range請求將會失效,如下圖所示:


導致range參數無法傳遞到下一級的原因如下:

當緩存代理轉發http請求到後端服務器時,http header會改變,header中的部分參數,會被取消掉。其中range參數被取消,導致,後端nginx服務器沒有收到range參數,最終導致這個分片下載不成功。所以需要對代理轉發的header進行配置。

例如:

[plain] view plain copy

  1. location /tmp-test/ {  

  2.                 proxy_cache tmp-test;  

  3.                 proxy_cache_valid  200 206 304 301 302 10d;  

  4.                 proxy_cache_key $uri;  

  5.                 <span style="color:#ff0000;">proxy_set_header Range $http_range;</span>  

  6.                 proxy_pass http://127.0.0.1:8081/media_store.php/tmp-test/;  

  7. }  

紅色部分的含義:將http請求中的range值($http_range)放到代理轉發的http請求頭中作爲參數range的值。


問題四,當支持range加載後,proxy_cache_key,則需要重新配置:

如果請求端 Range請求(分片下載)一個大資源,同樣的uri,proxy cache如何識別資源對應的key。

由於nginx配置爲:proxy_cache_key $uri,用uri作爲key

所以當請求爲普通請求和range請求時,都是同樣的uri作爲key。proxy_cache將有可能導致錯誤返回。如下圖所示:


解決方法如下:

修改proxy_cache_key ,配置proxy_cache_key $http_range$uri;

這樣就能解決:key唯一性。可以避免不管是正常請求還是不同的range請求,第一次獲取的內容和之後獲取的緩存內容都不會出現異常。


問題五:如何配置-返回過期時間

需要通過返回過期時間來指定請求端,哪些資源需要緩存,哪些資源不緩存,



參數正常請求range請求
返回過期時間返回不返回

爲了防止請求端將分片資源當做完整資源緩存起來,我們需要對正常請求,返回過期時間;對range請求, 不返回過期時間。

解決該問題,通過對nginx配置即可解決:

[plain] view plain copy

  1. location /media_store.php {  

  2.      fastcgi_pass   127.0.0.1:9000;  

  3.      fastcgi_index  media_store.php;  

  4.      fastcgi_param  SCRIPT_FILENAME  $document_root/$fastcgi_script_name;  

  5.      include        fastcgi_params;  

  6.      if ( $http_range = ''){  

  7.           expires 2592000s;  

  8.      }  

  9. }  

在proxy_pass代理之後的location中加入對$http_range的判斷,expires 表示過期時間。 2592000s指緩存過期時間。


問題七:緩存命中情況如何在http頭中體現,以及在nginx日誌中查看

解決方法:

利用nginx $upstream_cache_status變量:該變量代表緩存命中的狀態,

如果命中,爲HIT;如果未命中,爲MISS

在返回nginx server配置中添加:

add_header  Nginx-Cache "$upstream_cache_status";

在nginxlog中添加:

log_format       combinedio  …$upstream_cache_status;

http返回head截圖:


nginx log日誌截圖:



總結:

整個一套完備的緩存策略就介紹到此,這套方案中不僅實現了基本的緩存配置,還解決了實際場景應用中會遇到的,磁盤擴展,緩存清理,斷點續傳,緩存過期時間,緩存命中提示等問題,只要將這套方案靈活運用,不管是再複雜的場景,基本都能滿足需求。以上都是我在工作中爬過的坑,不斷完善總結出的結果,希望對讀者能有幫助。


本文來自:http://blog.csdn.net/dengjiexian123/article/details/53386586

參考文章:http://freeloda.blog.51cto.com/2033581/1288553


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章