Linux 千萬級PV規(guī)模高性能高并發(fā)網站架構

防偽碼：好久不見，你會不會突然的出現。

客戶端：緩存（expires）、deflate壓縮

緩存服務器：CDN/cache緩存靜態(tài)內容如：html、jpg、gif、js等

靜態(tài)web服務器：Apache/nginx靜態(tài)服務器提供html頁面內容

php/java服務器：PHP/JAVA動態(tài)內容

數據庫緩存服務器：數據庫緩存memcache/redis

數據庫服務器：MYSQL數據庫

數據存儲：NFS/HADOOP等

高并發(fā)訪問的核心原則其實就一句話“把所有的用戶訪問請求都盡量往前推”。

如果把來訪用戶比作來犯的"敵人"，我們一定要把他們擋在800里地以外，即不能讓他們的請求一下打到我們的指揮部（指揮部就是數據庫及分布式存儲）。

如：能緩存在用戶電腦本地的，就不要讓他去訪問CDN/cache。能緩存CDN/cache服務器上的，就不要讓CDN/cache去訪問源（靜態(tài)web服務器）了。能訪問靜態(tài)web服務器的，就不要去訪問動態(tài)服務器。以此類推：能不訪問數據庫和存儲就一定不要去訪問數據庫和存儲。

高性能高并發(fā)高可擴展網站架構訪問的幾個層次：

第一層：首先在用戶瀏覽器端，使用Apache的mod_deflate壓縮傳輸，再比如：expires功能,deflate和expires功能利用的好，就會大大提升用戶體驗效果及減少網站帶寬，減少后端服務器的壓力。

提示：有關壓縮傳輸及expires功能nginx/lighttpd等軟件同樣也有。

第二層：靜態(tài)頁面內容緩存，如圖片/js/css等或靜態(tài)數據html，這個層面是網頁緩存層,比如CDN（效果比公司自己部署squid/nginx/varnish要好，他們更專業(yè)，價格低廉，比如快網/CC等,而且覆蓋的城市節(jié)點更多）。自己架設squid/nginx/varnish來做小型CDN是次選(超大規(guī)模的公司可能會考慮風險問題實行自建加購買服務結合)，為前端的CDN提供數據源服務，以減輕后端我們的服務器數據及存儲壓力，而不是直接提供cache服務給最終用戶。淘寶的CDN曾經因為一部分圖片的尺寸大而導致CDN壓力大的情況，甚至對圖片尺寸大的來改小，以達到降低流量及帶寬的作用。

提示：我們也可以自己架設一層cache層，對我們購買的CDN提供數據源服務，可用的軟件有varnish/nginx/squid 等cache，以減輕第三層靜態(tài)數據層的壓力。在這層的前端我們也可以架設DNS服務器，來達到跨機房業(yè)務拓展及智能解析的目的。

第三層：靜態(tài)服務器層一般為圖片服務器，視頻服務器，靜態(tài)HTML服務器。這一層是前面緩存層和后面動態(tài)服務器層的連接紐帶。

第四層：動態(tài)服務器層：php,java等，只有通過了前面3層后的訪問請求才會到這個層，才可能會訪問數據庫及存儲設備。經過前三層的訪問過濾能到這層訪問請求一般來說已非常少了，一般都是新發(fā)布的內容和新發(fā)布內容第一次瀏覽如；博文（包括微博等），BBS帖子。

特別提示：此層可以在程序上多做文章，比如向下訪問cache層，memcache,redis,mysql,oracle，在程序級別實現分布式訪問，分布式讀寫分離，而程序級別分布式訪問的每個db cache節(jié)點，又可以是一組業(yè)務或者一組業(yè)務拆分開來的多臺服務器的負載均衡。這樣的架構會為后面的數據庫和存儲層大大的減少壓力，那么這里呢，相當于指揮部的外層了。

第五層：數據庫cache層，比如：memcache,redis等等。

