架構師眼中的高併發架構

2022-08-03 12:03:14 字數 3969 閱讀 3199

三、分層,分割,分布式

四、集群

五、非同步

六、快取

七、面向服務

八、冗餘,自動化

九、總結

高併發經常會發生在有大活躍使用者量,使用者高聚集的業務場景中,如:秒殺活動,定時領取紅包等。

為了讓業務可以流暢的執行並且給使用者乙個好的互動體驗,我們需要根據業務場景預估達到的併發量等因素,來設計適合自己業務場景的高併發處理方案。

業務從發展的初期到逐漸成熟,伺服器架構也是從相對單一到集群,再到分布式服務。

乙個可以支援高併發的服務少不了好的伺服器架構,需要有均衡負載,資料庫需要主從集群,nosql快取需要主從集群,靜態檔案需要上傳cdn,這些都是能讓業務程式流暢執行的強大後盾。

伺服器這塊多是需要運維人員來配合搭建,具體我就不多說了,點到為止。

大致需要用到的伺服器架構如下:

資料庫nosql

cdn高併發相關的業務,需要進行併發的測試,通過大量的資料分析評估出整個架構可以支撐的併發量。

測試高併發可以使用第三方伺服器或者自己測試伺服器,利用測試工具進行併發請求測試,分析測試資料得到可以支撐併發數量的評估,這個可以作為乙個預警參考,俗話說知己自彼百戰不殆。

第三方服務:

併發測試工具:

2.2.1 通用方案

日使用者流量大,但是比較分散,偶爾會有使用者高聚的情況;

場景: 使用者簽到,使用者中心,使用者訂單,等

伺服器架構圖:

說明:更新使用者相關快取需要分布式儲存,比如使用使用者id進行hash分組,把使用者分布到不同的快取中,這樣乙個快取集合的總量不會很大,不會影響查詢效率。

方案如:

使用者訂單

使用者中心

其他業務

以上例子是乙個相對簡單的高併發架構,併發量不是很高的情況可以很好的支撐,但是隨著業務的壯大,使用者併發量增加,我們的架構也會進行不斷的優化和演變,比如對業務進行服務化,每個服務有自己的併發架構,自己的均衡伺服器,分布式資料庫,nosql主從集群,如:使用者服務、訂單服務;

2.2.2 訊息佇列
秒殺、秒搶等活動業務,使用者在瞬間湧入產生高併發請求

場景:定時領取紅包,等

伺服器架構圖:

說明:場景中的定時領取是乙個高併發的業務,像秒殺活動使用者會在到點的時間湧入,db瞬間就接受到一記暴擊,hold不住就會宕機,然後影響整個業務;

像這種不是只有查詢的操作並且會有高併發的插入或者更新資料的業務,前面提到的通用方案就無法支撐,併發的時候都是直接命中db;

設計這塊業務的時候就會使用訊息佇列的,可以將參與使用者的資訊新增到訊息佇列中,然後再寫個多執行緒程式去消耗佇列,給佇列中的使用者發放紅包;

方案如:

附加:通過訊息佇列可以做很多的服務。

如:定時簡訊傳送服務,使用sset(sorted set),傳送時間戳作為排序依據,簡訊資料佇列根據時間公升序,然後寫個程式定時迴圈去讀取sset佇列中的第一條,當前時間是否超過傳送時間,如果超過就進行簡訊傳送。

2.2.3 一級快取

高併發請求連線快取伺服器超出伺服器能夠接收的請求連線量,部分使用者出現建立連線超時無法讀取到資料的問題;

因此需要有個方案當高併發時候時候可以減少命中快取伺服器;

這時候就出現了一級快取的方案,一級快取就是使用站點伺服器快取去儲存資料,注意只儲存部分請求量大的資料,並且快取的資料量要控制,不能過分的使用站點伺服器的記憶體而影響了站點應用程式的正常執行,一級快取需要設定秒單位的過期時間,具體時間根據業務場景設定,目的是當有高併發請求的時候可以讓資料的獲取命中到一級快取,而不用連線快取nosql資料伺服器,減少nosql資料伺服器的壓力

伺服器架構圖:

合理的規範和使用nosql快取資料庫,根據業務拆分快取資料庫的集群,這樣基本可以很好支援業務,一級快取畢竟是使用站點伺服器快取所以還是要善用。

2.2.4 靜態化資料

高併發請求資料不變化的情況下如果可以不請求自己的伺服器獲取資料那就可以減少伺服器的資源壓力。

對於更新頻繁度不高,並且資料允許短時間內的延遲,可以通過資料靜態化成json,xml,html等資料檔案上傳cdn,在拉取資料的時候優先到cdn拉取,如果沒有獲取到資料再從快取,資料庫中獲取,當管理人員操作後台編輯資料再重新生成靜態檔案上傳同步到cdn,這樣在高併發的時候可以使資料的獲取命中在cdn伺服器上。

