WEB快取系統之varnish快取項修剪-有解無憂

　　前文我們聊了下varnish的狀態引擎和不同型別的變數對應該使用在那個狀態引擎中，以及每個狀態引擎的對應處理事務；回顧請參考https://www.cnblogs.com/qiuhom-1874/p/12643549.html；今天我們來聊一聊varnish的快取項修剪；

　　什么是快取項修剪？所謂修剪我個人的理解是把多余的部分或者不需要的部分洗掉掉；對于varninsh來講，快取項修剪也叫快取項洗掉；我們在varnish服務器上可以通過vcl語言來撰寫快取策略，對于某些快取該如何快取，快取多久等等；假如我們在定義好快取策略后，在定義快取過期時間內，后端服務器內容發生了變化，或者后端服務器發生了內容更新，我們如果不把varnish上的快取修剪掉，對于用戶來講，用戶的訪問就不是最新的資料；為了解決這樣的問題，我們需要人工手動的去修剪快取項；而修剪快取項一般都是針對某一類資源或特定資源來做修剪（通過用戶指定或正在匹配），一般不會也不應該是全部；在varnish中，修剪快取的方式有兩種，一種是vcl_purge狀態引擎修剪（通過判斷用戶的某些請求首部特征，來對用戶指定的資源進行修剪），一種是內部函式ban()來修剪快取（通常在命令列執行ban命令修剪快取）；

　　首先我們來看看varnish的默認配置中如何定義vcl_purge這個狀態引擎的；

[root@test_node1-centos7 ~]# varnishadm -S /etc/varnish/secret -T 127.0.0.1:6082 "vcl.show -v boot"|grep -A3 purge
sub vcl_purge {
    return (synth(200, "Purged"));
}

[root@test_node1-centos7 ~]#

　　提示：從上面默認配置中可以看到對于vcl_purge的配置很簡單；以上配置表示如果上一個狀態引擎把報文送給purge這個狀態引擎后，purge狀態引擎的操作就是把對應報文送給synth()，并合成一個200的回應碼，訊息狀態是purged的合成頁面回應給客戶端；以上就是告訴客戶端快取項修剪成功；

　　了解了purge的處理機制后，我們在來看看快取項的修剪應該在那個狀態引擎中定義；通常在接收到用戶請求后，就需要修剪快取；這樣用戶才可以拿到最新頁面；所以我們在定義快取的修剪操作應該在vcl_recv中定義；比如判斷用戶的請求方法，如果用戶請求的方法是我們自定義的請求方法，我們就把這類請求直接交給purge處理；

　　提示：紅框中的內容就是來判斷用戶的請求方法，如果請求方法是“PURGE” 那么就把對應的請求交給purge去處理；

　　測驗：用curl命令指定特定的請求方法去訪問varnish對外提供的頁面；通過判斷回應報文中，之前我們定義的X-Cache首部的值來判斷是否命中快取；如果我們使用了purge方法后，第二次正常方式訪問應該是miss的，第三次訪問時hit就表示修剪快取項成功；

[root@test_node1-centos7 ~]# varnishadm -S /etc/varnish/secret -T 127.0.0.1:6082
200        
-----------------------------
Varnish Cache CLI 1.0
-----------------------------
Linux,3.10.0-693.el7.x86_64,x86_64,-sfile,-smalloc,-hcritbit
varnish-4.0.5 revision 07eff4c29

Type 'help' for command list.
Type 'quit' to close CLI session.


varnish> vcl.load test default.vcl
200        
VCL compiled.

varnish> vcl.use test
200        
VCL 'test' now active

varnish> quit
500        
Closing CLI connection
[root@test_node1-centos7 ~]# curl  -I http://192.168.0.99:8000
HTTP/1.1 200 OK
Date: Thu, 09 Apr 2020 04:57:49 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips
Strict-Transport-Security: max-age=31536000
Last-Modified: Tue, 31 Mar 2020 14:56:54 GMT
ETag: "2f-5a227c743121d"
Content-Length: 47
Content-Type: text/html; charset=UTF-8
X-Varnish: 65541
Age: 0
Via: 1.1 varnish-v4
X-Cache: miss via 192.168.0.99
Connection: keep-alive

[root@test_node1-centos7 ~]# curl  -I http://192.168.0.99:8000
HTTP/1.1 200 OK
Date: Thu, 09 Apr 2020 04:57:49 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips
Strict-Transport-Security: max-age=31536000
Last-Modified: Tue, 31 Mar 2020 14:56:54 GMT
ETag: "2f-5a227c743121d"
Content-Length: 47
Content-Type: text/html; charset=UTF-8
X-Varnish: 32772 65542
Age: 3
Via: 1.1 varnish-v4
X-Cache: hit via 192.168.0.99
Connection: keep-alive

[root@test_node1-centos7 ~]# curl -X "PURGE" http://192.168.0.99:8000
<!DOCTYPE html>
<html>
  <head>
    <title>200 Purged</title>
  </head>
  <body>
    <h1>Error 200 Purged</h1>
    <p>Purged</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 65544</p>
    <hr>
    <p>Varnish cache server</p>
  </body>