根據不同的業(yè)務需求，選擇適合具體業(yè)務的數據庫。對于memcache、redis，可以在第四層通過程序來實現對本層實現分布式訪問，每個分布式訪問的節(jié)點都可能是一組負載均衡（數十臺機器）。

第六層：數據庫層，一般的不是超大站點都會用mysql主從結構，程序層做分布式數據庫讀寫分離，一主（或雙主）多從的方式，訪問大了，可以做級連的主從及環(huán)狀的多主多從，然后，實現多組負載均衡，供前端的分布式程序調用，如果訪問量再大，就需要拆業(yè)務了，比如：分司把www服務,blog服務，bbs服務都放一個服務器上，然后做主從。這種情況，當業(yè)務訪問量大了，可以簡單的把www,blog,bbs服務分別各用一組服務器拆分開。當然訪問量再大了，可以繼續(xù)針對某一個服務拆分如：www庫拆分，每個庫做一組負載均衡，還可以對庫里的表拆分。需要高可用可以通過MHA等工具做成高可用方式。對于寫大的，可以做主主或多主的MYSQL REP方式。

像百度等巨型公司除了會采用常規(guī)的mysql及oracle數據庫庫外，會在性能要求更高的領域，大量的使用nosql數據庫（非關系型的數據庫），然后前端在加DNS，負載均衡，分布式的讀寫分離，最后依然是拆業(yè)務，拆庫，。。。逐步細化，然后每個點又可以是一組或多組機器。

特別提示：數據庫層的硬件好壞也會決定訪問量的多少，尤其是要考慮磁盤IO的問題，大公司往往在性價比上做文章，比如核心業(yè)務采用硬件netapp/emc及san光纖架構，對于資源數據存儲，如圖片視頻，會采用sas或固態(tài)ssd盤，如果數據超大，可以采取熱點分取分存的方法：如：最常訪問的10-20%使用ssd存儲，中間的20-30%采用sas盤，最后的40-50%可以采用廉價的sata。

第七層：千萬級PV的站如果設計的合理一些，1，2個NFS SERVER就足夠了。當然可以做成drbd+heartbeat+nfs+a/a的方式。

以上1-7層，如果都搭好了，這樣漏網到第四層動態(tài)服務器層的訪問，就不多了。一般的中等站點，絕對不會對數據庫造成太大的壓力。程序層的分布式訪問是從千萬及PV向億級PV的發(fā)展，當然特殊的業(yè)務還需要特殊架構，來合理利用數據庫和存儲。

擴展知識點1：CDN的全稱是Content Delivery Network，即內容分發(fā)網絡。其基本思路是盡可能避開互聯網上有可能影響數據傳輸速度和穩(wěn)定性的瓶頸和環(huán)節(jié)，使內容傳輸的更快、更穩(wěn)定。通過在網絡各處放置節(jié)點服務器所構成的在現有的互聯網基礎之上的一層智能虛擬網絡，CDN系統能夠實時地根據網絡流量和各節(jié)點的連接、負載狀況以及到用戶的距離和響應時間等綜合信息將用戶的請求重新導向離用戶最近的服務節(jié)點上。其目的是使用戶可就近取得所需內容，解決 Internet網絡擁擠的狀況，提高用戶訪問網站的響應速度。

舉個通俗的例子：

談到CDN的作用，可以用早些年買火車票來比喻：在沒有火車票代售點和12306.cn之前。那時候火車票還只能在火車站的售票大廳購買，而小縣城并不通火車，火車票都要去市里的火車站購買，而從縣城到市里，來回就得n個小時車程。

到后來，小縣城里出現了火車票代售點，可以直接在代售點購買火車，方便了不少，人們再也不用在一個點排隊買票了。

CDN就可以理解為分布在每個縣城的火車票代售點，用戶在瀏覽網站的時候，CDN會選擇一個離用戶最近的CDN節(jié)點來響應用戶的請求，這樣海南移動用戶的請求就不會千里迢迢跑到北京電信機房的服務器（假設源站部署在北京電信機房）上了。

