Linux 千萬(wàn)級(jí)PV規(guī)模高性能高并發(fā)網(wǎng)站架構(gòu)

防偽碼：好久不見(jiàn)，你會(huì)不會(huì)突然的出現(xiàn)。

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

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

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

php/java服務(wù)器：PHP/JAVA動(dòng)態(tài)內(nèi)容

數(shù)據(jù)庫(kù)緩存服務(wù)器：數(shù)據(jù)庫(kù)緩存memcache/redis

數(shù)據(jù)庫(kù)服務(wù)器：MYSQL數(shù)據(jù)庫(kù)

數(shù)據(jù)存儲(chǔ)：NFS/HADOOP等

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

如果把來(lái)訪用戶比作來(lái)犯的"敵人"，我們一定要把他們擋在800里地以外，即不能讓他們的請(qǐng)求一下打到我們的指揮部（指揮部就是數(shù)據(jù)庫(kù)及分布式存儲(chǔ)）。

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

高性能高并發(fā)高可擴(kuò)展網(wǎng)站架構(gòu)訪問(wèn)的幾個(gè)層次：

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

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

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

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

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

第四層：動(dòng)態(tài)服務(wù)器層：php,java等，只有通過(guò)了前面3層后的訪問(wèn)請(qǐng)求才會(huì)到這個(gè)層，才可能會(huì)訪問(wèn)數(shù)據(jù)庫(kù)及存儲(chǔ)設(shè)備。經(jīng)過(guò)前三層的訪問(wèn)過(guò)濾能到這層訪問(wèn)請(qǐng)求一般來(lái)說(shuō)已非常少了，一般都是新發(fā)布的內(nèi)容和新發(fā)布內(nèi)容第一次瀏覽如；博文（包括微博等），BBS帖子。

特別提示：此層可以在程序上多做文章，比如向下訪問(wèn)cache層，memcache,redis,mysql,oracle，在程序級(jí)別實(shí)現(xiàn)分布式訪問(wèn)，分布式讀寫(xiě)分離，而程序級(jí)別分布式訪問(wèn)的每個(gè)db cache節(jié)點(diǎn)，又可以是一組業(yè)務(wù)或者一組業(yè)務(wù)拆分開(kāi)來(lái)的多臺(tái)服務(wù)器的負(fù)載均衡。這樣的架構(gòu)會(huì)為后面的數(shù)據(jù)庫(kù)和存儲(chǔ)層大大的減少壓力，那么這里呢，相當(dāng)于指揮部的外層了。

第五層：數(shù)據(jù)庫(kù)cache層，比如：memcache,redis等等。

根據(jù)不同的業(yè)務(wù)需求，選擇適合具體業(yè)務(wù)的數(shù)據(jù)庫(kù)。對(duì)于memcache、redis，可以在第四層通過(guò)程序來(lái)實(shí)現(xiàn)對(duì)本層實(shí)現(xiàn)分布式訪問(wèn)，每個(gè)分布式訪問(wèn)的節(jié)點(diǎn)都可能是一組負(fù)載均衡（數(shù)十臺(tái)機(jī)器）。

第六層：數(shù)據(jù)庫(kù)層，一般的不是超大站點(diǎn)都會(huì)用mysql主從結(jié)構(gòu)，程序?qū)幼龇植际綌?shù)據(jù)庫(kù)讀寫(xiě)分離，一主（或雙主）多從的方式，訪問(wèn)大了，可以做級(jí)連的主從及環(huán)狀的多主多從，然后，實(shí)現(xiàn)多組負(fù)載均衡，供前端的分布式程序調(diào)用，如果訪問(wèn)量再大，就需要拆業(yè)務(wù)了，比如：分司把www服務(wù),blog服務(wù)，bbs服務(wù)都放一個(gè)服務(wù)器上，然后做主從。這種情況，當(dāng)業(yè)務(wù)訪問(wèn)量大了，可以簡(jiǎn)單的把www,blog,bbs服務(wù)分別各用一組服務(wù)器拆分開(kāi)。當(dāng)然訪問(wèn)量再大了，可以繼續(xù)針對(duì)某一個(gè)服務(wù)拆分如：www庫(kù)拆分，每個(gè)庫(kù)做一組負(fù)載均衡，還可以對(duì)庫(kù)里的表拆分。需要高可用可以通過(guò)MHA等工具做成高可用方式。對(duì)于寫(xiě)大的，可以做主主或多主的MYSQL REP方式。

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

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