</html>
[root@test_node1-centos7 ~]# curl  -I http://192.168.0.99:8000       
HTTP/1.1 200 OK
Date: Thu, 09 Apr 2020 04:58:11 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips
Strict-Transport-Security: max-age=31536000
Last-Modified: Tue, 31 Mar 2020 14:56:54 GMT
ETag: "2f-5a227c743121d"
Content-Length: 47
Content-Type: text/html; charset=UTF-8
X-Varnish: 32774
Age: 0
Via: 1.1 varnish-v4
X-Cache: miss via 192.168.0.99
Connection: keep-alive

[root@test_node1-centos7 ~]# curl  -I http://192.168.0.99:8000
HTTP/1.1 200 OK
Date: Thu, 09 Apr 2020 04:58:11 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips
Strict-Transport-Security: max-age=31536000
Last-Modified: Tue, 31 Mar 2020 14:56:54 GMT
ETag: "2f-5a227c743121d"
Content-Length: 47
Content-Type: text/html; charset=UTF-8
X-Varnish: 32777 32775
Age: 3
Via: 1.1 varnish-v4
X-Cache: hit via 192.168.0.99
Connection: keep-alive

[root@test_node1-centos7 ~]#

　　提示：我們用purge方法去請求對應資源后，再用正常的get方法去獲取資源，對應回應報文首部X-Cache的值就變成miss的，說明沒用從快取中命中；再次訪問X-Cache的值變成hit，說明從快取中命中，這是因為第一次快取修剪后，第二次訪問就把該資源快取到varnish上，再次訪問varnish就直接從快取中給我們回應；

　　其實通過請求方法來判快取項是否該修剪，其實很危險的；就以上面的配置，任何人都可以通過purge方法去修剪快取，這很顯然是不能也不應該的；所以我們還需要限定那些用戶可以執行purge方法去修剪快取；在varnish中添加訪問控制法則需要用acl關鍵指定，然后起一名稱，把對應的ip地址或網段地址寫進去；如下

　　提示：以上就表示定義了一個訪問控制法則，其名稱叫做allow_purge_method_clients；其中這里面寫ip地址需要用雙引號引起來，并用分號結束；對于網段地址掩碼位數需要寫在雙引號外；

　　定義好訪問控制規則后，我們在原有的判斷用戶請求方法中加入限定IP地址的操作；

　　提示：以上紅框中的內容表示如果用戶請求的方法是PURGE，IP地址不匹配我們指定的ip地址法則，那么就回傳合成403回應碼給客戶；如果匹配就執行purge操作；

　　測驗：用192.168.0.99這臺主機用"PURGE"方法請求修剪和用192.168.0.22這臺主機用"PURGE"方法修剪快取，如果我們定義的快取策略正確的話，第一臺主機應該是可以修剪快取的，第二臺主機會提示不運行修剪快取，回應403;

　　提示：從上面的示例可以看到通過不同ip的主機對varnish發起“PURGE”方法修剪快取，在自定義訪問控制法則中存在的IP就可以通過“PURGE”方法來修剪快取，相反不再acl控制發展中的IP地址主機，就不被允許修剪快取；

　　以上是通過撰寫vcl來判斷用戶的請求方法實作快取修剪，除此之外varnish還支持內建命令ban來修剪快取;接下來我們來看看用內建命名ban怎么修剪快取；

　　首先我們可以來查看下ban命令的用法；

　　提示：以上就是ban命令的用法，其中field表示用戶請求的某些首部，比如req.http.host、req.url等；operaror表示運算子，arg表示引數；

　　示例：修剪用戶請求資源是index.html內容

　　提示：以上紅框中的內容就相當于判斷用戶請求的url，如果匹配/index.html，就return(synth(200));意思就是說對用戶請求的/index.html的快取項進行修剪（洗掉）；所以用戶再次訪問該URL就不會從快取回應；

　　測驗：

　　提示：把/index.html的快取項修剪以后，用戶再次訪問到/index.html資源時，從回應首部就可以知道它沒有被快取命中；說明快取項修剪時成功的；

　　當然在命令列中可以直接使用ban命令修剪快取，在組態檔中，我們也可以來使用ban函式來對快取項進行修剪；如下

　　提示：以上紅框中的內容表示用戶的請求方法是BAN 就執行ban("req.http.host == " + req.http.host + "&& req.url ==" + req.url)，然后通過synth()合成一回應碼為200的頁面回應給用戶；這里的ban函式引數部分就是一字串合成；如果用戶請求的host是192.168.0.99 ,url是/index.html;那么ban函式引數部分就是req.http.host == 192.168.0.99:8000 && req.url == /index.html ，就相當在命令列執行ban req.http.host == 192.168.0.99:8000 && req.url == /index.html ；這里特別提示“&&”和 “==”號兩邊必須要有空格，否則會把&&識別成req.http.host的值的一部分；

　　測驗

　　提示：我們在組態檔利用判斷用戶請求的方法來修剪快取項，這種方式同PURGE的方式類似，都需要用acl去控制可以執行修剪操作的客戶端；通常情況下我們如果是臨時修剪快取項，用ban命令在命令列修剪，很少寫在組態檔中，通過特定的請求方法去修剪特定的資源快取；而PURGE和ban相反，PURGE常用于在組態檔中用特定的請求方法修剪指定的url資源快取項；

轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/110694.html

標籤：Linux

上一篇：awk之NR==FNR，如何理解整理

下一篇：debian10切換國內源