CDN的基本原理為反向代理，反向代理（Reverse Proxy）方式是指以代理服務器來接受internet上的連接請求，然后將請求轉發(fā)給內部網絡上的服務器，并將從服務器上得到的結果返回給internet上請求連接的客戶端，此時代理服務器對外就表現為一個節(jié)點服務器。通過部署更多的反向代理服務器，來達到實現多節(jié)點CDN的效果。

首先，讓我們先看傳統的未加緩存服務的訪問過程，以便了解CDN緩存訪問方式與未加緩存訪問方式的差別：

用戶提交域名→瀏覽器對域名進行解析→得到目的主機的IP地址→根據IP地址訪問發(fā)出請求→得到請求數據并回復

由上可見，用戶訪問未使用CDN緩存網站的過程為:

1)、用戶向瀏覽器提供要訪問的域名；

2)、瀏覽器調用域名解析函數庫對域名進行解析，以得到此域名對應的IP地址；

3)、瀏覽器使用所得到的IP地址，向域名的服務主機發(fā)出數據訪問請求；

4)、瀏覽器根據域名主機返回的數據顯示網頁的內容。

通過以上四個步驟，瀏覽器完成從用戶處接收用戶要訪問的域名到從域名服務主機處獲取數據的整個過程。CDN網絡是在用戶和服務器之間增加Cache層

如何將用戶的請求引導到Cache上獲得源服務器的數據，主要是通過接管DNS實現，下面讓我們看看訪問使用CDN緩存后的網站的過程：

通過上圖，我們可以了解到，使用了CDN緩存后的網站的訪問過程變?yōu)椋?/span>

1)、用戶向瀏覽器提供要訪問的域名；

2)、瀏覽器調用域名解析庫對域名進行解析，由于CDN對域名解析過程進行了調整，所以解析函數庫一般得到的是該域名對應的CNAME記錄，為了得到實際IP地址，瀏覽器需要再次對獲得的CNAME域名進行解析以得到實際的 IP地址；在此過程中，使用的全局負載均衡DNS解析，如根據地理位置信息解析對應的IP地址，使得用戶能就近訪問。

3)、此次解析得到CDN緩存服務器的IP地址，瀏覽器在得到實際的IP地址以后，向緩存服務器發(fā)出訪問請求；

4)、緩存服務器根據瀏覽器提供的要訪問的域名，通過Cache內部專用DNS解析得到此域名的實際IP地址，再由緩存服務器向此實際IP地址提交訪問請求；

5)、緩存服務器從實際IP地址得得到內容以后，一方面在本地進行保存，以備以后使用，另一方面把獲取的數據返回給客戶端，完成數據服務過程；

6)、客戶端得到由緩存服務器返回的數據以后顯示出來并完成整個瀏覽的數據請求過程。