第七層：千萬(wàn)級(jí)PV的站如果設(shè)計(jì)的合理一些，1，2個(gè)NFS SERVER就足夠了。當(dāng)然可以做成drbd+heartbeat+nfs+a/a的方式。

以上1-7層，如果都搭好了，這樣漏網(wǎng)到第四層動(dòng)態(tài)服務(wù)器層的訪問(wèn)，就不多了。一般的中等站點(diǎn)，絕對(duì)不會(huì)對(duì)數(shù)據(jù)庫(kù)造成太大的壓力。程序?qū)拥姆植际皆L問(wèn)是從千萬(wàn)及PV向億級(jí)PV的發(fā)展，當(dāng)然特殊的業(yè)務(wù)還需要特殊架構(gòu)，來(lái)合理利用數(shù)據(jù)庫(kù)和存儲(chǔ)。

擴(kuò)展知識(shí)點(diǎn)1：CDN的全稱是Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)。其基本思路是盡可能避開(kāi)互聯(lián)網(wǎng)上有可能影響數(shù)據(jù)傳輸速度和穩(wěn)定性的瓶頸和環(huán)節(jié)，使內(nèi)容傳輸?shù)母?、更穩(wěn)定。通過(guò)在網(wǎng)絡(luò)各處放置節(jié)點(diǎn)服務(wù)器所構(gòu)成的在現(xiàn)有的互聯(lián)網(wǎng)基礎(chǔ)之上的一層智能虛擬網(wǎng)絡(luò)，CDN系統(tǒng)能夠?qū)崟r(shí)地根據(jù)網(wǎng)絡(luò)流量和各節(jié)點(diǎn)的連接、負(fù)載狀況以及到用戶的距離和響應(yīng)時(shí)間等綜合信息將用戶的請(qǐng)求重新導(dǎo)向離用戶最近的服務(wù)節(jié)點(diǎn)上。其目的是使用戶可就近取得所需內(nèi)容，解決 Internet網(wǎng)絡(luò)擁擠的狀況，提高用戶訪問(wèn)網(wǎng)站的響應(yīng)速度。

舉個(gè)通俗的例子：

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

到后來(lái)，小縣城里出現(xiàn)了火車票代售點(diǎn)，可以直接在代售點(diǎn)購(gòu)買火車，方便了不少，人們?cè)僖膊挥迷谝粋€(gè)點(diǎn)排隊(duì)買票了。

CDN就可以理解為分布在每個(gè)縣城的火車票代售點(diǎn)，用戶在瀏覽網(wǎng)站的時(shí)候，CDN會(huì)選擇一個(gè)離用戶最近的CDN節(jié)點(diǎn)來(lái)響應(yīng)用戶的請(qǐng)求，這樣海南移動(dòng)用戶的請(qǐng)求就不會(huì)千里迢迢跑到北京電信機(jī)房的服務(wù)器（假設(shè)源站部署在北京電信機(jī)房）上了。

CDN的基本原理為反向代理，反向代理（Reverse Proxy）方式是指以代理服務(wù)器來(lái)接受internet上的連接請(qǐng)求，然后將請(qǐng)求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器，并將從服務(wù)器上得到的結(jié)果返回給internet上請(qǐng)求連接的客戶端，此時(shí)代理服務(wù)器對(duì)外就表現(xiàn)為一個(gè)節(jié)點(diǎn)服務(wù)器。通過(guò)部署更多的反向代理服務(wù)器，來(lái)達(dá)到實(shí)現(xiàn)多節(jié)點(diǎn)CDN的效果。

首先，讓我們先看傳統(tǒng)的未加緩存服務(wù)的訪問(wèn)過(guò)程，以便了解CDN緩存訪問(wèn)方式與未加緩存訪問(wèn)方式的差別：

用戶提交域名→瀏覽器對(duì)域名進(jìn)行解析→得到目的主機(jī)的IP地址→根據(jù)IP地址訪問(wèn)發(fā)出請(qǐng)求→得到請(qǐng)求數(shù)據(jù)并回復(fù)

