【乾貨走一波】千萬級用戶的大型網站，應該如何設計其高併發架構？

公衆號：狸貓技術窩
做者：原子彈大俠，阿里巴巴高級技術專家

目錄 （1）單塊架構

（2）初步的高可用架構

（3）千萬級用戶量的壓力預估

（4）服務器壓力預估

（5）業務垂直拆分

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

（7）基於數據庫主從架構作讀寫分離

（8）總結

本文將會從一個大型的網站發展歷程出發，一步一步的探索這個網站的架構是如何從單體架構，演化到分佈式架構，而後演化到高併發架構的。

（1）單塊架構

通常一個網站剛開始創建的時候，用戶量是不多的，大概可能就幾萬或者幾十萬的用戶量，天天活躍的用戶可能就幾百或者幾千個。

這個時候通常網站架構都是採用單體架構來設計的，總共就部署3臺服務器，1臺應用服務器，1臺數據庫服務器，1臺圖片服務器。

研發團隊一般都在10人之內，就是在一個單塊應用裏寫代碼，而後寫好以後合併代碼，接着就是直接在線上的應用服務器上發佈。極可能就是手動把應用服務器上的Tomcat給關掉，而後替換系統的代碼war包，接着從新啓動Tomcat。

數據庫通常就部署在一臺獨立的服務器上，存放網站的所有核心數據。

而後在另一臺獨立的服務器上部署NFS做爲圖片服務器，存放網站的所有圖片。應用服務器上的代碼會鏈接以及操做數據庫以及圖片服務器。以下圖所示：

（2）初步的高可用架構

可是這種純單塊系統架構下，有高可用問題存在，最大的問題就是應用服務器可能會故障，或者是數據庫可能會故障

因此在這個時期，通常稍微預算充足一點的公司，都會作一個初步的高可用架構出來。

對於應用服務器而言，通常會集羣化部署。固然所謂的集羣化部署，在初期用戶量不多的狀況下，其實通常也就是部署兩臺應用服務器而已，而後前面會放一臺服務器部署負載均衡設備，好比說LVS，均勻的把用戶請求打到兩臺應用服務器上去。

若是此時某臺應用服務器故障了，還有另一臺應用服務器是可使用的，這樣就避免了單點故障問題。以下圖所示：

對於數據庫服務器而言，此時通常也會使用主從架構，部署一臺從庫來從主庫同步數據，這樣一旦主庫出現問題，能夠迅速使用從庫繼續提供數據庫服務，避免數據庫故障致使整個系統都完全故障不可用。以下圖：

（3）千萬級用戶量的壓力預估

這個假設這個網站預估的用戶數是1000萬，那麼根據28法則，天天會來訪問這個網站的用戶佔到20%，也就是200萬用戶天天會過來訪問。

一般假設平均每一個用戶每次過來會有30次的點擊，那麼總共就有6000萬的點擊（PV）。

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

也就是說，在5小時內會有5000萬點擊進來。

換算下來，在那5小時的活躍訪問期內，大概每秒鐘會有3000左右的請求量，而後這5小時中可能又會出現大量用戶集中訪問的高峯時間段。

好比在集中半個小時內大量用戶涌入造成高峯訪問。根據線上經驗，通常高峯訪問是活躍訪問的2~3倍。假設咱們按照3倍來計算，那麼5小時內可能有短暫的峯值會出現每秒有10000左右的請求。

（4）服務器壓力預估

大概知道了高峯期每秒鐘可能會有1萬左右的請求量以後，來看一下系統中各個服務器的壓力預估。

通常來講一臺虛擬機部署的應用服務器，上面放一個Tomcat，也就支撐最多每秒幾百的請求。

按每秒支撐500的請求來計算，那麼支撐高峯期的每秒1萬訪問量，須要部署20臺應用服務。

