假如說我們現在要做一個千萬級用戶量網站,你怎麼設計高併發架構?

雲棲號資訊:【點擊查看更多行業資訊
在這裏您可以找到不同行業的第一手的上雲資訊,還在等什麼,快來!


之前的時候,阿粉一直在看同事面試,但是呢,阿粉並沒有自己去面試,而無意間打開Boss的時候,發現一家公司私聊了我,我回復了一下之後,竟然說我可以去面試,不曾想,面試一個問題,讓我的薪資瞬間被砍掉了5K,你如果不想自己出去要的薪資被砍,那麼你要會設計這個。

一般的普通項目架構

像阿粉的朋友所在的公司屬於一箇中小型的公司,公司的項目都是按照客戶的要求來定製進行開發的,而服務器的數量那是少的可憐,什麼高併發,不考慮,什麼高可用,也不考慮,一臺服務器上面部署了自己的項目,有時候連個圖片服務器都沒有,他們的圖就是這個樣子的。

1

是不是看着很簡陋的樣子,直接瀏覽器客戶端和單一服務器之間進行交流了,如果訪問人數在千人以上,比如秒殺個限量款,那估計可能直接就涼了,“Boom”的一下就訪問失敗了。

稍微進階版本的項目架構

這個時候一般網站架構還是採用單體架構,但是服務器也相對的增加了,終於增加了數據庫服務器和應用類服務器在加上圖片服務器,算是組成了一個小小的進階版本的項目架構。

2

也就是說我們在部署應用的時候,手動把應用服務器上的Tomcat給關掉,然後替換系統的代碼war包,接着重新啓動Tomcat。

這時候把數據單獨的部署在另外的一個服務器上面,存放網站的全部核心數據。

然後在另外一臺獨立的服務器上部署NFS作爲圖片服務器,存放網站的全部圖片。

這時候呢,代碼執行的是請求,數據訪問在另外一臺服務器,而圖片在另外一臺服務器上面,這樣就通過增加了服務器來部署的普通版本的項目架構就完成了,而大部分的項目都是這個樣子的吧,畢竟小公司人力有限呀。

簡單的支持高併發,高可用的項目架構

不知道大家在面試的時候說這個的時候面試官有沒有問過,如果你們的應用服務器掛了,你們怎麼處理?

是的,應用服務器真的會出事,那在項目的應用服務器真的出事之後,我們怎麼處理,在換個服務器,那麼你很多想對應的配置就要做出更改,需要更改一大堆的東西,那麼你會有很長時間的維護期,維護代價很高了呀。

這時候我們就出現了這個:

如果說我們有一臺其中的應用服務器宕機了,不幹活了,那麼接下來,另外的一臺服務器就會正常的使用,並且,在同時使用的時候,我們還能夠把從瀏覽器來的大量的請求分發一下,直接對半劈成2份,如果說其中有一個服務器的配置“高的飛起”,那麼我們還可以通過配置,給他的請求讓他多一點,“設置權重”,這樣讓他分擔更多的壓力,而那個比較 low 的服務器的話,承擔的相應的請求就會減少一點,畢竟性能比較低。

而在這個時候還會出現另外一種意外,那就是數據庫服務器宕機了,怎麼辦?相同的原理,增加另外的一個數據庫服務器,也就是主從數據庫。

3

那麼爲什麼要做主從複製,不單單是因爲這一個服務器宕機的問題,還有如果對數據庫的讀和寫都在同一個數據庫服務器中操作,業務系統性能會降低。

而我們很多的項目在數據上面需要的就是比較重要的,就很多就是做讀寫分離,而爲了提升業務系統性能,優化用戶體驗,可以通過做主從複製(讀寫分離)來減輕主數據庫的負載。

一臺用於寫入數據,一臺用於同步主的數據並用於數據查詢操作。

配置好主從複製之後,同一張表,只能對一個服務器寫操作。

業務分離

現在很多項目的架構都是所有人的業務代碼都寫在了一起,亂七八糟的,好幾個人的代碼,維護起來那叫一個崩潰,當你看到這樣的項目的時候,你就會發現,人都傻了,這是個什麼鬼,改動一點,其他的不好用了,那叫一個崩潰呀。