由上可見(jiàn)，用戶訪問(wèn)未使用CDN緩存網(wǎng)站的過(guò)程為:

1)、用戶向?yàn)g覽器提供要訪問(wèn)的域名；

2)、瀏覽器調(diào)用域名解析函數(shù)庫(kù)對(duì)域名進(jìn)行解析，以得到此域名對(duì)應(yīng)的IP地址；

3)、瀏覽器使用所得到的IP地址，向域名的服務(wù)主機(jī)發(fā)出數(shù)據(jù)訪問(wèn)請(qǐng)求；

4)、瀏覽器根據(jù)域名主機(jī)返回的數(shù)據(jù)顯示網(wǎng)頁(yè)的內(nèi)容。

通過(guò)以上四個(gè)步驟，瀏覽器完成從用戶處接收用戶要訪問(wèn)的域名到從域名服務(wù)主機(jī)處獲取數(shù)據(jù)的整個(gè)過(guò)程。CDN網(wǎng)絡(luò)是在用戶和服務(wù)器之間增加Cache層

如何將用戶的請(qǐng)求引導(dǎo)到Cache上獲得源服務(wù)器的數(shù)據(jù)，主要是通過(guò)接管DNS實(shí)現(xiàn)，下面讓我們看看訪問(wèn)使用CDN緩存后的網(wǎng)站的過(guò)程：

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

1)、用戶向?yàn)g覽器提供要訪問(wèn)的域名；

2)、瀏覽器調(diào)用域名解析庫(kù)對(duì)域名進(jìn)行解析，由于CDN對(duì)域名解析過(guò)程進(jìn)行了調(diào)整，所以解析函數(shù)庫(kù)一般得到的是該域名對(duì)應(yīng)的CNAME記錄，為了得到實(shí)際IP地址，瀏覽器需要再次對(duì)獲得的CNAME域名進(jìn)行解析以得到實(shí)際的 IP地址；在此過(guò)程中，使用的全局負(fù)載均衡DNS解析，如根據(jù)地理位置信息解析對(duì)應(yīng)的IP地址，使得用戶能就近訪問(wèn)。

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

4)、緩存服務(wù)器根據(jù)瀏覽器提供的要訪問(wèn)的域名，通過(guò)Cache內(nèi)部專用DNS解析得到此域名的實(shí)際IP地址，再由緩存服務(wù)器向此實(shí)際IP地址提交訪問(wèn)請(qǐng)求；

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

6)、客戶端得到由緩存服務(wù)器返回的數(shù)據(jù)以后顯示出來(lái)并完成整個(gè)瀏覽的數(shù)據(jù)請(qǐng)求過(guò)程。

通過(guò)以上的分析我們可以得到，為了實(shí)現(xiàn)既要對(duì)普通用戶透明(即加入緩存以 后用戶客戶端無(wú)需進(jìn)行任何設(shè)置，直接使用被加速網(wǎng)站原有的域名即可訪問(wèn)，只要修改整個(gè)訪問(wèn)過(guò)程中的域名解析部分，以實(shí)現(xiàn)透明的加速服務(wù)。

下面是CDN網(wǎng)絡(luò)實(shí)現(xiàn)的具體操作過(guò)程。

使用了CDN服務(wù)后，用戶的訪問(wèn)流程如下圖所示：

1.用戶向?yàn)g覽器輸入www.web.com這個(gè)域名，瀏覽器第一次發(fā)現(xiàn)本地沒(méi)有dns緩存，則向網(wǎng)站的DNS服務(wù)器請(qǐng)求；

2.網(wǎng)站的DNS域名解析器設(shè)置了CNAME，指向了www.web.51cdn.com,請(qǐng)求指向了CDN網(wǎng)絡(luò)中的智能DNS負(fù)載均衡系統(tǒng)；

3.智能DNS負(fù)載均衡系統(tǒng)解析域名，把對(duì)用戶響應(yīng)速度最快的IP節(jié)點(diǎn)返回給用戶；

4.用戶向該IP節(jié)點(diǎn)（CDN服務(wù)器）發(fā)出請(qǐng)求；

