如何為擁有千萬用戶的大型網站設計高并發架構?

發布時間:2020-04-24 12:20:00

本文將從一個大型網站的開發入手,逐步探索該網站的架構是如何從單一架構發展到分布式架構,再發展到高度并發架構的。

如何為擁有千萬用戶的大型網站設計高并發架構?

本文將從一個大型網站的開發入手,逐步探索該網站的架構是如何從單一架構發展到分布式架構,再發展到高度并發架構的。

一般來說,一個網站剛建立時,用戶數量非常少,可能有幾萬或幾十萬用戶,每天活躍的用戶數量可能有幾百或幾千。

此時,通用網站架構采用單一框架設計,共部署3臺服務器、1臺應用服務器、1臺數據庫服務器和1臺鏡像服務器。

研發團隊通常不到10人,即在單個塊應用程序中編寫代碼,編寫完成后合并代碼,然后直接在在線應用服務器上發布。它可能會手動關閉應用服務器上的Tomcat,替換系統代碼war包,然后重新啟動Tomcat。

一般來說,數據庫部署在一個獨立的服務器上以存儲網站的所有核心數據。

然后,我們將NFS部署為另一個獨立服務器上的圖片服務器,以存儲網站的所有圖片。應用服務器上的代碼將連接并操作數據庫和映像服務器。如下圖所示:

然而,在這種純單塊系統架構下,存在高可用性問題。最大的問題是應用服務器可能會失敗,或者數據庫可能會失敗

因此,在這一時期,預算很少的公司將制定一個初步的高可用性架構。

對于應用服務器,它們通常部署在集群中。當然,所謂的集群部署,在初始階段只有少數用戶的情況下,通常只是部署兩個應用服務器。然后在前面放置一個服務器來部署負載平衡設備(如LVS),以便將用戶請求均勻地發送到兩個應用服務器。

如果此時某個應用服務器出現故障,則可以使用另一個應用服務器,以避免出現單點故障。如下圖所示:

對于數據庫服務器,此時通常使用主從式體系結構。將部署一個從數據庫以同步主數據庫中的數據。一旦主數據庫出現問題,可以快速使用從數據庫繼續提供數據庫服務,從而避免因數據庫故障而導致整個系統的完全故障。下圖:

假設該網站的估計用戶數為1000萬,根據規則28,20%的用戶將每天訪問該網站,也就是說,每***有200萬用戶訪問該網站。

通常假設每個用戶每次有30次點擊,所以總共有6000萬次點擊(PV)。

也就是說,5小時內點擊量將達到5000萬次。

也就是說,在5小時的主動訪問期間,每秒將有大約3000個請求,然后在5小時的主動訪問期間,可能會有大量用戶的集中訪問高峰期。

在知道峰值期間每秒可能有10000個請求之后,讓我們看看系統中每個服務器的壓力預測。

一般來說,由虛擬機部署的應用服務器(上面有一個Tomcat)每秒最多支持幾百個請求。

以每秒支持500個請求計算,需要部署20個應用程序服務,以支持高峰期每秒10000次訪問。

此外,應用服務器對數據庫的訪問量成倍增加,因為假定應用服務器每秒接收10000個請求,但應用服務器可能平均需要3-5次數據庫訪問才能處理每個請求。

基于三次數據庫訪問,每秒將生成30000個對數據庫的請求。

根據數據庫服務器每秒支持的最大請求數,此時需要通過6個數據庫服務器每秒支持約30000個請求。

圖像服務器的壓力也會很大,因為需要讀取大量的圖像顯示頁面,這不容易估計,但可以粗略估計,每秒至少會有數千個請求,因此還需要多個圖像服務器來支持圖像訪問的請求。

一般來說,在這個階段首先要做的是垂直分割業務

因為如果所有的業務代碼都混合在一起并部署在一起,那么當多個人一起工作時就很難維護。當網站的用戶達到數千萬時,研發團隊通常會有幾十人甚至幾百人。

所以在一個單一的系統中開發是一件非常痛苦的事情。我們現在需要做的是把業務垂直拆分,把一個單塊系統拆分成多個業務系統,然后一個10人左右的小團隊專門負責維護一個業務系統。下表

此時,應用服務器級別通常沒有大問題,因為只有添加機器才能抵抗更高的并發請求。

現在估計每秒大約有10000個請求,所以可以部署20或30臺機器。

但目前,上述系統架構中最大的壓力實際上是在數據庫層面,因為據估計,在高峰期將有約30000個并發的數據庫讀寫請求。

此時,我們需要引入分布式緩存來抵抗向數據庫讀取請求的壓力,即引入redis集群。

基本上90%的讀請求可以被分布式緩存集群抵抗,也就是說,大約20000個讀請求可以被redis集群抵抗。

我們可以在redis集群中放置一個熱數據和公共數據的副本作為緩存,然后對外提供緩存服務。

讀取數據時,應優先從緩存中讀取。如果沒有緩存,則從數據庫中讀取。這樣,20000個讀請求落在redis上,10000個讀寫請求繼續落在數據庫上。

一般來說,一臺服務器每秒可以抵抗數萬個請求,所以redis集群通常部署三臺機器,每秒抵抗20000個讀請求是絕對可以的。如下圖所示:

此時,數據庫服務器每秒仍有10000個請求,這對單個服務器來說壓力太大。

但是,數據庫通常支持主從式體系結構,也就是說,有一個從式數據庫正在同步來自主數據庫的數據。此時,我們可以在主從結構的基礎上進行讀寫分離。

也就是說,每秒大約6000個寫請求進入主庫,大約4000個讀請求從庫中讀取,這樣10000個讀寫請求的壓力就可以分配到兩個服務器。

分配后,主數據庫每秒可寫入6000個請求,從數據庫每秒可讀取4000個請求?;旧?,壓力是可以抵抗的。下圖:

本文主要討論了千萬用戶場景下大型網站的高并發架構設計,即為了抵抗高并發,估計千萬用戶和相應的后臺系統的訪問壓力,業務系統、緩存和數據庫中高并發性的體系結構設計與分析。

但請記住,大型網站架構所涉及的技術遠不止這些,包括MQ、CDN、static、子數據庫和子表、NoSQL、search、分布式文件系統、逆向代理等許多主題,但本文不能一一介紹,主要從高并發的角度來分析系統如何能夠抵抗每秒數萬個請求。


聯系我們,談您的需求

立即咨詢
推广微信支付还能赚钱 泰和新材股票 九鼎新材股票行情 澳门六会彩资料图片 免费下载麻将 上海11选5走势图开奖 精准内部资料一波中特 成都遇乐棋牌大厅官网 北京快中彩质合走势图 浙江股票微信交流群 22选5开奖时间