搞清楚系統到底怎樣支撐高併發以及架構圖的繪製(面試向)

原文轉載自「劉悅的技術博客」https://v3u.cn/a_id_95

大多數人面試的時候經常會被問到:你簡歷上有高負載高併發的經驗,那到底你的系統是怎樣設計的?

如果沒有過相關的項目經驗,大多數同學被問到這個問題壓根兒沒什麼思路去回答,不知道從什麼地方說起,其實,就算沒有相關的經驗,只要事先編好話術,搞清楚架構圖,回答此類問題也還是可以滴水不漏的。

首先,在腦子裏虛擬一個大用戶量背景下的場景,如果我們手頭有幾臺4核8g的服務器,假設一個平臺用戶量是500萬。此時日活用戶是50萬,日訪問量在600-700萬左右,高峯期對系統每秒請求是500/s。然後對數據庫的每秒請求數量是1500/s,這個時候會怎麼樣呢?如果系統內處理的是較爲複雜的一些業務邏輯,是那種重業務邏輯的系統的話,是比較耗費CPU的。此時,4核8G的機器每秒請求達到500/s的時候,很可能你的機器CPU負載較高了。然後數據庫層面,以上述的配置而言,其實基本上1500/s的高峯請求壓力的話,還算可以接受。這個主要是要觀察數據庫所在機器的磁盤負載、網絡負載、CPU負載、內存負載,按照我們的線上經驗而言,那個配置的數據庫在1500/s請求壓力下是沒問題的。所以此時需要做的一個事情,首先就是要支持你的系統集羣化部署。可以在前面掛一個負載均衡層,把請求均勻打到系統層面,讓系統可以用多臺機器集羣化支撐更高的併發壓力。比如說這裏假設給系統增加部署一臺機器,那麼每臺機器就只有250/s的請求了。這樣一來,兩臺機器的CPU負載都會明顯降低,這個初步的“高併發”不就先抗住住了嗎?要是連這個都不做,那單臺機器負載越來越高的時候,極端情況下是可能出現機器上部署的系統無法有足夠的資源響應請求了,然後出現請求卡死,甚至系統宕機之類的問題。所以,簡單小結,第一步要做的:添加負載均衡層,將請求均勻打到系統層。系統層採用集羣化部署多臺機器,扛住初步的併發壓力。

架構圖如下:

然後,經過了幾個月的增長期,假設此時用戶量繼續增長,達到了1000萬註冊用戶,然後每天日活用戶是100萬,日訪問量在800-1000萬。那麼此時對系統層面的請求量會達到每秒1000/s,系統層面,你可以繼續通過集羣化的方式來擴容,反正前面的負載均衡層會均勻分散流量過去的。但是,這時數據庫層面接受的請求量會達到3000/s,這個就有點問題了。此時數據庫層面的併發請求翻了一倍,你一定會發現線上的數據庫負載越來越高。每次到了高峯期,磁盤IO、網絡IO、內存消耗、CPU負載的壓力都會很高,大家很擔心數據庫服務器能否抗住。沒錯,一般來說,對那種普通配置的線上數據庫,建議就是讀寫併發加起來,按照上述我們舉例的那個配置,不要超過3000/s。因爲數據庫壓力過大,首先一個問題就是高峯期系統性能可能會降低,因爲數據庫負載過高對性能會有影響。另外一個,壓力過大把你的數據庫給搞掛了怎麼辦?所以此時你必須得對系統做分庫分表 + 讀寫分離,也就是把一個庫拆分爲多個庫,部署在多個數據庫服務上,這是作爲主庫承載寫入請求的。然後每個主庫都掛載至少一個從庫,由從庫來承載讀請求。此時假設對數據庫層面的讀寫併發是3000/s,其中寫併發佔到了1000/s,讀併發佔到了2000/s。那麼一旦分庫分表之後,採用兩臺數據庫服務器上部署主庫來支撐寫請求,每臺服務器承載的寫併發就是500/s。每臺主庫掛載一個服務器部署從庫,那麼2個從庫每個從庫支撐的讀併發就是1000/s。簡單總結,併發量繼續增長時,我們就需要專注在數據庫層面:分庫分表、讀寫分離。

如果註冊用戶量越來越大,此時你可以不停地加機器,比如說系統層面不停加機器,就可以承載更高的併發請求。然後數據庫層面如果寫入併發越來越高,就擴容加數據庫服務器,通過分庫分表是可以支持擴容機器的,如果數據庫層面的讀併發越來越高,就擴容加更多的從庫。但是這裏有一個很大的問題:數據庫其實本身不是用來承載高併發請求的。所以通常來說,數據庫單機每秒承載的併發就在幾千的數量級,而且數據庫使用的機器都是比較高配置,比較昂貴的機器,成本很高。如果不停地加機器,這是不對的。在高併發架構裏通常都有緩存這個環節,緩存系統的設計就是爲了承載高併發而生。單機承載的併發量都在每秒幾萬,甚至每秒數十萬,對高併發的承載能力比數據庫系統要高出一到兩個數量級。可以根據系統的業務特性,對那種寫少讀多的請求,引入緩存集羣。具體來說,就是在寫數據庫的時候同時寫一份數據到緩存集羣裏,然後用緩存集羣來承載大部分的讀請求。這樣的話,通過緩存集羣,就可以用更少的機器資源承載更高的併發。比如說上面那個圖裏,讀請求目前是每秒1000/s,兩個從庫各自抗了500/s讀請求,但是其中可能每秒800次的讀請求都是可以直接讀緩存裏的不怎麼變化的數據的。那麼此時你一旦引入緩存集羣,就可以抗下來這800/s讀請求,落到數據庫層面的讀請求就200/s。

架構圖如下:

初步來說,簡單的一個高併發系統的闡述是說完了,是不是很簡單呢?

原文轉載自「劉悅的技術博客」 https://v3u.cn/a_id_95

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章