5.由于是第一次訪問(wèn)，CDN服務(wù)器會(huì)向原web站點(diǎn)請(qǐng)求，并緩存內(nèi)容；

6.請(qǐng)求結(jié)果發(fā)給用戶。

CDN網(wǎng)絡(luò)是在用戶和服務(wù)器之間增加Cache層，如何將用戶的請(qǐng)求引導(dǎo)到Cache上獲得源服務(wù)器的數(shù)據(jù)，主要是通過(guò)接管DNS實(shí)現(xiàn)，這就是CDN的最基本的原理，當(dāng)然很多細(xì)節(jié)沒(méi)有涉及到，比如第1步，首先向本地的DNS服務(wù)器請(qǐng)求。第5步，內(nèi)容淘汰機(jī)制（根據(jù)TTL）等。但原理大體如此。

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

對(duì)于普通的Internet用戶來(lái)講，每個(gè)CDN節(jié)點(diǎn)就相當(dāng)于一個(gè)放置在它周圍的WEB。通過(guò)全局負(fù)載均衡DNS的控制，用戶的請(qǐng)求被透明地指向離他最近的節(jié)點(diǎn)，節(jié)點(diǎn)中CDN服務(wù)器會(huì)像網(wǎng)站的原始服務(wù)器一樣，響應(yīng)用戶的請(qǐng)求。由于它離用戶更近，因而響應(yīng)時(shí)間必然更快。

每個(gè)CDN節(jié)點(diǎn)由兩部分組成:負(fù)載均衡設(shè)備和高速緩存服務(wù)器

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

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

CDN的典型拓?fù)鋱D如下：

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

CDN對(duì)網(wǎng)絡(luò)的優(yōu)化作用：

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

CDN對(duì)網(wǎng)絡(luò)的優(yōu)化作用主要體現(xiàn)在如下幾個(gè)方面：

解決服務(wù)器端的“第一公里”問(wèn)題

緩解甚至消除了不同運(yùn)營(yíng)商之間互聯(lián)的瓶頸造成的影響

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

緩解了骨干網(wǎng)的壓力

提起CDN，一般人都會(huì)望而止步，因?yàn)镃DN太貴，都是大企業(yè)才能用得起的貴族式服務(wù)，而如今面對(duì)中小企業(yè)的CDN技術(shù)開(kāi)發(fā)已經(jīng)實(shí)現(xiàn)，并進(jìn)入市場(chǎng)開(kāi)始運(yùn)營(yíng)。

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

擴(kuò)展知識(shí)點(diǎn)2：pvuvip

PV(page view)：即頁(yè)面瀏覽量，或點(diǎn)擊量，PV是網(wǎng)站分析的一個(gè)術(shù)語(yǔ)，用以衡量網(wǎng)站用戶訪問(wèn)的網(wǎng)頁(yè)的數(shù)量。一般來(lái)說(shuō)，PV與來(lái)訪者的數(shù)量成正比，但是PV并不直接決定頁(yè)面的真實(shí)來(lái)訪者數(shù)量，如同一個(gè)來(lái)訪者通過(guò)不斷的刷新頁(yè)面，也可以制造出非常高的PV。

UV（unique visitor）即獨(dú)立訪客數(shù)：指訪問(wèn)某個(gè)站點(diǎn)或點(diǎn)擊某個(gè)網(wǎng)頁(yè)的不同IP地址的人數(shù)。在同一天內(nèi)，UV只記錄第一次進(jìn)入網(wǎng)站的具有獨(dú)立IP的訪問(wèn)者，在同一天內(nèi)再次訪問(wèn)該網(wǎng)站則不計(jì)數(shù)。UV提供了一定時(shí)間內(nèi)不同觀眾數(shù)量的統(tǒng)計(jì)指標(biāo)，而沒(méi)有反應(yīng)出網(wǎng)站的全面活動(dòng)。

通過(guò)cookie是判斷UV值的方式：

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

使用Cookie方法比分析客戶端HTTP請(qǐng)求頭部信息更為精準(zhǔn)，但是會(huì)有缺點(diǎn)，那就是用戶可能會(huì)關(guān)閉了Cookie功能?；蛘咦詣?dòng)刪除了cookie等操作，所以獲取的指標(biāo)也不能說(shuō)是完全準(zhǔn)確。

