第十五週學習內容：keepalived和varnish
第十五週作業：
1、簡述HA cluster原理。
集羣中存在着多個單點，如調度器、session server、NFS等，他們的宕機會導致整個集羣不可用。解決辦法就是高可用集羣（HA cluster），將多臺能夠提供相同服務的主機組成一個組，活動中的主機不停將自己還在服務的信息以某種協議同步給備用主機。工作正常時相安無事，一旦活動主機發生故障，則會將活動主機提供服務所需的資源轉移到備用主機上，這個過程叫做失效轉移，也叫故障轉移。在開源領域，高可用集羣的解決方案有很多，keepalive、heartbeat、Corosync等。
keepalived在設計之初就是爲lvs服務的，可爲其提供高可用和健康監測，其工作原理是利用網絡中的vrrp協議，建立一個虛擬IP地址，背後是真正的物理接口，多臺主機的多個物理接口共享同一個虛擬IP地址，主機中有主有被，通過優先級來決定。虛擬IP地址一直在主服務器上，有其向外提供服務，一旦主設備發生故障，備機將會把虛擬IP地址搶佔過來，從而改由備機提供服務。在配置過程中還可以定義是否搶佔，主備，優先級和優先級懲罰等多種屬性。
heartbeat和Corosync是另外一種架構，基於分層的高可用集羣。最底層叫資源層也被稱爲心跳層，用來確保各臺主機狀態是否正常，可以互相通信傳遞心跳信息。上面一層叫做資源管理層crm，用來配置策略，決定哪些資源被監控，當活動主機發生故障要傳遞哪些資源等，但這一層是無法在不同主機之間通信的，也不能對主機作出具體的更改，算是中間層，決策層。再往上一層叫本地資源管理層lrm，通過ra資源代理調用一個個外部指令做出具體更改。
2、keepalived實現主從、主主架構。
keepalived是vrrp協議的具體實現，簡單來說就是可以做到地址流動，可以爲虛擬IP地址所在節點生成ipvs規則，爲後端real server做健康狀態檢測，還可以基於腳本調用接口通過執行腳本完成腳本中定義的功能。keepalived就存在base倉庫，主配置文件是/etc/keepalived/keepalived.conf，配置文件可分爲三部分：全局配置、VRRP配置、LVS配置。
keepalived實現主從配置：主服務器配置
從服務器配置，主要區別在state、priority這兩個配置。
現在將兩臺主機的keepalived服務啓動起來，並準備兩張主頁且啓動http服務，嘗試訪問虛擬地址主頁。
發現訪問的是主設備，現在把主設備的http服務關閉了。
再去訪問該主頁，自動就切換到備機了。
keepalived實現主主配置：在主從設置中，大多數情況下是一臺主機一直處於活動，一臺主機一直處於閒置。爲了避免浪費可以使用主主配置，就是再定義一個實例，加一個虛擬地址，將前一個實例中的主服務器定義爲備用，再將備用主機定義爲主，再基於DNS實現域名的負載均衡。
主服務器配置
備用服務器配置
這樣基於兩個不同的地址，將訪問兩臺不同的主機。
當其中一臺主機發生宕機，則會兩個地址都去往同一臺可用主機。
3、簡述http協議緩存原理及常用首部講解。
緩存的名詞解釋爲數據交換的緩衝區，緩存能夠生效是因爲程序的運行具有局部性特徵：時間局部性，一個數據被訪問過之後，可能很快再次訪問；空間侷限性：一個數據被訪問時，其周邊的數據也有可能被訪問到。
以web站點爲例，緩存的數據庫數據成爲datacache，緩存的PHP資源稱爲opcode。緩存的上線並不是立即生效的，是需要熱身，瞭解哪些是需要緩存的，這一過程短則1,2個小時，長則1天。所以在生產環境中，會用線上數據去做壓測，將熱身過程在上線前完成，緩存上線後即可立即生效。
緩存空間肯定是小於實際存儲空間的，當緩存空間滿了以後，可根據LRU（最近最少使用規則）清理緩存。可自己定義緩存保留時長，當過期後即使緩存空間未滿也會清理。
緩存的目的是爲了加速訪問，而一直不被訪問就叫有效性很差，有效性的評估方法叫命中率：hit/（hit+miss），有頁面命中率、字節命中率等。緩存是有多級結構的，用戶本地緩存叫做private cache，每一層的反代也都會有各自的緩存叫做public cache。
緩存服務器也有兩種組織形式，最常見的就是反代，接收到用戶請求，查找本地緩存，沒找到在反代給後端服務器，等待後端服務器響應後自己也緩存一份，web服務都是以這種形式組織的；還有一種叫做旁掛式緩存，接收到用戶請求，查找本地緩存，沒找到就告訴用戶沒有緩存，用戶再重新發請求找真正的後端服務器，此種方式所有的選擇權都在用戶這邊，memcache就是這種架構。
http協議的緩存機制：http1.0時代，通過響應報文首部Expires來控制，記錄的是絕對時間，表示給用戶的響應多久以後會過期，是單純的以時間爲衡量標準，如果有時差的話會出現收到響應報文緩存已經過期的情況，這樣的話緩存根本無法發揮作用。到了http1.1時代，可以通過cache-control來進行控制了，該首部中記錄了很多內容，如maxage，也是過期時間，但用的是相對時間，以秒爲單位，可用於所有緩存，這樣就避免了收到即過期的情況；s-maxage，同樣是過期時間，僅用於公共緩存，且會覆蓋maxage；no-cache表示即使被用戶緩存，用戶在請求時也要做有效性驗證；no-store表示不能緩存；public表示可用於所有緩存；private表示僅用於私有緩存等。除了基於時間作爲控制緩存的機制以外，http1.1還引入了條件式控制，Last-Modified定義了自從多久沒更新，會向後端服務器發起驗證，驗證該緩存是否依然可用，當響應碼爲304時，表示可以繼續使用；當響應碼爲200時，表示不可繼續使用同時新的響應資源會被送達；ETag定義了已緩存文件的校驗嗎作爲判斷，兩種方式可結合起來使用。
4、簡述回源原理和CDN常見多級緩存 。
回源原理：回源是指瀏覽器在發送請求報文時，響應該請求報文的是源站點的服務器，而不是各節點上的緩存服務器，那麼這個過程相對於通過各節點上的緩存服務器來響應的話就稱作爲回源。回源的請求或流量太多的話，有可能會讓源站點的服務器承載着過大的訪問壓力，進而影響服務的正常訪問。
CDN：Content Delivery Network，內容分發網絡，其搭建的思路是儘可能避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，儘量使內容傳輸的更快更穩定。CDN通過在網絡邊緣部署邊緣服務器，依靠CDN中心平臺的負載均衡、內容分發及調度等功能，使用戶就近獲取所需的內容，降低網絡擁堵，提高用戶訪問響應速度和命中率。所以基本上CDN就是廣泛採用各種緩存服務器，使得用戶的請求直接由這些緩存服務器響應，加快了響應速度；只有在用戶請求的資源在緩存服務器上沒有找到或者請求訪問的資源在源站點服務器上已經修改過的情況下，緩存服務器纔會去訪問源站點服務器以獲取最新的資源。
在CDN系統中，直接面向用戶，負責給用戶提供內容服務的的Cache設備都部署在整個CDN網絡的邊緣位置，所以將這一層稱爲邊緣層。而中心層負責全局的管理和控制，同時也保存了最多的內容Cache。在邊緣層設備未能命中Cache時，需要向中心層設備請求；而中心層未能命中時，則需要向源站請求。不同的CDN系統設計存在差異，中心層可能具備用戶服務的能力，也可能只會向下一層提供服務。如果CDN系統比較龐大，邊緣層向中心層請求內容太多，會造成中心層負載壓力太大。此時，需要在中心層和邊緣層之間部署一個區域層，負責一個區域的管理和控制，也可以提供一些內容Cache供邊緣層訪問。
CDN邊緣節點緩存策略因服務商不同而不同，但一般都會遵循http標準協議，通過http響應頭中的Cache-control: max-age的字段來設置CDN邊緣節點數據緩存時間。當客戶端向CDN節點請求數據時，CDN節點會判斷緩存數據是否過期，若緩存數據並沒有過期，則直接將緩存數據返回給客戶端；否則，CDN節點就會向源站發出回源請求，從源站拉取最新數據，更新本地緩存，並將最新數據返回給客戶端。
這一段完全靠百度......
5、varnish實現緩存對象及反代後端主機。
varnish是一款高性能、開源的反向代理服務器和緩存服務器。Varnish使用內存緩存文件來減少響應時間和網絡帶寬消耗。由於varnish先進的設計理念，性能要比古老的緩存服務器squid高上許多，varnish還可以通過端口進行管理，使用正則語句做到清除指定緩存的功能，這些squid都做不到。但是varnish在高併發的情況下，資源消耗較高，而且varnish服務進程一旦崩潰，重啓，內存中的緩存數據將全部丟失。
VCL：是一種專用的配置語言，在報文到達用戶空間後也會有一道道的關卡，被稱爲狀態引擎，可以用iptables中的鏈去類比思考，在每個狀態引擎上可以配置各種緩存規則，並且要在最後使用return()函數指明下一個狀態引擎，引擎之間是彼此隔離的，但又存在相關性。在配置文件中每個狀態引擎對應一個配置段，叫subroutine，子例程。默認配置文件中看不到任何配置，但在varnishadm命令行界面中使用vcl.show -v即可查看到有些已經做得隱藏配置並且是不能修改的。
狀態引擎：從收到用戶請求開始，先經過vcl_recv，如果可查看緩存則送往vcl_hash，如果是根本不認識的METHOD，根本不理解此請求報文則送往vcl_pipe作其它處理，如果METHOD是PURGE（修剪）則送往vcl_purge，再經過vcl_synth，將響應碼與響應內容合成以後響應給客戶。而可查緩存內容到達vcl_hash之後，查看hash表，命中則送往vcl_hit，未命中則送往vcl_miss。正常情況下vcl_hit會將緩存內容通過vcl_deliver響應給用戶，但如果緩存文件過期或者設有條件式控制機制則會將報文發送至vcl_pass，而vcl_miss的下一步也是vcl_pass。vcl_pass會將報文送到專門的後臺工作線程vcl_backend_fetch，不可響應的分到vcl_backend_error，可響應的分到vcl_backend_response，最終送達vcl_deliver，結束！除此之外，還有兩個特殊的狀態引擎：vcl_int，在處理任何請求之前先執行的vcl代碼，用於初始化；vcl_finl，在所有請求處理完畢後用於清理。
內建函數和變量：return()，指明下一步到哪個引擎上；hash_data()，指明對哪個數據做哈希運算。varnish一般會接觸到四種報文，分別爲用戶發來的請求，後端服務器的響應以及自己發給用戶的響應和發給後端服務器的請求，只有後兩種報文可以進行修改。req.*表示由客戶端發來的請求報文相關屬性值；bereq.*表示自己發往後端服務器的請求報文相關屬性值；beresp.*表示後端主機發給我的響應報文相關屬性值；resp.*表示由我發給客戶端的響應報文相關屬性值；obj.*表示存儲在本地緩存空間的緩存對象的屬性；server.*表示varnish服務器的屬性；client.*表示用戶的相關屬性。而在這些分類中經常會用到的變量有bereq.和req.request：請求方法；bereq.url：請求的url；bereq.proto：請求的協議版本；bereq.backend：指明要調用的後端主機；req.url:請求的url；req.http.Cookie：客戶端的請求報文中Cookie首部的值； req.http.User-Agent：瀏覽器類型；beresp.和resp.status：響應的狀態碼；reresp.proto：協議版本；beresp.backend.name：BE主機的主機名；beresp.ttl：BE主機響應的內容的餘下的可緩存時長；obj.hits：此對象從緩存中命中的次數；obj.ttl：對象的ttl值；server.ip和client.ip：主機和客戶端IP地址。
varnish實現緩存對象及反代後端主機：
在default.vcl中定義一個內建變量obj.hits，用於保存某緩存項的從緩存中命中與否，爲了之後的顯示更直觀。
進入varnish的命令行接口，載入default.vcl配置
再次訪問主頁時，在響應報文首部就多了XX報頭，並且顯示緩存是否被命中
強制對某類資源的請求不檢查緩存，這需要在recv段中配置
在不載入配置時，訪問/admin路徑
載入配置，別忘了要啓動
再次進行訪問，就顯示miss狀態，且不管刷新幾次都是miss，不會命中
使用curl命令發送請求，直接不用緩存響應，且返回403響應碼，依然是在recv段中配置
載入配置以後，使用curl命令進行訪問
由於時間的關係，還有兩個示例在下週進行補充。