通過以上的分析我們可以得到，為了實現既要對普通用戶透明(即加入緩存以 后用戶客戶端無需進行任何設置，直接使用被加速網站原有的域名即可訪問，只要修改整個訪問過程中的域名解析部分，以實現透明的加速服務。

下面是CDN網絡實現的具體操作過程。

使用了CDN服務后，用戶的訪問流程如下圖所示：

1.用戶向瀏覽器輸入www.web.com這個域名，瀏覽器第一次發(fā)現本地沒有dns緩存，則向網站的DNS服務器請求；

2.網站的DNS域名解析器設置了CNAME，指向了www.web.51cdn.com,請求指向了CDN網絡中的智能DNS負載均衡系統；

3.智能DNS負載均衡系統解析域名，把對用戶響應速度最快的IP節(jié)點返回給用戶；

4.用戶向該IP節(jié)點（CDN服務器）發(fā)出請求；

5.由于是第一次訪問，CDN服務器會向原web站點請求，并緩存內容；

6.請求結果發(fā)給用戶。

CDN網絡是在用戶和服務器之間增加Cache層，如何將用戶的請求引導到Cache上獲得源服務器的數據，主要是通過接管DNS實現，這就是CDN的最基本的原理，當然很多細節(jié)沒有涉及到，比如第1步，首先向本地的DNS服務器請求。第5步，內容淘汰機制（根據TTL）等。但原理大體如此。

當用戶訪問加入CDN服務的網站時，域名解析請求將最終交給全局負載均衡DNS進行處理。全局負載均衡DNS通過一組預先定義好的策略，將當時最接近用戶的節(jié)點地址提供給用戶，使用戶能夠得到快速的服務。同時，它還與分布在世界各地的所有CDNC節(jié)點保持通信，搜集各節(jié)點的通信狀態(tài)，確保不將用戶的請求分配到不可用的CDN節(jié)點上，實際上是通過DNS做全局負載均衡。

對于普通的Internet用戶來講，每個CDN節(jié)點就相當于一個放置在它周圍的WEB。通過全局負載均衡DNS的控制，用戶的請求被透明地指向離他最近的節(jié)點，節(jié)點中CDN服務器會像網站的原始服務器一樣，響應用戶的請求。由于它離用戶更近，因而響應時間必然更快。

每個CDN節(jié)點由兩部分組成:負載均衡設備和高速緩存服務器

負載均衡設備負責每個節(jié)點中各個Cache的負載均衡，保證節(jié)點的工作效率;同時，負載均衡設備還負責收集節(jié)點與周圍環(huán)境的信息，保持與全局負載DNS的通信，實現整個系統的負載均衡。CDN的管理系統是整個系統能夠正常運轉的保證。它不僅能對系統中的各個子系統和設備進行實時監(jiān)控，對各種故障產生相應的告警，還可以實時監(jiān)測到系統中總的流量和各節(jié)點的流量，并保存在系統的數據庫中，使網管人員能夠方便地進行進一步分析。通過完善的網管系統，用戶可以對系統配置進行修改。

理論上，最簡單的CDN網絡有一個負責全局負載均衡的DNS和各節(jié)點一臺Cache，即可運行。DNS支持根據用戶源IP地址解析不同的IP，實現就近訪問。為了保證高可用性等，需要監(jiān)視各節(jié)點的流量、健康狀況等。一個節(jié)點的單臺Cache承載數量不夠時，才需要多臺Cache，多臺Cache同時工作，才需要負載均衡器，使Cache群協同工作。

CDN的典型拓撲圖如下：

CDN和反向代理的基本原理都是緩存數據，區(qū)別就在于CDN部署在網絡提供商的機房，使用戶在請求網站服務時，可以從距離自己最近的網絡提供商機房獲取數據。

CDN對網絡的優(yōu)化作用：

CDN系統通過在網絡各處放置節(jié)點服務器，從而將網站的內容放置到離用戶最近的地方，避免了影響互聯網傳輸性能的“第一公里”和“網間互聯瓶頸”等各個環(huán)節(jié)，為改善互聯網環(huán)境、解決網站的服務質量和提高用戶的上網速度提供了有效的解決方案。

CDN對網絡的優(yōu)化作用主要體現在如下幾個方面：

解決服務器端的“第一公里”問題

緩解甚至消除了不同運營商之間互聯的瓶頸造成的影響

減輕了各省的出口帶寬壓力

緩解了骨干網的壓力

提起CDN，一般人都會望而止步，因為CDN太貴，都是大企業(yè)才能用得起的貴族式服務，而如今面對中小企業(yè)的CDN技術開發(fā)已經實現，并進入市場開始運營。

現在市面上CDN提供商計費方式多樣，有按每月最低消費的，有按帶寬收費的，有按請求數收費的，有包月包季包年限制的，還有些大多人看不懂的技術指標收費的，總之比較復雜，CDN服務在所有計費方式中，中小企業(yè)一致認為按流量收費最為合理，另外大多按流量計費方式中會有時間限制，規(guī)定時間內用不完就會全部作廢，對于流量把握不好的中小企業(yè)，存在相當一部分浪費。所以企業(yè)自已也可以使用squid/varnish/nginx等構建緩存服務器。

擴展知識點2：pvuvip

PV(page view)：即頁面瀏覽量，或點擊量，PV是網站分析的一個術語，用以衡量網站用戶訪問的網頁的數量。一般來說，PV與來訪者的數量成正比，但是PV并不直接決定頁面的真實來訪者數量，如同一個來訪者通過不斷的刷新頁面，也可以制造出非常高的PV。

UV（unique visitor）即獨立訪客數：指訪問某個站點或點擊某個網頁的不同IP地址的人數。在同一天內，UV只記錄第一次進入網站的具有獨立IP的訪問者，在同一天內再次訪問該網站則不計數。UV提供了一定時間內不同觀眾數量的統計指標，而沒有反應出網站的全面活動。

通過cookie是判斷UV值的方式：

用Cookie分析UV值：當客戶端第一次訪問某個網站服務器的時候，網站服務器會給這個客戶端的電腦發(fā)出一個Cookie，通常放在這個客戶端電腦的C盤當中。在這個Cookie中會分配一個獨一無二的編號，這其中會記錄一些訪問服務器的信息，如訪問時間，訪問了哪些頁面等等。當你下次再訪問這個服務器的時候，服務器就可以直接從你的電腦中找到上一次放進去的Cookie文件，并且對其進行一些更新，但那個獨一無二的編號是不會變的。所以當客戶端再次使用cookie訪問網站時，會附帶此Cookie，那么此時服務器就會認為是同一個客戶端，那么只會記錄一次的UV

使用Cookie方法比分析客戶端HTTP請求頭部信息更為精準，但是會有缺點，那就是用戶可能會關閉了Cookie功能。或者自動刪除了cookie等操作，所以獲取的指標也不能說是完全準確。

IP即獨立IP數：

IP可以理解為獨立IP的訪問用戶，指1天內使用不同IP地址的用戶訪問網站的數量，同一IP無論訪問了幾個頁面，獨立IP數均為1。但是假如說兩臺機器訪問而使用的是同一個IP，那么只能算是一個IP的訪問。

IP和UV之間的數據不會有太大的差異，通常UV量和比IP量高出一點，每個UV相對于每個IP更準確地對應一個實際的瀏覽者。

①UV大于IP

這種情況就是在網吧、學校、公司等，公用相同IP的場所中不同的用戶，或者多種不同瀏覽器訪問您網站，那么UV數會大于IP數。

②UV小于IP

在家庭中大多數電腦使用ADSL撥號上網，所以同一個用戶在家里不同時間訪問您網站時，IP可能會不同，因為它會根據時間變動IP，即動態(tài)的IP地址，但是實際訪客數唯一，便會出現UV數小于IP數。

PV和UV是衡量一個網站流量好壞的一個重要指標，對于網站的PV和UV的統計，可使用第三方統計工具進行統計，只需要將第三方統計工具的JS代碼放置于網站需要統計PV和UV的頁面即可，然后登錄統計工具后臺查詢網站的PV和UV量（如可使用的第三方統計工具為百度統計）；

查詢方法

1. 使用alexa統計

英文站： http://www.alexa.com/

中文站： http://alexa.chinaz.com/

2. 一般大型網站都有自己的一套流量統計系統，可以到自己的后臺查看。

3. 如果沒有的話，可以借助GoogleAnalytics、cnzz、#等統計平臺查看數據。

IP、PV、UV的計算

對IP計算

1.分析網站的訪問日志，去除相同的IP地址

2.使用第三方統計工具

3.在網頁后添加多一個程序代碼統計字段，然后使用日志分析工具對程序代碼字段進行統計。

對PV的計算

1.分析網站的訪問日志，計算HTML及動態(tài)語言等網頁的數量

2.使用第三方統計工具

3.在網頁后添加多一個程序代碼統計字段，然后使用日志分析工具對程序代碼字段進行統計。

對UV的計算

1.分析客戶端的HTTP請求報文，將客戶端特有的信息記錄下來進行分析。若能滿足共同的特征將會被認為是同一個客戶端，那么此時將記錄為一個UV。

2.通過cookie
當客戶端訪問一個網站時，服務器會向該客戶端發(fā)送一個Cookie，Cookie具有獨一性，所以當客戶端再次使用cookie訪問網站時，會附帶此Cookie，那么此時服務器就會認為是同一個客戶端，那么只會記錄一次的UV
缺點：使用Cookie方法比分析客戶端HTTP請求頭部信息更為精準，但是會有缺點，那就是用戶可能會關閉了Cookie功能?；蛘咦詣觿h除了cookie等操作，所以獲取的指標也不能說是完全準確。

每秒并發(fā)數預估：

1. 假如每天的pv為6000萬；

2. 集中訪問量：24*0.2=4.8小時，會有6000萬*0.8=4800萬（二八原則）；

3. 每分并發(fā)量：4.8*60=288分鐘，每分鐘訪問4800/288=16.7萬（約等于）；

4. 每秒并發(fā)量：16.7萬/60=2780（約等于）；

5. 假設：高峰期為平常值的二到三倍，則每秒的并發(fā)數可以達到5560~8340次。

千萬PV級別WEB站點架構設計

1、代理層可以使用Haproxy或nginx，Haproxy/nginx是非常優(yōu)秀的反向代理軟件，十分高效、穩(wěn)定?？梢钥紤]用F5-LTM或成熟的開源解決方案LVS實現代理層負載均衡方案。