IP即獨(dú)立IP數(shù)：

IP可以理解為獨(dú)立IP的訪問(wèn)用戶，指1天內(nèi)使用不同IP地址的用戶訪問(wèn)網(wǎng)站的數(shù)量，同一IP無(wú)論訪問(wèn)了幾個(gè)頁(yè)面，獨(dú)立IP數(shù)均為1。但是假如說(shuō)兩臺(tái)機(jī)器訪問(wèn)而使用的是同一個(gè)IP，那么只能算是一個(gè)IP的訪問(wèn)。

IP和UV之間的數(shù)據(jù)不會(huì)有太大的差異，通常UV量和比IP量高出一點(diǎn)，每個(gè)UV相對(duì)于每個(gè)IP更準(zhǔn)確地對(duì)應(yīng)一個(gè)實(shí)際的瀏覽者。

①UV大于IP

這種情況就是在網(wǎng)吧、學(xué)校、公司等，公用相同IP的場(chǎng)所中不同的用戶，或者多種不同瀏覽器訪問(wèn)您網(wǎng)站，那么UV數(shù)會(huì)大于IP數(shù)。

②UV小于IP

在家庭中大多數(shù)電腦使用ADSL撥號(hào)上網(wǎng)，所以同一個(gè)用戶在家里不同時(shí)間訪問(wèn)您網(wǎng)站時(shí)，IP可能會(huì)不同，因?yàn)樗鼤?huì)根據(jù)時(shí)間變動(dòng)IP，即動(dòng)態(tài)的IP地址，但是實(shí)際訪客數(shù)唯一，便會(huì)出現(xiàn)UV數(shù)小于IP數(shù)。

PV和UV是衡量一個(gè)網(wǎng)站流量好壞的一個(gè)重要指標(biāo)，對(duì)于網(wǎng)站的PV和UV的統(tǒng)計(jì)，可使用第三方統(tǒng)計(jì)工具進(jìn)行統(tǒng)計(jì)，只需要將第三方統(tǒng)計(jì)工具的JS代碼放置于網(wǎng)站需要統(tǒng)計(jì)PV和UV的頁(yè)面即可，然后登錄統(tǒng)計(jì)工具后臺(tái)查詢網(wǎng)站的PV和UV量（如可使用的第三方統(tǒng)計(jì)工具為百度統(tǒng)計(jì)）；

查詢方法

1. 使用alexa統(tǒng)計(jì)

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

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

2. 一般大型網(wǎng)站都有自己的一套流量統(tǒng)計(jì)系統(tǒng)，可以到自己的后臺(tái)查看。

3. 如果沒(méi)有的話，可以借助GoogleAnalytics、cnzz、#等統(tǒng)計(jì)平臺(tái)查看數(shù)據(jù)。

IP、PV、UV的計(jì)算

對(duì)IP計(jì)算

1.分析網(wǎng)站的訪問(wèn)日志，去除相同的IP地址

2.使用第三方統(tǒng)計(jì)工具

3.在網(wǎng)頁(yè)后添加多一個(gè)程序代碼統(tǒng)計(jì)字段，然后使用日志分析工具對(duì)程序代碼字段進(jìn)行統(tǒng)計(jì)。

對(duì)PV的計(jì)算

1.分析網(wǎng)站的訪問(wèn)日志，計(jì)算HTML及動(dòng)態(tài)語(yǔ)言等網(wǎng)頁(yè)的數(shù)量

2.使用第三方統(tǒng)計(jì)工具

3.在網(wǎng)頁(yè)后添加多一個(gè)程序代碼統(tǒng)計(jì)字段，然后使用日志分析工具對(duì)程序代碼字段進(jìn)行統(tǒng)計(jì)。

對(duì)UV的計(jì)算

1.分析客戶端的HTTP請(qǐng)求報(bào)文，將客戶端特有的信息記錄下來(lái)進(jìn)行分析。若能滿足共同的特征將會(huì)被認(rèn)為是同一個(gè)客戶端，那么此時(shí)將記錄為一個(gè)UV。

