防偽碼：好久不見，你會不會突然的出現(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頁面內(nèi)容

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

舉個通俗的例子：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

擴展知識點2：pvuvip

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

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

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

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

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

IP即獨立IP數(shù)：

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

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

①UV大于IP

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

②UV小于IP

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

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

查詢方法

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

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

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

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

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

IP、PV、UV的計算

對IP計算

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

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

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

對PV的計算

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

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

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

對UV的計算

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

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

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

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. 假設(shè)：高峰期為平常值的二到三倍，則每秒的并發(fā)數(shù)可以達到5560~8340次。

千萬PV級別WEB站點架構(gòu)設(shè)計

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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