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

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

（3）千萬級用戶量的壓力預(yù)估

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

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

（6）用分布式緩存抗下讀請求

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

（8）總結(jié)

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

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

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

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

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

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

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

所以在這個時期，一般稍微預(yù)算充足一點的公司，都會做一個初步的高可用架構(gòu)出來。

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

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

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

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

通常假設(shè)平均每個用戶每次過來會有30次的點擊，那么總共就有6000萬的點擊（PV）。

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

也就是說，在5小時內(nèi)會有5000萬點擊進來。

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

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

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

一般來說一臺虛擬機部署的應(yīng)用服務(wù)器，上面放一個Tomcat，也就支撐最多每秒幾百的請求。

按每秒支撐500的請求來計算，那么支撐高峰期的每秒1萬訪問量，需要部署20臺應(yīng)用服務(wù)。

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

按照3次數(shù)據(jù)庫訪問來算，那么每秒會對數(shù)據(jù)庫形成3萬次的請求。

按照一臺數(shù)據(jù)庫服務(wù)器高支撐每秒5000左右的請求量，此時需要通過6臺數(shù)據(jù)庫服務(wù)器才能支撐每秒3萬左右的請求。

圖片服務(wù)器的壓力同樣會很大，因為需要大量的讀取圖片展示頁面，這個不太好估算，但是大致可以推算出來每秒至少也會有幾千次請求，因此也需要多臺圖片服務(wù)器來支撐圖片訪問的請求。

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

因為如果所有業(yè)務(wù)代碼都混合在一起部署，會導(dǎo)致多人協(xié)作開發(fā)時難以維護。在網(wǎng)站到了千萬級用戶的時候，研發(fā)團隊一般都有幾十人甚至上百人。

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

這個時候應(yīng)用服務(wù)器層面一般沒什么大問題，因為無非就是加機器就可以抗住更高的并發(fā)請求。

現(xiàn)在估算出來每秒鐘是1萬左右的請求，部署個二三十臺機器就沒問題了。

但是目前上述系統(tǒng)架構(gòu)中壓力大的，其實是數(shù)據(jù)庫層面 ，因為估算出來可能高峰期對數(shù)據(jù)庫的讀寫并發(fā)會有3萬左右的請求。

此時就需要引入分布式緩存來抗下對數(shù)據(jù)庫的讀請求壓力了，也就是引入Redis集群。

一般來說對數(shù)據(jù)庫的讀寫請求也大致遵循28法則，所以每秒3萬的讀寫請求中，大概有2.4萬左右是讀請求

這些讀請求基本上90%都可以通過分布式緩存集群來抗下來，也就是大概2萬左右的讀請求可以通過 Redis集群來抗住。

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

在讀數(shù)據(jù)的時候優(yōu)先從緩存里讀，如果緩存里沒有，再從數(shù)據(jù)庫里讀取。這樣2萬讀請求就落到Redis上了，1萬讀寫請求繼續(xù)落在數(shù)據(jù)庫上。

Redis一般單臺服務(wù)器抗每秒幾萬請求是沒問題的，所以Redis集群一般就部署3臺機器，抗下每秒2萬讀請求是絕對沒問題的。如下圖所示：

此時數(shù)據(jù)庫服務(wù)器還是存在每秒1萬的請求，對于單臺服務(wù)器來說壓力還是過大。

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

也就是說，每秒大概6000寫請求是進入主庫，大概還有4000個讀請求是在從庫上去讀，這樣就可以把1萬讀寫請求壓力分攤到兩臺服務(wù)器上去。

這么分攤過后，主庫每秒最多6000寫請求，從庫每秒最多4000讀請求，基本上可以勉強把壓力給抗住。如下圖：

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

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

網(wǎng)站欄目：一個大型的網(wǎng)站高并發(fā)架構(gòu)實例
文章地址：http://www.rwnh.cn/news17/103867.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供關(guān)鍵詞優(yōu)化、企業(yè)建站、網(wǎng)頁設(shè)計公司、網(wǎng)站制作、小程序開發(fā)、商城網(wǎng)站

廣告

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