（1）單塊架構(gòu)

（2）初步的高可用架構(gòu)

（3）千萬(wàn)級(jí)用戶量的壓力預(yù)估

（4）服務(wù)器壓力預(yù)估

（5）業(yè)務(wù)垂直拆分

（6）用分布式緩存抗下讀請(qǐng)求

（7）基于數(shù)據(jù)庫(kù)主從架構(gòu)做讀寫分離

（8）總結(jié)

本文將會(huì)從一個(gè)大型的網(wǎng)站發(fā)展歷程出發(fā)，一步一步的探索這個(gè)網(wǎng)站的架構(gòu)是如何從單體架構(gòu)，演化到分布式架構(gòu)，然后演化到高并發(fā)架構(gòu)的。

一般一個(gè)網(wǎng)站剛開(kāi)始建立的時(shí)候，用戶量是很少的，大概可能就幾萬(wàn)或者幾十萬(wàn)的用戶量，每天活躍的用戶可能就幾百或者幾千個(gè)。

這個(gè)時(shí)候一般網(wǎng)站架構(gòu)都是采用單體架構(gòu)來(lái)設(shè)計(jì)的，總共就部署3臺(tái)服務(wù)器，1臺(tái)應(yīng)用服務(wù)器，1臺(tái)數(shù)據(jù)庫(kù)服務(wù)器，1臺(tái)圖片服務(wù)器。

研發(fā)團(tuán)隊(duì)通常都在10人以內(nèi)，就是在一個(gè)單塊應(yīng)用里寫代碼，然后寫好之后合并代碼，接著就是直接在線上的應(yīng)用服務(wù)器上發(fā)布。很可能就是手動(dòng)把應(yīng)用服務(wù)器上的Tomcat給關(guān)掉，然后替換系統(tǒng)的代碼war包，接著重新啟動(dòng)Tomcat。

數(shù)據(jù)庫(kù)一般就部署在一臺(tái)獨(dú)立的服務(wù)器上，存放網(wǎng)站的全部核心數(shù)據(jù)。

然后在另外一臺(tái)獨(dú)立的服務(wù)器上部署NFS作為圖片服務(wù)器，存放網(wǎng)站的全部圖片。應(yīng)用服務(wù)器上的代碼會(huì)連接以及操作數(shù)據(jù)庫(kù)以及圖片服務(wù)器。如下圖所示：

但是這種純單塊系統(tǒng)架構(gòu)下，有高可用問(wèn)題存在，大的問(wèn)題就是應(yīng)用服務(wù)器可能會(huì)故障，或者是數(shù)據(jù)庫(kù)可能會(huì)故障

所以在這個(gè)時(shí)期，一般稍微預(yù)算充足一點(diǎn)的公司，都會(huì)做一個(gè)初步的高可用架構(gòu)出來(lái)。

對(duì)于應(yīng)用服務(wù)器而言，一般會(huì)集群化部署。當(dāng)然所謂的集群化部署，在初期用戶量很少的情況下，其實(shí)一般也就是部署兩臺(tái)應(yīng)用服務(wù)器而已，然后前面會(huì)放一臺(tái)服務(wù)器部署負(fù)載均衡設(shè)備，比如說(shuō)LVS，均勻的把用戶請(qǐng)求打到兩臺(tái)應(yīng)用服務(wù)器上去。

如果此時(shí)某臺(tái)應(yīng)用服務(wù)器故障了，還有另外一臺(tái)應(yīng)用服務(wù)器是可以使用的，這樣就避免了單點(diǎn)故障問(wèn)題。如下圖所示：

對(duì)于數(shù)據(jù)庫(kù)服務(wù)器而言，此時(shí)一般也會(huì)使用主從架構(gòu)，部署一臺(tái)從庫(kù)來(lái)從主庫(kù)同步數(shù)據(jù)，這樣一旦主庫(kù)出現(xiàn)問(wèn)題，可以迅速使用從庫(kù)繼續(xù)提供數(shù)據(jù)庫(kù)服務(wù)，避免數(shù)據(jù)庫(kù)故障導(dǎo)致整個(gè)系統(tǒng)都徹底故障不可用。如下圖：

這個(gè)假設(shè)這個(gè)網(wǎng)站預(yù)估的用戶數(shù)是1000萬(wàn)，那么根據(jù)28法則，每天會(huì)來(lái)訪問(wèn)這個(gè)網(wǎng)站的用戶占到20%，也就是200萬(wàn)用戶每天會(huì)過(guò)來(lái)訪問(wèn)。

通常假設(shè)平均每個(gè)用戶每次過(guò)來(lái)會(huì)有30次的點(diǎn)擊，那么總共就有6000萬(wàn)的點(diǎn)擊（PV）。