並且應用服務器對數據庫的訪問量又是要翻幾倍的，由於假設一秒鐘應用服務器接收到1萬個請求，可是應用服務器爲了處理每一個請求可能要涉及到平均3~5次數據庫的訪問。

按照3次數據庫訪問來算，那麼每秒會對數據庫造成3萬次的請求。

按照一臺數據庫服務器最高支撐每秒5000左右的請求量，此時須要經過6臺數據庫服務器才能支撐每秒3萬左右的請求。

圖片服務器的壓力一樣會很大，由於須要大量的讀取圖片展現頁面，這個不太好估算，可是大體能夠推算出來每秒至少也會有幾千次請求，所以也須要多臺圖片服務器來支撐圖片訪問的請求。

（5）業務垂直拆分

通常來講在這個階段要作的第一件事兒就是業務的垂直拆分

由於若是全部業務代碼都混合在一塊兒部署，會致使多人協做開發時難以維護。在網站到了千萬級用戶的時候，研發團隊通常都有幾十人甚至上百人。

因此這時若是仍是在一個單塊系統裏作開發，是一件很是痛苦的事情，此時須要作的就是進行業務的垂直拆分，把一個單塊系統拆分爲多個業務系統，而後一個小團隊10我的左右就專門負責維護一個業務系統。以下圖

（6）分佈式緩存扛下讀請求

這個時候應用服務器層面通常沒什麼大問題，由於無非就是加機器就能夠抗住更高的併發請求。

如今估算出來每秒鐘是1萬左右的請求，部署個二三十臺機器就沒問題了。

可是目前上述系統架構中壓力最大的，實際上是數據庫層面 ，由於估算出來可能高峯期對數據庫的讀寫併發會有3萬左右的請求。

此時就須要引入分佈式緩存來抗下對數據庫的讀請求壓力了，也就是引入Redis集羣。

通常來講對數據庫的讀寫請求也大體遵循28法則，因此每秒3萬的讀寫請求中，大概有2.4萬左右是讀請求

這些讀請求基本上90%均可以經過分佈式緩存集羣來抗下來，也就是大概2萬左右的讀請求能夠經過 Redis集羣來抗住。

咱們徹底能夠把熱點的、常見的數據都在Redis集羣裏放一份做爲緩存，而後對外提供緩存服務。

在讀數據的時候優先從緩存裏讀，若是緩存裏沒有，再從數據庫裏讀取。這樣2萬讀請求就落到Redis上了，1萬讀寫請求繼續落在數據庫上。

Redis通常單臺服務器抗每秒幾萬請求是沒問題的，因此Redis集羣通常就部署3臺機器，抗下每秒2萬讀請求是絕對沒問題的。以下圖所示：

（7）基於數據庫主從架構作讀寫分離

此時數據庫服務器仍是存在每秒1萬的請求，對於單臺服務器來講壓力仍是過大。

可是數據庫通常都支持主從架構，也就是有一個從庫一直從主庫同步數據過去。此時能夠基於主從架構作讀寫分離。

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

這麼分攤事後，主庫每秒最多6000寫請求，從庫每秒最多4000讀請求，基本上能夠勉強把壓力給抗住。以下圖：

（8）總結

本文主要是探討在千萬級用戶場景下的大型網站的高併發架構設計，也就是預估出了千萬級用戶的訪問壓力以及對應的後臺系統爲了要抗住高併發，在業務系統、緩存、數據庫幾個層面的架構設計以及抗高併發的分析。

可是要記住，大型網站架構中共涉及的技術遠遠不止這些，還包括了MQ、CDN、靜態化、分庫分表、NoSQL、搜索、分佈式文件系統、反向代理，等等不少話題，可是本文不能一一涉及，主要是在高併發這個角度分析一下系統如何抗下每秒上萬的請求。

END

長按下圖二維碼，即刻關注【狸貓技術窩】 阿里、京東、美團、字節跳動 頂尖技術專家坐鎮 爲IT人打造一個 「有溫度」 的技術窩！