第八章 反向代理緩存 第九章 Web組件分離 第十章 分佈式緩存
第八章 反向代理緩存
1.傳統代理
很久以前，我們通常需要通過代理服務器來訪問互聯網上的Web站點，代理服務器本身接入了互聯網，而我們通過內部網絡與代理服務器相連。即便是現在，有些時候爲了訪問一些由於某種原因無法直接訪問的站點，我們也會通過特定的代理服務器，繞過某些限制來訪問目標站點。
現在，我們普遍已經不使用代理服務器了，當我們的PC處於內部網絡時，網關會使用NAT（網絡地址轉換）技術，將PC的內部IP地址和網關的外網IP地址進行相互轉換，使得PC發出的請求可以順利到達外部網絡的Web服務器，同時將返回的數據正確地傳送給內部網絡的PC。
在某種意義上，NAT在這裏起到的作用等同於代理服務器，但是它們的不同在於，代理服務器工作在應用層，所以只有當它支持某個協議的時候纔可以轉發該協議的數據，而NAT工作在應用層以下，它可以透明地轉發應用層協議的數據，比如HTTP、FTP、SMTP等。
代理服務器還有安全性和HTTP過濾的等功能。
2.何爲反向
傳統代理服務器的特點，即用戶隱藏在代理服務器之後，那麼，反向代理服務器的特點便與此剛好相反，那就是Web服務器隱藏在代理服務器之後。我們將這種代理機制稱爲反向代理（Reverse Proxy），同時，實現這種機制的服務器，便稱爲反向代理服務器（Reverse Proxy Server）。
用戶的請求被代理服務器處理並轉發，是普通代理服務器，而服務器的響應，被代理服務器處理叫反向代理。
所以正向代理是處理用戶請求數據，將用戶隱藏，反向代理是處理服務器響應數據，將服務器隱藏。
那麼，反向代理的主要目的是什麼呢？有一點肯定沒錯，那就是基於緩存的加速。
3.在反向代理上創建緩存
4.小心穿過代理
5.流量分配
第九章 Web組件分離
1.備受爭議的分離
2.因材施教
Web組件是指Web服務器提供的所有基於URL訪問的資源，比如動態內容、圖片、JavaScript腳本、CSS樣式表等。
好，我們從以下幾個方面來看這些Web組件的差異：
● 文件大小
● 文件數量
● 內容更新頻率
● 預計併發用戶數
● 是否需要腳本解釋器
● 是否涉及大量CPU計算
● 是否訪問數據庫
● 訪問數據庫的主要操作是讀還是寫
● 是否包含遠程調用（RPC）
我們需要清楚地認識到，Web組件分離的目的是便於採用針對性的方法，使得各種Web組件能夠充分有效地利用服務器資源，達到符合各自實際情況的吞吐率最大化。
這些方法可能包括以下條目中的一種或多種：
● 是否使用epoll模型
● 是否使用sendfile()系統調用
● 是否使用異步I/O
● 是否支持HTTP持久連接（HTTP Keep-alive）
● 是否需要opcode緩存
● 是否使用動態內容緩存以及有效期爲多長
● 是否使用Web服務器緩存以及有效期爲多長
● 是否使用瀏覽器緩存以及有效期爲多長
● 是否使用反向代理緩存以及有效期爲多長
● 是否使用負載均衡策略
3.擁有不同的域名
順便一提的是，這種Web組件分離的方法，本質上也屬於一種負載均衡的策略，以實現站點規模擴展，它把一系列對Web組件的請求進行垂直分割，分別指向不同的組件服務器。
後續章節中我們會詳細介紹負載均衡，我們甚至可以在各種組件服務器內部再次實現負載均衡或者集羣，那麼，這裏描述的Web組件分離便放大成爲組件集羣之間的負載均衡。
4.瀏覽器併發數
當我們用不同的域名對Web組件進行分離後，另一個好處隨之而來，那就是提高了瀏覽器在下載Web組件時的併發數。
然而，瀏覽器下載組件的過程受到最大併發數的限制，也就是瀏覽器同一時刻最多只可以下載一定數量的組件，不同的瀏覽器擁有不同的默認限制。
其實，瀏覽器的最大併發數限制有一個前提，那就是對於同一個域名下的組件纔有效，也就是說，瀏覽器會爲每個域名維護不同的下載隊列，每個隊列的最大併發數限制均爲表9-1中列出的數值，這些隊列同時運行。
可見，Web組件分離使得服務器端和瀏覽器端同時受益，可謂是雙管齊下。
5.發揮各自的潛力
動態內容：開啓opcode緩存、足夠快的CPU、足夠大的內存、多進程、與數據庫保持高速連接、可靠的數據中心
動態內容包括了一切需要動態腳本在運行時創建的內容，比如動態生成的HTML網頁、動態生成的圖片、動態生成的XML數據等。
將動態內容分離出來並不是一件容易的事情，因爲前面已經提到過，動態內容本身又包括很多差異化的應用，這往往由商業邏輯來決定，所以這也許意味着需要一個持續的分離過程，持續的意思不代表不停止，而是說明不止一次。
1、“4核4線”是指 CPU 有4個物理核心 , 任務管理器會顯示出4張CPU圖表。
2、“8核8線” 和前面“4核4線”一樣，“ 4核8線 ”是指使用了超線程技術 , 把一個物理核心模擬成2個邏輯核心， 所以任務管理器會顯示出 8張CPU表。
四核四線程相當於，四隻手做四件不同的事情，四核八線程就相當於四隻手能同時做八件事情。
我們來看看Google對一些動態內容的分離，它將不同的服務分別部署在以下的域名：
ditu.google.cn
images.google.cn
news.google.cn
video.google.cn
translate.google.cn
shenghuo.google.cn
這些服務想必你都有體驗，分離還帶來了另外一些好處：
● 域名更具有可讀性，用戶容易記憶。
● 有利於各種服務的獨立訪問量統計。
● 有利於各服務的獨立擴展，這涉及後面要介紹的基於DNS的負載均衡。
當站點壓力較小時，即便是將不同服務的域名指向同一臺物理服務器，它同樣也能帶來上述這些好處。
靜態網頁：支持epoll、非阻塞I/O、異步I/O、使用sendfile()系統調用、單進程、使用高速磁盤、使用RAID分區、購買足夠的帶寬
epoll是Linux內核爲處理大批量文件描述符而作了改進的poll，是Linux下多路複用IO接口select/poll的增強版本，它能顯著提高程序在大量併發連接中只有少量活躍的情況下的系統CPU利用率。
磁盤陣列（Redundant Arrays of Independent Drives，RAID），有“獨立磁盤構成的具有冗餘能力的陣列”之意。
磁盤陣列是由很多價格較便宜的磁盤，組合成一個容量巨大的磁盤組，利用個別磁盤提供數據所產生加成效果提升整個磁盤系統效能。利用這項技術，將數據切割成許多區段，分別存放在各個硬盤上。
圖片：
一般而言，瀏覽器會非常積極地在對靜態內容的請求中附加持久連接的聲明，所以我們只需要設置Web服務器端支持持久連接即可。
樣式表：
腳本：
視頻：
第十章 分佈式緩存
1.數據庫的前端緩衝區
但是在有些時候，使用頁面緩存顯得尤爲笨重，這可能來自於以下幾個原因：
● 一個網頁中不同區域的內容，自身更新頻率和呈現及時度要求各不相同，如果爲了遷就頻繁更新的區域，而使整個頁面頻繁重建緩存，則影響整體吞吐率。
● 即便是採用局部動態緩存，如果局部區域過多，則會使得頁面結構過於複雜，而且整合各個局部頁面也存在不小的開銷。
● 有些計算是無法作爲頁面來緩存的，比如有些動態內容中需要獲取用戶的登錄狀態，並根據不同用戶呈現不同的內容。
● 這些頁面緩存都只是提高了讀數據的速度，並沒有提高寫數據的速度。
那麼，有什麼更好的方法呢？
2.使用memcached
3.讀操作緩存
4.寫操作緩存
5.監控狀態
6.緩存擴展