每天24小時(shí)，根據(jù)28法則，每天大部分用戶最活躍的時(shí)間集中在（24小時(shí) * 0.2）≈ 5小時(shí)內(nèi)，而大部分用戶指的是（6000萬(wàn)點(diǎn)擊 * 0.8 ≈ 5000萬(wàn)點(diǎn)擊）

也就是說(shuō)，在5小時(shí)內(nèi)會(huì)有5000萬(wàn)點(diǎn)擊進(jìn)來(lái)。

換算下來(lái)，在那5小時(shí)的活躍訪問(wèn)期內(nèi)，大概每秒鐘會(huì)有3000左右的請(qǐng)求量，然后這5小時(shí)中可能又會(huì)出現(xiàn)大量用戶集中訪問(wèn)的高峰時(shí)間段。

比如在集中半個(gè)小時(shí)內(nèi)大量用戶涌入形成高峰訪問(wèn)。根據(jù)線上經(jīng)驗(yàn)，一般高峰訪問(wèn)是活躍訪問(wèn)的2~3倍。假設(shè)我們按照3倍來(lái)計(jì)算，那么5小時(shí)內(nèi)可能有短暫的峰值會(huì)出現(xiàn)每秒有10000左右的請(qǐng)求。

大概知道了高峰期每秒鐘可能會(huì)有1萬(wàn)左右的請(qǐng)求量之后，來(lái)看一下系統(tǒng)中各個(gè)服務(wù)器的壓力預(yù)估。

一般來(lái)說(shuō)一臺(tái)虛擬機(jī)部署的應(yīng)用服務(wù)器，上面放一個(gè)Tomcat，也就支撐最多每秒幾百的請(qǐng)求。

按每秒支撐500的請(qǐng)求來(lái)計(jì)算，那么支撐高峰期的每秒1萬(wàn)訪問(wèn)量，需要部署20臺(tái)應(yīng)用服務(wù)。

而且應(yīng)用服務(wù)器對(duì)數(shù)據(jù)庫(kù)的訪問(wèn)量又是要翻幾倍的，因?yàn)榧僭O(shè)一秒鐘應(yīng)用服務(wù)器接收到1萬(wàn)個(gè)請(qǐng)求，但是應(yīng)用服務(wù)器為了處理每個(gè)請(qǐng)求可能要涉及到平均3~5次數(shù)據(jù)庫(kù)的訪問(wèn)。

按照3次數(shù)據(jù)庫(kù)訪問(wèn)來(lái)算，那么每秒會(huì)對(duì)數(shù)據(jù)庫(kù)形成3萬(wàn)次的請(qǐng)求。

按照一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器高支撐每秒5000左右的請(qǐng)求量，此時(shí)需要通過(guò)6臺(tái)數(shù)據(jù)庫(kù)服務(wù)器才能支撐每秒3萬(wàn)左右的請(qǐng)求。

圖片服務(wù)器的壓力同樣會(huì)很大，因?yàn)樾枰罅康淖x取圖片展示頁(yè)面，這個(gè)不太好估算，但是大致可以推算出來(lái)每秒至少也會(huì)有幾千次請(qǐng)求，因此也需要多臺(tái)圖片服務(wù)器來(lái)支撐圖片訪問(wèn)的請(qǐng)求。

一般來(lái)說(shuō)在這個(gè)階段要做的第一件事兒就是業(yè)務(wù)的垂直拆分

因?yàn)槿绻袠I(yè)務(wù)代碼都混合在一起部署，會(huì)導(dǎo)致多人協(xié)作開(kāi)發(fā)時(shí)難以維護(hù)。在網(wǎng)站到了千萬(wàn)級(jí)用戶的時(shí)候，研發(fā)團(tuán)隊(duì)一般都有幾十人甚至上百人。

所以這時(shí)如果還是在一個(gè)單塊系統(tǒng)里做開(kāi)發(fā)，是一件非常痛苦的事情，此時(shí)需要做的就是進(jìn)行業(yè)務(wù)的垂直拆分，把一個(gè)單塊系統(tǒng)拆分為多個(gè)業(yè)務(wù)系統(tǒng)，然后一個(gè)小團(tuán)隊(duì)10個(gè)人左右就專門負(fù)責(zé)維護(hù)一個(gè)業(yè)務(wù)系統(tǒng)。如下圖

這個(gè)時(shí)候應(yīng)用服務(wù)器層面一般沒(méi)什么大問(wèn)題，因?yàn)闊o(wú)非就是加機(jī)器就可以抗住更高的并發(fā)請(qǐng)求。