2、緩存層可以使用Squid或Varnish，緩存服務器作為網頁服務器的前置cache服務器，可以代理用戶向 web服務器請求數據并進行緩存。

3、靜態(tài)web服務器（apache/nginx）提供靜態(tài)內容訪問，實現靜動分離；通過相關工具(lvs/haproxy/nginx)做負載均衡(Load Balancer)

4、動態(tài)內容服務器（php/java）通過相關工具如xcache緩存解析過的動態(tài)內容。

5、數據庫緩存（memcache/redis）作為數據庫緩存都非常理想。

6、數據庫層主流開源解決方案Mysql是首選，主從復制（一主對多從或多主多從）是目前比較靠譜的模式。

7、存儲層作為數據的存儲可以考慮nfs、分布式文件系統（如mfs）、hadoop(hadoop適合海量數據的存儲與處理，如做網站日志分析、用戶數據挖掘等)

當用戶請求的是靜態(tài)資源(圖片/視頻/html等),不需要計算處理時，在CDN或緩存層就結束了，當緩存不能命中時，就會去web server中取相應的數據。只有當用戶請求動態(tài)資源時，才會到動態(tài)內容服務器。動態(tài)內容服務器可以從數據庫緩存或者MySQL中獲得數據。

此外，如果前端的程序和數據的存取不同步，是需要異步訪問的。這就需要使用一些消息隊列，如rabbitmq，這在后面openstack相關學習做進一步的講解。同時Apache的開源項目中的activemq也能提供相關的功能。

注：消息隊列可以解決子系統/模塊之間的耦合，實現異步，高可用，高性能的系統。是分布式系統的標準配置。

例如消息隊列在購物，配送環(huán)節(jié)的應用。

用戶下單后，寫入消息隊列，后直接返回客戶端；

庫存子系統：讀取消息隊列信息，完成減庫存；

配送子系統：讀取消息隊列信息，進行配送；

歡迎加技術群：323779636（Shell/Python運維開發(fā)群）

本文出自 “一盞燭光” 博客，謝絕轉載！