這時候我們就需要把我們的業務徹底的做出分割,比如商城裏面的,訂單屬於一塊的業務,積分屬於一部分的業務,物流屬於另外一部分的業務,這時候我們就需要分成三塊的業務模塊。

也就是相當於每一塊的內容都屬於一個服務,而這些服務疊加起來可就不是1+1=2的問題了,這些業務服務相加起來,這時候完整的項目和你把所有的內容同一寫到一個部分的內容差距是非常大的,尤其是在代碼冗餘方面,做的那是相當透徹的。

而說到這些內容的話,其實已經算差不多了,但是再更深的阿粉是真的沒有了解到那麼多,而阿粉之前沒想過這些內容會在你面試的時候問到,可能阿粉當時只是想自己做個鹹魚,不去關心架構方面的事情,而架構方面的事情確實很多公司很看重的一點。

在這裏阿粉給大家再次貢獻出此次面試的其他的問題,並且給出詳細的解答,並且阿粉也是很欣慰的,只是壓了工資,而沒有說直接拒絕。

1.Redis分區實現方案

  • 客戶端分區:

客戶端分區就是在客戶端就已經決定數據會被存儲到哪個redis節點或者從哪個redis節點讀取。大多數客戶端已經實現了客戶端分區。

  • 代理分區:

代理分區 意味着客戶端將請求發送給代理,然後代理決定去哪個節點寫數據或者讀數據。代理根據分區規則決定請求哪些Redis實例,然後根據Redis的響應結果返回給客戶端。

  • 查詢路由:

查詢路由(Query routing) 的意思是客戶端隨機地請求任意一個redis實例,然後由Redis將請求轉發給正確的Redis節點。Redis Cluster實現了一種混合形式的查詢路由,但並不是直接將請求從一個redis節點轉發到另一個redis節點,而是在客戶端的幫助下直接redirected到正確的redis節點。

這些都是阿粉死記硬背背下來的,關於這種東西,沒有實際親身實踐過的,沒有遇到過的問題的,都是屬於被diss的,但是面試官好像理解也不是很深,也是知道,但是具體的也沒有仔細的深挖我這塊的內容。

2.SpringBean的生命週期

說實話,這個問題,面試好像現在都是必問的知識點了,阿粉的同事面試也是被問,但是巧了,之前阿粉就寫過關於SpringBean的生命週期的,文章鏈接給大家送上,大家可以仔細查看,可以共同交流呦。

面試官:兄弟你來闡述一下Spring框架中Bean的生命週期?

所以大家一定要把這個準備好呦,SpringBean的生命週期,從初始化到最終的銷燬中間經歷了什麼,過程是什麼,流程怎麼理解。

3.HashMap 和 Hashtable

這個問題我在回答的時候我就分開了,分門別類的比較比如說:

  • 線程安全
  • 性能優劣
  • NULL
  • 實現方式
  • 容量擴容

我分成了五塊的內容作答,如果說你只能夠剛剛想起來其中的三到四點也是不錯的,至少比你只會說他們的線程安全和是否允許鍵爲空來的好很多,如果大家有興趣,請尋找集合系列文章,在過往的歷史當中尋找一下,有很多關於HashMap 和 Hashtable的面試點。

4.JVM內存模型和優化

這個我相信只要是工作了兩到三年的程序員肯定都會,我就給大家簡單說說,之前的文章圖解,

5

關於其他的問題,都不是比較經典的,都是屬於項目業務中的了,阿粉就不再一一給大家介紹了,總結起來就一句話,基礎你要掌握,擴展你更要會,不然面試想要高工資?那是不可能的,畢竟不是每家公司都缺“大爺”,不是麼?

阿粉在這裏希望大家找到自己理想的工作,等疫情穩定了,直接跳槽工資“Double”。

【雲棲號在線課堂】每天都有產品技術專家分享!
課程地址:https://yqh.aliyun.com/live

立即加入社羣,與專家面對面,及時瞭解課程最新動態!
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK

原文發佈時間:2020-07-28
本文作者:鴨血粉絲
本文來自:“cocoachina”,瞭解相關信息可以關注“cocoachina”

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