現(xiàn)在估算出來(lái)每秒鐘是1萬(wàn)左右的請(qǐng)求，部署個(gè)二三十臺(tái)機(jī)器就沒(méi)問(wèn)題了。

但是目前上述系統(tǒng)架構(gòu)中壓力大的，其實(shí)是數(shù)據(jù)庫(kù)層面 ，因?yàn)楣浪愠鰜?lái)可能高峰期對(duì)數(shù)據(jù)庫(kù)的讀寫并發(fā)會(huì)有3萬(wàn)左右的請(qǐng)求。

此時(shí)就需要引入分布式緩存來(lái)抗下對(duì)數(shù)據(jù)庫(kù)的讀請(qǐng)求壓力了，也就是引入Redis集群。

一般來(lái)說(shuō)對(duì)數(shù)據(jù)庫(kù)的讀寫請(qǐng)求也大致遵循28法則，所以每秒3萬(wàn)的讀寫請(qǐng)求中，大概有2.4萬(wàn)左右是讀請(qǐng)求

這些讀請(qǐng)求基本上90%都可以通過(guò)分布式緩存集群來(lái)抗下來(lái)，也就是大概2萬(wàn)左右的讀請(qǐng)求可以通過(guò) Redis集群來(lái)抗住。

我們完全可以把熱點(diǎn)的、常見(jiàn)的數(shù)據(jù)都在Redis集群里放一份作為緩存，然后對(duì)外提供緩存服務(wù)。

在讀數(shù)據(jù)的時(shí)候優(yōu)先從緩存里讀，如果緩存里沒(méi)有，再?gòu)臄?shù)據(jù)庫(kù)里讀取。這樣2萬(wàn)讀請(qǐng)求就落到Redis上了，1萬(wàn)讀寫請(qǐng)求繼續(xù)落在數(shù)據(jù)庫(kù)上。

Redis一般單臺(tái)服務(wù)器抗每秒幾萬(wàn)請(qǐng)求是沒(méi)問(wèn)題的，所以Redis集群一般就部署3臺(tái)機(jī)器，抗下每秒2萬(wàn)讀請(qǐng)求是絕對(duì)沒(méi)問(wèn)題的。如下圖所示：

此時(shí)數(shù)據(jù)庫(kù)服務(wù)器還是存在每秒1萬(wàn)的請(qǐng)求，對(duì)于單臺(tái)服務(wù)器來(lái)說(shuō)壓力還是過(guò)大。

但是數(shù)據(jù)庫(kù)一般都支持主從架構(gòu)，也就是有一個(gè)從庫(kù)一直從主庫(kù)同步數(shù)據(jù)過(guò)去。此時(shí)可以基于主從架構(gòu)做讀寫分離。

也就是說(shuō)，每秒大概6000寫請(qǐng)求是進(jìn)入主庫(kù)，大概還有4000個(gè)讀請(qǐng)求是在從庫(kù)上去讀，這樣就可以把1萬(wàn)讀寫請(qǐng)求壓力分?jǐn)偟絻膳_(tái)服務(wù)器上去。

這么分?jǐn)傔^(guò)后，主庫(kù)每秒最多6000寫請(qǐng)求，從庫(kù)每秒最多4000讀請(qǐng)求，基本上可以勉強(qiáng)把壓力給抗住。如下圖：

本文主要是探討在千萬(wàn)級(jí)用戶場(chǎng)景下的大型網(wǎng)站的高并發(fā)架構(gòu)設(shè)計(jì)，也就是預(yù)估出了千萬(wàn)級(jí)用戶的訪問(wèn)壓力以及對(duì)應(yīng)的后臺(tái)系統(tǒng)為了要抗住高并發(fā)，在業(yè)務(wù)系統(tǒng)、緩存、數(shù)據(jù)庫(kù)幾個(gè)層面的架構(gòu)設(shè)計(jì)以及抗高并發(fā)的分析。

但是要記住，大型網(wǎng)站架構(gòu)中共涉及的技術(shù)遠(yuǎn)遠(yuǎn)不止這些，還包括了MQ、CDN、靜態(tài)化、分庫(kù)分表、NoSQL、搜索、分布式文件系統(tǒng)、反向代理，等等很多話題，但是本文不能一一涉及，主要是在高并發(fā)這個(gè)角度分析一下系統(tǒng)如何抗下每秒上萬(wàn)的請(qǐng)求。

當(dāng)前題目：一個(gè)大型的網(wǎng)站高并發(fā)架構(gòu)實(shí)例
當(dāng)前URL：http://jinyejixie.com/news/103867.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、網(wǎng)站收錄、Google、品牌網(wǎng)站制作、企業(yè)網(wǎng)站制作、搜索引擎優(yōu)化

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)