淺析 VANISH
--一種cache
第一部分：理解vanish的準備工作
1.對CDN的小剖析
CDN content delivery network 內容分發（推送）網絡，是在現有的Internet中增加一層新的網絡架構，將網絡內容發佈到最接近用戶的網絡邊緣（邊緣服務器），使用戶最近取得所需內容，解決網絡擁擠狀態，提高用戶訪問網站的速度。
CDN網絡架構主要有兩部分組成，中心和邊緣兩部分，中心指CDN網管中心和DNS重定向解析中心，負責全局負載均衡。邊緣主要指異地節點，CDN分發的載體，主要有cache和負載均衡器組成。
CDN網絡是經策略性部署的整體系統，包括分佈式存儲，負載均衡網絡請求的重定向和內容管理四個要件。
1.1分佈式存儲：
存儲系統採用三級儲存架構，包括核心存儲，節點分佈式緩存，和終端本地緩存。可見任意節點的崩潰都不會影響服務器的可用性。
1.2負載均衡：
負載均衡體現內容的路由功能，將用戶的請求發向最佳節點，可能是最近的，也可能是節點負載量最輕的。是CDN的核心，負載均衡的準確性和效率直接決定了CDN的效率和性能。負載均衡分爲全局負載均衡和本地負載均衡。
全局負載均衡以最近爲衡量目標，本地負載均衡，則考慮最佳，包括節點的健康情況，負載情況，支持的媒體格式。
負載均衡可以通過DNS，應用層重定向，傳輸層重定向等來實現。
對於全局負載均衡，可通過靜態的IP地址配置表來實現ip地址到CDN節點的映射和動態的監控CDN節點到目標ip的距離。
1.3內容管理：
內容管理和全局網絡流量管理是 是CDN的核心所在，內容服務基於緩存服務器，也叫做代理緩存，他是原服務器的一個透明鏡像，代理服務器在處理70---95%的訪問量，減輕服務器的壓力，提高服務器的性能和可擴展性。
1.4網絡請求的重定向：
當用戶訪問使用CDN服務的資源時，DNS域名服務器通過CNAME的方式，將最終域名請求重定向到CDN系統中的DNS負載均衡系統，智能DNS負載均衡系統將根據事先定義好的策略，將當時能夠最快響應用戶的節點提供給用戶。
1.5對CDN用戶訪問流程的總結:
用戶在瀏覽器輸入網站的域名，域名解析的請求被髮往網站的域名解析服務器，由於域名解析服務器對此域名解析設置了CNAME，請求被髮往CDN網絡中的智能DNS負載均衡系統，智能DNS負載均衡系統對域名進行智能解析，將響應速度最快的節點ip返回給用戶，然後用戶向節點發起訪問，由於是第一次訪問，節點會去原佔=站取用戶需要的數據併發給用戶，當再有用戶再次訪問時，CDN會將數據直接返回給用戶。DNS負載均衡均衡系統還與所有CDN節點保持通信，確保不把請求發給已經不可用的節點。
用戶》》》瀏覽器的DNS服務器》》網站的智能DNS負載均衡系統》》用戶》》》CDN節點。
1.6對CDN中部分用到的名詞的解釋
CNAME:
CNAME指別名記錄，也叫作規範名字，這種記錄允許將多個名字映射到一臺計算機上，當你有多個域名，並且想將他們指向同一個服務器IP時，可以將一個域名做A記錄指向IP，然後將其他域名做別名到之前做過A記錄的域名上，那麼你的服務器IP地址發生變化時，只需要改變做了A記錄的那個域名，其他別名域名指向也會指向新IP。
A記錄：
A記錄:主機名或者域名對應IP地址的記錄。
MX記錄：
MX記錄：記錄郵件的路由記錄，用戶可以將該域名指向到自己的mailserver上，然後就可以自行操作郵箱設置，只需在線填寫服務器的IP就可以將自己的郵件發送到郵件服務器上。
VCL ：
vanish配置語言。在執行VCL時vanish將VCL轉換成二進制代碼。VCL文件被分爲多個子程序，有些在接受到請求是執行有些在後端服務器傳送文件時執行。
Vanish將在不同的階段執行不同的代碼，一行一行執行，不存在優先級，隨時可以執行子程序的功能並且實行完就退出。如果到最後也沒找到你調用程序中的功能，vanish就會調用內建的代碼，也就是被註釋掉的代碼。
99%的機率，我們會修改vcl_recv和vcl_fetch這兩個子程序。
vcl_recv在請求開始被調用，在接受，解析後，決定是否響應請求，怎麼響應，使用哪個後臺服務器。在中間可以修改cookies，添加或者刪除請求的頭信息。這中間只有請求的目標，req is available。
vcl_fetch 在一個文件成功從後 臺獲取後被調用，他的任務就是改變響應的頭文件，觸發ESI進程，在後臺服務器嘗試輪詢嘗試失敗的請求。
在其中包含請求的目標，req available，這裏通常是backend response beresp.bere將會包含後端服務器的HTTP文件。
Action :
主要與以下動作;
Pass 請求將會通過vanish轉發到後端服務端，但是不會被緩存，可以放在 recv fetch中。
Lookup vanish將會從緩存中提取數據，如果緩存中沒有數據，將被設置爲pass。只在recv中可以設置。
Pipe 和pass類似，都會訪問後端服務器，在此鏈接未關閉之前，所有請求都將發送到後端服務器。
Delive 請求的目標被緩存，然後發給客戶端。
三個重要的數據結構:
Request 從客戶端進來
Responses 從後端服務器過來
Object 存儲在cache中
需要知道以下結構：
Req 請求目標，當vanish 接受到請求， req object就被創建了，在vcl中的大部分工作都是在req object上進行的。
Beresp 後端服務器返回的目標，他包含返回的頭文件信息，在vcl_fech中的大部分工作都在beresp object上進行。
Obj 被cache的對象，只讀的目標被保存在內存中，obj.ttl的值可以被修改，其他的只能讀。
Cookie 與session：
Cookie：存儲在用戶本地終端上的數據，是指某些網站爲了辨別用戶身份，進行session跟蹤而儲存在本地用戶本地終端上的數據，通常經過加密。Cookie是由服務器產生髮送給客戶端瀏覽器，，瀏覽器會將cookie的key儲存在某個目錄底下，下一次訪問同一服務器，就會發送此cookie給服務器，主要用途：註冊後，再次登錄會自動識別，服務器會根據cookie中的信息統計用戶訪問該網站的習慣，一方面可以提供個性化服務，另一方面，也可以作爲了解所有用戶的行爲的參考工具。對於網站的經營策略也有一定的參考價值。
當session第一次被啓用時，唯一標識就被保存在本地的cookie中。
一個session中中包含特定的用戶和服務器。
兩者區別：
Cookie是一種客戶端狀態服務技術，將狀態寫在瀏覽器端，session是一種服務器狀態管理技術，將狀態寫在web服務器上。
Cookie有很多限制，比如可以被用戶禁止，保存的數據比較小，不安全，只能保存字符串。而session更安全，數據類型更豐富。Session對服務器的壓力比較大。
第二部分：實踐操作
實驗環境：
一臺物理機配合三臺虛擬機，並且防火牆和selinux都關閉。
Ip：物理機172.25.0.250 172.25.254.0
虛擬機
172.25.0.1
172.25.0.2
172.25.0.3
開始：
2.1.安裝vanish：
在server1上做varnish cache
首先從172.25.0.254中獲得varnis的包，並安裝。
2.2配置：
####配置一個後端服務器：
切換到/etc/varnish目錄下，做：
指定varnish的後臺主機和端口。
#####在server2 3 上安裝httpd服務：
並開啓：
編輯http 服務默認發佈目錄，用於測試：
Vim index.html
<h1>server</h1>
####server1上配置vanish服務端口：
修改varnish 配置文件，將varnish監聽端口設置爲 80
Varnish配置完成後，開啓
也可以用此命令開啓：
查看端口會發現現在varnish對應着端口80端口，也就是別人通過http訪問我時，訪問的是varnish而不是我的Apache:
測試:
發現 顯示200 說明連接正常，並且可以通過80端口連接，連接的是varnish。
Curl 顯示域名或者IP指向的頁面如果URL指向是一個文件或者是一幅畫都可以直接下載到本地，如果是HTML文件將不顯示文件頭部，要顯示全部，-i；只顯示頭部-I。
Curl利用URL語法在命令行下工作的文件傳輸工具，支持文件的上傳和下載。
URL uniform resource locator 統一資源管理，又叫做網頁地址，只互聯網上標準的資源地址，互聯網上每個文件都有唯一的URL。它包含的信息指出文件的位置及瀏覽器該怎麼處理它，
上面的三張圖顯示，qq.com會直接訪問上海或者深圳的後端服務器。比較慢，如果訪問www.qq.com 會是西安，比較快，是因爲這是訪問西安的高速緩存器。
一會HIT 將會變成MISS 這是因爲緩存都有周期，現在緩存時間到了。就沒了。
####http的狀態碼;
http://sc.qq.com/fx/u?r=ogLIAkA
302代表 請求的資源臨時被不同的URL響應請求，由於重定向是臨時的，客戶端應該繼續向原地址發送請求。
然後就有連上了：
##下面是在linux下查看PDF文件：
Debin用apt-get
Red-hat 用yum 還可以用桌面自帶的evience，xpdf，okular。
###查看緩存命中情況：
/etc/varnish
重新加載：
或者：
檢測：
顯示MISS，可以查看緩存命中情況，沒有命中。
在查，就命中了。
命中後，age每次都在變，是因爲緩存都有自己的週期。
在server2 端修改默認發佈文件內容，
現在去查詢緩存，發現並沒有改變：
等到120秒過去後，緩存就更新了，就變成了修改後的server-2這個默認發佈內容，現在用瀏覽器檢測;
確實改變了。
現在我們想實現修改發佈目錄後不等120秒就能更新所以我們需要清除緩存
###手動清除緩存：
檢測：
清除所有後，現在週期又開始重新計算週期：
######定義多個不同域名的後端服務器，當訪問不同的域名時，從不同的web上取不同的數據。下面的實驗中，當訪問westos時,會取web1（server2）上的數據，當訪問bbs.org時會取web（server3）上的數據，訪問其他頁面會報錯：
重新加載varnish：
然後配置每個域名的默認發佈目錄，並檢測可以通：
當然爲了檢測方便，我們將server2和server3默認發佈目錄中做以改變：
檢測：
###定義負載均衡：
首先如果一個服務器組就只對應着一個域名，就有點資源浪費了，這就有了虛擬主機的產生。虛擬主機：簡單那的說就是一個服務器組，對應着多個域名。
此處，我們是在server3上做虛擬主機，來做www.westos.org的負載均衡：
#做虛擬主機：
編輯做負載均衡的虛擬主機的默認發佈文件：
server3
將另一個負載均衡主機默認發佈文件也改了：
加上本地解析檢測虛擬主機沒問題：
然後就是vanish的配置：
爲了檢測方便，我們不進行緩存：
而在實際中我們當然不會這麼做。
然後訪問www.westos.org時就會在兩個內容之間變化：
當然在實際中，同一網址的內容當然相同，這裏只是爲了辨別確實負載均衡了。
Vanish推送，應用在：當程序員改變一個文件的內容，或者是淘寶商家改變商品的售價，都需要及時的改變網頁的內容。
推送平臺用到了http來訪問，所以先安裝http再重啓，並且改變http默認的80端口，因爲80端口被vanish佔用了。
然後獲得bansys壓縮包，解壓，並將解壓後的文件放到Apache默認發佈目錄下面：
觀察到這些文件都是PHP結尾，所以應該需要安裝PHP軟件:
推送軟件，默認推送的是數據庫，所以，我們數據庫信息註釋掉：
還要定義主機列表：
這樣，訪問www.westos.org就可以指向0.1的6082端口，就會彈出推送的界面。
修改了http默認的發佈目錄中的文件，要重新開啓http;
這時，vanish有兩個端口可以訪問，80和6082http是8080端口。
然後我們去訪問0.1的8080端口：
然後推送，也就是將就緩存去掉，讓新內容進入緩存，就避免了清除所有緩存的問題，我們可以用推送直推送我們更新的東西，可以是文件，可以是一個目錄。