2.通過(guò)cookie
當(dāng)客戶端訪問(wèn)一個(gè)網(wǎng)站時(shí)，服務(wù)器會(huì)向該客戶端發(fā)送一個(gè)Cookie，Cookie具有獨(dú)一性，所以當(dāng)客戶端再次使用cookie訪問(wèn)網(wǎng)站時(shí)，會(huì)附帶此Cookie，那么此時(shí)服務(wù)器就會(huì)認(rèn)為是同一個(gè)客戶端，那么只會(huì)記錄一次的UV
缺點(diǎn)：使用Cookie方法比分析客戶端HTTP請(qǐng)求頭部信息更為精準(zhǔn)，但是會(huì)有缺點(diǎn)，那就是用戶可能會(huì)關(guān)閉了Cookie功能。或者自動(dòng)刪除了cookie等操作，所以獲取的指標(biāo)也不能說(shuō)是完全準(zhǔn)確。

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

1. 假如每天的pv為6000萬(wàn)；

2. 集中訪問(wèn)量：24*0.2=4.8小時(shí)，會(huì)有6000萬(wàn)*0.8=4800萬(wàn)（二八原則）；

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

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

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

千萬(wàn)PV級(jí)別WEB站點(diǎn)架構(gòu)設(shè)計(jì)

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

2、緩存層可以使用Squid或Varnish，緩存服務(wù)器作為網(wǎng)頁(yè)服務(wù)器的前置cache服務(wù)器，可以代理用戶向 web服務(wù)器請(qǐng)求數(shù)據(jù)并進(jìn)行緩存。

3、靜態(tài)web服務(wù)器（apache/nginx）提供靜態(tài)內(nèi)容訪問(wèn)，實(shí)現(xiàn)靜動(dòng)分離；通過(guò)相關(guān)工具(lvs/haproxy/nginx)做負(fù)載均衡(Load Balancer)

4、動(dòng)態(tài)內(nèi)容服務(wù)器（php/java）通過(guò)相關(guān)工具如xcache緩存解析過(guò)的動(dòng)態(tài)內(nèi)容。

5、數(shù)據(jù)庫(kù)緩存（memcache/redis）作為數(shù)據(jù)庫(kù)緩存都非常理想。

6、數(shù)據(jù)庫(kù)層主流開(kāi)源解決方案Mysql是首選，主從復(fù)制（一主對(duì)多從或多主多從）是目前比較靠譜的模式。

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

當(dāng)用戶請(qǐng)求的是靜態(tài)資源(圖片/視頻/html等),不需要計(jì)算處理時(shí)，在CDN或緩存層就結(jié)束了，當(dāng)緩存不能命中時(shí)，就會(huì)去web server中取相應(yīng)的數(shù)據(jù)。只有當(dāng)用戶請(qǐng)求動(dòng)態(tài)資源時(shí)，才會(huì)到動(dòng)態(tài)內(nèi)容服務(wù)器。動(dòng)態(tài)內(nèi)容服務(wù)器可以從數(shù)據(jù)庫(kù)緩存或者M(jìn)ySQL中獲得數(shù)據(jù)。

此外，如果前端的程序和數(shù)據(jù)的存取不同步，是需要異步訪問(wèn)的。這就需要使用一些消息隊(duì)列，如rabbitmq，這在后面openstack相關(guān)學(xué)習(xí)做進(jìn)一步的講解。同時(shí)Apache的開(kāi)源項(xiàng)目中的activemq也能提供相關(guān)的功能。

注：消息隊(duì)列可以解決子系統(tǒng)/模塊之間的耦合，實(shí)現(xiàn)異步，高可用，高性能的系統(tǒng)。是分布式系統(tǒng)的標(biāo)準(zhǔn)配置。

例如消息隊(duì)列在購(gòu)物，配送環(huán)節(jié)的應(yīng)用。

用戶下單后，寫(xiě)入消息隊(duì)列，后直接返回客戶端；

庫(kù)存子系統(tǒng)：讀取消息隊(duì)列信息，完成減庫(kù)存；

配送子系統(tǒng)：讀取消息隊(duì)列信息，進(jìn)行配送；

歡迎加技術(shù)群：323779636（Shell/Python運(yùn)維開(kāi)發(fā)群）

本文出自 “一盞燭光” 博客，謝絕轉(zhuǎn)載！