cdn節點同步有一定的延遲性,所以找乙個靠譜的cdn伺服器商也很重要

2.2.5 其他方案

大型**要很好支撐高併發,這是需要長期的規劃設計

在初期就需要把系統進行分層,在發展過程中把核心業務進行拆分成模組單元,根據需求進行分布式部署,可以進行獨立團隊維護開發。

分割分布式

**分層-圖1來自網路

對於使用者訪問集中的業務獨立部署伺服器,應用伺服器,資料庫,nosql資料庫。 核心業務基本上需要搭建集群,即多台伺服器部署相同的應用構成乙個集群,通過負載均衡裝置共同對外提供服務, 伺服器集群能夠為相同的服務提供更多的併發支援,因此當有更多的使用者訪問時,只需要向集群中加入新的機器即可, 另外可以實現當其中的某台伺服器發生故障時,可以通過負載均衡的失效轉移機制將請求轉移至集群中其他的伺服器上,因此可以提高系統的可用性

(關係/nosql)資料庫集群

通過反向**均衡負載

在高併發業務中如果涉及到資料庫操作,主要壓力都是在資料庫伺服器上面,雖然使用主從分離,但是資料庫操作都是在主庫上操作,單台資料庫伺服器連線池允許的最大連線數量是有限的

當連線數量達到最大值的時候,其他需要連線資料操作的請求就需要等待有空閒的連線,這樣高併發的時候很多請求就會出現connection time out 的情況

那麼像這種高併發業務我們要如何設計開發方案可以降低資料庫伺服器的壓力呢?

設計考慮:

方案設計:

補充:高併發業務介面多數都是進行業務資料的查詢,如:商品列表,商品資訊,使用者資訊,紅包資訊等,這些資料都是不會經常變化,並且持久化在資料庫中

高併發的情況下直接連線從庫做查詢操作,多台從庫伺服器也抗不住這麼大量的連線請求數(前面說過,單台資料庫伺服器允許的最大連線數量是有限的)

那麼我們在這種高併發的業務介面要如何設計呢?

方案設計:

補充:使用服務化思維,將核心業務或者通用的業務功能抽離成服務獨立部署,對外提供介面的方式提供功能。

最理想化的設計是可以把乙個複雜的系統抽離成多個服務,共同組成系統的業務,優點:松耦合,高可用性,高伸縮性,易維護。

通過面向服務化設計,獨立伺服器部署,均衡負載,資料庫集群,可以讓服務支撐更高的併發

說明:背景:

架構:業務設計:

介面:上線跟進:

當高併發業務所在的伺服器出現宕機的時候,需要有備用伺服器進行快速的替代,在應用伺服器壓力大的時候可以快速新增機器到集群中,所以我們就需要有備用機器可以隨時待命。 最理想的方式是可以通過自動化監控伺服器資源消耗來進行報警,自動切換降級方案,自動的進行伺服器替換和新增操作等,通過自動化可以減少人工的操作的成本,而且可以快速操作,避免人為操作上面的失誤。

自動化通過gitlab事件,我們應該反思,做了備份資料並不代表就萬無一失了,我們需要保證高可用性,首先備份是否正常進行,備份資料是否可用,需要我們進行定期的檢查,或者自動化監控, 還有包括如何避免人為上的操作失誤問題。(不過事件中gitlab的開放性姿態,積極的處理方式還是值得學習的)

高併發架構是乙個不斷衍變的過程,冰洞三尺非一日之寒,長城築成非一日之功 。

打好基礎架構方便以後的拓展,這點很重要。

架構師之路 究竟啥是高併發

一 高併發常用的指標 例如系統處理乙個http請求需要300ms,這個300ms就是系統的響應時間。2 吞吐量 例如在1秒內處理的請求數量 3 qps 每秒的響應請求數 4 併發使用者數 同時承載正常使用系統功能的使用者數量 二 如何提公升系統的併發能力 1 垂直擴充套件 a 增強單機硬體效能 增加...

架構師之路 架構師思維的培養

公司的cms 綜合賦碼管理系統 是winform的cs架構。這套系統的架構師換了3屆,到現在已經幾年沒有架構師了。本來入職時,崗位目標就是這個 自動化架構師 後來和領導達成共識先爭取成為儲備架構師,因為架構首先是為業務服務的,而工控行業有許多特別的地方,不是普通的軟體技術堆疊就能做出優秀的工控軟體的...

架構師之路 架構師思維的培養

公司的cms 綜合賦碼管理系統 是winform的cs架構。這套系統的架構師換了3屆,到現在已經幾年沒有架構師了。本來入職時,崗位目標就是這個 自動化架構師 後來和領導達成共識先爭取成為儲備架構師,因為架構首先是為業務服務的,而工控行業有許多特別的地方,不是普通的軟體技術堆疊就能做出優秀的工控軟體的...