Web開發中,什麼級別才算是高併發

大愚Talk發表於2019-02-16

這並不是一個回答的問題的文章,而是由此引發的一個思考。

大家心裡仔細想想,當你們聽到高併發網站時,心裡對這個網站是個什麼概念?首先想到的是淘寶嗎?帶著問題,我們一起思考技術

寫這個話題是因為我對搜尋引擎給我的答案很不滿意,然後決定把思考的一些東西分享出來,希望可以大家彼此討論下。

我們經常在面試的時候,被問到有沒有高併發的經驗?先不說哪些考高併發的裝逼公司。我思考的是什麼才算是高併發?你一天幾個pv肯定高不了。首先在網上查詢一下,並未找到明確的標準定義。那麼什麼是併發呢?

併發,在作業系統中,是指一個時間段中有幾個程式都處於已啟動執行到執行完畢之間,且這幾個程式都是在同一個處理機上執行,但任一個時刻點上只有一個程式在處理機上執行。

摘自百度百科

我們說的高併發是什麼?

上面的定義明顯不是我們通常所言的併發,在網際網路時代,所講的併發、高併發,通常是指併發訪問。也就是在某個時間點,有多少個訪問同時到來。

我看到有人給高併發下了類似的定義:

高併發通常是指我們提供的系統服務能夠同時並行處理很多請求。

來看看這個定義,這裡首先把併發給混淆到並行了。關於併發並行的區別看這裡,我就不多說,繼續探討併發。

然後定義又說很多請求?什麼叫很多請求?做為中國人,這個詞讓我想象力一發不可收拾……好了,拉回來,繼續本文。

那麼從上面的分析,可以看出來高併發在網路上業界也沒有明確的定義。但根據我搜尋情況,一般都是pv在千萬級別以上的公司才會涉及到這個概念。所以我得出一個自定義概念:如果某個系統的日pv在千萬級別以上,他就可能是一個高併發的系統。

為什麼說是可能?那是因為有的公司完全不走技術路線,全靠機器堆,這不在我們的討論範圍。

高併發的問題,我們具體該關心什麼?

講真話,高併發是個比較抽象的概念。很難有一個統一的可衡量的標準。哪麼有一些其它維度的標準指標來衡量系統的效能嗎?搬出以前計算機課程裡邊的一些指標來跟大家聊聊。

先宣告幾個概念,別打瞌睡。

  • QPS(TPS):每秒鐘 request/事務 數量,在網際網路領域,指每秒響應請求數(指http請求);
  • 吞吐量:單位時間內處理的請求數量(通常由QPS與併發數決定);
  • 響應時間:系統對一個請求做出響應的平均時間。例如系統處理一個HTTP請求需要200ms,這個200ms就是系統的響應時間(我認為這裡應該僅包含處理時間,網路傳輸時間忽略)。

這裡一定要注意呃,QPS ≠ 併發數

併發是指,某個時刻有多少個訪問同時到來。QPS是指秒鐘響應的請求數量。那麼這裡就肯容易推算出一個公式:

QPS = 併發數 / 平均響應時間

後面我們的分析都是圍繞這個公示來進行展開,沒明白的再回味一下。

現在我們來假設一個場景:既然QPS是每秒鐘處理的http請求數量。那麼1s = 1000ms。假設我們當前一個http請求伺服器處理完成需要100ms(即那麼 平均響應時間 = 100ms )。那麼它1s鍾可以處理10個請求。也就是說 qps = 10。推算出 併發數 = 10

常常我們被問到高併發的問題,其實從某種程度上來說是怎麼提高現有程式的效能。現在我們基於上面的假設,來進行分析。假設現在有個系統效能上就是我們上面的假設,它每天有 300萬pv,執行在單機上(當然經常當機),按照上面的系統效能資料,給出優化解決方案。

提高併發能力

通過上面的分析,要提升併發能力,我們就需要提升我們的qps(其實這裡並不完全正確,為了說明問題,我們先放棄一部分正確性

最快速解決方案,就是增加機器。我們根據以上情況來實際計算一下。

  • 訪問量:200w pv
  • QPS:10

根據日常經驗,80% 的訪問量集中在 20%的時間,算一下這 200w pv實際需要機器達到多少qps才能滿足。

qps = (200w * 0.8) / (24 * 3600 * 0.3)

qps = 61.7

實際上如果在單機上,要求我們每秒鐘處理請求必須達到 61.7 以上才行,而實際上我們當前系統的qps是 10。那麼怎麼解決?

方案一:上機器

個人的能力是有限的,團隊的力量是無窮的。既然一臺機器搞不定,我們就多上幾臺機器。這就涉及到db主從、讀寫分離、負載均衡等技術。

它的原理就是分流,把以前集中的壓力分散開來。改方案見效快,靈活,實踐起來也更快。

方案二:增加單機效能

單機到底效能能夠增加到一個什麼程度,這取決於你的機器配置,也取決於你的服務到底有多複雜。

ps: 寫到這裡突然有點能夠理解為什網上對高併發都是講很多請求,沒有具體資料了,因為這真的只能針對業務來講,100個併發對靜態網頁來說根本沒有的事兒,但是對於某些密集計算型的估計…

那麼常見的單機如何提升效能?比如:增加不常變化資料的快取,開啟php的opcache,優化程式碼(如:n+1問題、多重巢狀迴圈、深層遞迴等),db表優化等等。由於這些每一個點拿出來都夠寫一本書了。咋就不繼續下去。

總結

由於筆者自己也是沒有實際經歷過kw級別pv場景,很多東西講的不一定對,本文也是理清自己的一點思路。希望能夠與更多朋友進行討論。

也希望本文能夠解決你的一點疑惑,讓我們能夠從高大上的概念落實到實際問題中去。

參考資料


GitHub:https://github.com/helei112g

我在github開源了支付寶支付、微信支付、招商一網通支付的php sdk。希望能夠幫助你提升專案開發的效率。專案地址

相關文章