歡迎光臨
每天分享高質量文章

架構師眼中的高併發架構

前言

 

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

 

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

 

在電商相關產品開發的這些年,我有幸的遇到了併發下的各種坑,這一路摸爬滾打過來有著不少的血淚史,這裡進行的總結,作為自己的歸檔記錄,同時分享給大家。

 

服務器架構

 

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

 

一個可以支持高併發的服務少不了好的服務器架構,需要有均衡負載,資料庫需要主從集群,NoSQL快取需要主從集群,靜態檔案需要上傳CDN,這些都是能讓業務程式流暢運行的強大後盾,且服務器需要運維人員來配合搭建。

 

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

 

  • 服務器
    • 均衡負載(如:nginx,阿裡雲SLB
    • 資源監控
    • 分佈式
  • 資料庫
    • 主從分離、集群
    • DBA表優化、索引優化等
    • 分佈式
  • NoSQL
    • 主從分離、集群
    • 主從分離、集群
    • 主從分離、集群
    • Redis
    • MongoDB
    • MemCache
  • CDN
    • HTML
    • CSS
    • JS
    • image

 

併發測試

 

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

 

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

 

第三方服務:

 

  • 阿裡雲性能測試

 

併發測試工具:

 

  • Apache JMeter
  • Visual Studio性能負載測試
  • Microsoft Web Application Stress Tool

 

實戰方案

 

適用於:日用戶流量大,但是比較分散,偶爾會有用戶高聚的情況;

 

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

 

服務架構圖

說明:

 

場景中的這些業務基本是用戶進入APP後會操作到的,除了活動日(618、雙11等),這些業務的用戶量都不會高聚集,同時這些業務相關的表都是大資料表,業務多是查詢操作,所以我們需要減少用戶直接命中DB的查詢;優先查詢快取,如果快取不存在,再進行DB查詢,將查詢結果快取起來。

 

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

 

方案如:

 

    • 用戶簽到獲取積分
      • 計算出用戶分佈的key,redis hash中查找用戶今日簽到信息
      • 如果查詢到簽到信息,傳回簽到信息
      • 如果沒有查詢到,DB查詢今日是否簽到過,如果有簽到過,就把簽到信息同步Redis快取。
      • 如果DB中也沒有查詢到今日的簽到記錄,就進行簽到邏輯,操作DB添加今日簽到記錄,添加簽到積分(這整個DB操作是一個事務)
      • 快取簽到信息到redis,傳回簽到信息
      • 註意這裡會有併發情況下的邏輯問題,如:一天簽到多次,發放多次積分給用戶。

 

    • 用戶訂單
      • 這裡我們只快取用戶第一頁的訂單信息,一頁40條資料,用戶一般也只會看第一頁的訂單資料
      • 用戶訪問訂單串列,如果是第一頁讀快取,如果不是讀DB
      • 計算出用戶分佈的key,redis hash中查找用戶訂單信息
      • 如果查詢到用戶訂單信息,傳回訂單信息
      • 如果不存在就進行DB查詢第一頁的訂單資料,然後快取redis,傳回訂單信息

 

    • 用戶中心
      • 計算出用戶分佈的key,redis hash中查找用戶訂單信息
      • 如果查詢到用戶信息,傳回用戶信息
      • 如果不存在進行用戶DB查詢,然後快取redis,傳回用戶信息

 

  • 其他業務
    • 上面例子多是針對用戶儲存快取,如果是公用的快取資料需要註意一些問題,如下
    • 註意公用的快取資料需要考慮併發下的可能會導致大量命中DB查詢,可以使用管理後臺更新快取,或者DB查詢的鎖住操作。
    • 我的博文《大話Redis進階》(http://blog.thankbabe.com/2016/08/05/redis-up/)對更新快取問題和推薦方案的分享。

 

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

 

訊息佇列

 

適用活動:秒殺、秒搶等活動業務,用戶在瞬間涌入產生高併發請求。

 

場景:定時領取紅包等

服務器架構圖

說明:

 

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

 

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

 

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

 

方案如:

 

  • 定時領取紅包
    • 一般習慣使用 redis的 list
    • 當用戶參與活動,將用戶參與信息push到佇列中
    • 然後寫個多執行緒程式去pop資料,進行發放紅包的業務
    • 這樣可以支持高併發下的用戶可以正常的參與活動,並且避免資料庫服務器宕機的危險

 

附加: 

 

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

 

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

 

一級快取

 

高併發請求連接快取服務器超出服務器能夠接收的請求連接量,部分用戶出現建立連接超時無法讀取到資料的問題。因此需要有個方案當高併發時候時候可以減少命中快取服務器。

 

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

 

比如APP首屏商品資料接口,這些資料是公共的不會針對用戶自定義,而且這些資料不會頻繁的更新,像這種接口的請求量比較大就可以加入一級快取。

 

服務器架構圖

 

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

 

靜態化資料

 

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

 

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

 

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

 

其他方案

 

  • 對於更新頻繁度不高的資料,APP、PC瀏覽器可以快取資料到本地,然後每次請求接口的時候上傳當前快取資料的版本號,服務端接收到版本號判斷版本號與最新資料版本號是否一致,如果不一樣就進行最新資料的查詢並傳回最新資料和最新版本號,如果一樣就傳回狀態碼告知資料已經是最新。減少服務器壓力:資源、帶寬。

 

針對上面的技術我特意整理了一下,有很多技術不是靠幾句話能講清楚,所以乾脆找朋友錄製了一些視頻,很多問題其實答案很簡單,但是背後的思考和邏輯不簡單,要做到知其然還要知其所以然。如果想學習Java工程化、高性能及分佈式、深入淺出。

 

分層,分割,分佈式

 

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

 

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

 

    • 分層
      • 將系統在橫向維度上切分成幾個部分,每個部門負責一部分相對簡單並比較單一的職責,然後通過上層對下層的依賴和調度組成一個完整的系統
      • 比如把電商系統分成:應用層、服務層、資料層。(具體分多少個層次根據自己的業務場景)
      • 應用層:網站首頁、用戶中心、商品中心、購物車、紅包業務、活動中心等,負責具體業務和視圖展示
      • 服務層:訂單服務、用戶管理服務、紅包服務、商品服務等,為應用層提供服務支持
      • 資料層:關係資料庫、NoSQL資料庫等,提供資料儲存查詢服務
      • 分層架構是邏輯上的,在物理部署上可以部署在同一臺物理機器上,但是隨著網站業務的發展,必然需要對已經分層的模塊分離部署,分別部署在不同的服務器上,使網站可以支撐更多用戶訪問

 

    • 分割
      • 在縱向方面對業務進行切分,將一塊相對複雜的業務分割成不同的模塊單元
      • 包裝成高內聚低耦合的模塊不僅有助於軟體的開發維護,也便於不同模塊的分佈式部署,提高網站的併發處理能力和功能擴展
      • 比如用戶中心可以分割成:賬戶信息模塊、訂單模塊、充值模塊、提現模塊、優惠券模塊等

 

  • 分佈式
    • 分佈式應用和服務,將分層或者分割後的業務分佈式部署,獨立的應用服務器、資料庫、快取服務器
    • 當業務達到一定用戶量的時候,再進行服務器均衡負載、資料庫、快取主從集群
    • 分佈式靜態資源,比如:靜態資源上傳CDN
    • 分佈式計算,比如:使用hadoop進行大資料的分佈式計算
    • 分佈式資料和儲存,比如:各分佈節點根據哈希演算法或其他演算法分散儲存資料

 

網站分層,圖片來自網絡

 

集群

 

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

 

  • 應用服務器集群
    • nginx反向代理
    • slb
    • … …
  • (關係/NoSQL)資料庫集群
    • 主從分離,從庫集群

 

反向代理均衡負載,圖片自網絡

 

異步

 

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

 

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

 

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

 

  • 如:
    • 自動彈窗簽到,雙11跨0點的時候併發請求簽到接口
    • 雙11搶紅包活動
    • 雙11訂單入庫等

 

 

    • 設計考慮:
      • 逆向思維,壓力在資料庫,那業務接口就不進行資料庫操作不就沒壓力了
      • 資料持久化是否允許延遲?
      • 如何讓業務接口不直接操作DB,又可以讓資料持久化?

 

    • 方案設計:
      • 像這種涉及資料庫操作的高併發的業務,就要考慮使用異步了
      • 客戶端發起接口請求,服務端快速響應,客戶端展示結果給用戶,資料庫操作通過異步同步
      • 如何實現異步同步?
      • 使用訊息佇列,將入庫的內容enqueue到訊息佇列中,業務接口快速響應給用戶結果(可以溫馨提示高峰期延遲到賬)
      • 然後再寫個獨立程式從訊息佇列dequeue資料出來進行入庫操作,入庫成功後掃清用戶相關快取,如果入庫失敗記錄日誌,方便反饋查詢和重新持久化
      • 這樣一來資料庫操作就只有一個程式(多執行緒)來完成,不會給資料帶來壓力

 

  • 補充:
    • 訊息佇列除了可以用在高併發業務,其他只要有相同需求的業務也是可以使用,如:短信發送中間件等
    • 高併發下異步持久化資料可能會影響用戶的體驗,可以通過可配置的方式,或者自動化監控資源消耗來切換時時或者使用異步,這樣在正常流量的情況下可以使用時時運算元據庫來提高用戶體驗
    • 異步同時也可以指編程上的異步函式,異步執行緒,在有的時候可以使用異步操作,把不需要等待結果的操作放到異步中,然後繼續後面的操作,節省了等待的這部分操作的時間

 

快取

 

高併發業務接口多數都是進行業務資料的查詢,如:商品串列、商品信息、用戶信息、紅包信息等,這些資料都是不會經常變化,並且持久化在資料庫中

 

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

 

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

 

    • 設計考慮:
      • 還是逆向思維,壓力在資料庫,那麼我們就不進行資料庫查詢
      • 資料不經常變化,我們為啥要一直查詢DB?
      • 資料不變化客戶端為啥要向服務器請求傳回一樣的資料?

 

    • 方案設計:
      • 資料不經常變化,我們可以把資料進行快取,快取的方式有很多種,一般的:應用服務器直接Cache記憶體,主流的:儲存在MemCache、Redis記憶體資料庫
      • Cache是直接儲存在應用服務器中,讀取速度快,記憶體資料庫服務器允許連接數可以支撐到很大,而且資料儲存在記憶體,讀取速度快,再加上主從集群,可以支撐很大的併發查詢
      • 根據業務情景,使用配合客戶端本地存,如果我們資料內容不經常變化,為啥要一直請求服務器獲取相同資料,可以通過匹配資料版本號,如果版本號不一樣接口重新查詢快取傳回資料和版本號,如果一樣則不查詢資料直接響應
      • 這樣不僅可以提高接口響應速度,也可以節約服務器帶寬,雖然有些服務器帶寬是按流量計費,但是也不是絕對無限的,在高併發的時候服務器帶寬也可能導致請求響應慢的問題

 

  • 補充:
    • 快取同時也指靜態資源客戶端快取
    • CDN快取,靜態資源通過上傳cdn,CDN節點快取我們的靜態資源,減少服務器壓力

 

面向服務

 

  • SOA面向服務架構設計
  • 微服務更細粒度服務化,一系列的獨立的服務共同組成系統

 

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

 

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

 

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

 

    • 服務例子:
      • 用戶行為跟蹤記錄統計

 

    • 說明:
      • 通過上報應用模塊,操作事件,事件物件,等資料,記錄用戶的操作行為
      • 比如:記錄用戶在某個商品模塊,點擊了某一件商品,或者瀏覽了某一件商品

 

    • 背景:
      • 由於服務需要記錄用戶的各種操作行為,並且可以重覆上報,準備接入服務的業務又是核心業務的用戶行為跟蹤,所以請求量很大,高峰期會產生大量併發請求。

         

    • 架構:
      • nodejs WEB應用服務器均衡負載
      • Redis主從集群
      • MySQL主
      • nodejs+express+ejs+redis+mysql
      • 服務端採用nodejs,nodejs是單行程(PM2根據cpu核數開啟多個工作行程),採用事件驅動機制,適合I/O密集型業務,處理高併發能力強

         

    • 業務設計:
      • 併發量大,所以不能直接入庫,採用:異步同步資料,訊息佇列
      • 請求接口上報資料,接口將上報資料push到Redis的list佇列中
      • nodejs寫入庫腳本,迴圈pop redis list資料,將資料儲存入庫,併進行相關統計Update,無資料時sleep幾秒
      • 因為資料量會比較大,上報的資料表按天命名儲存

         

    • 接口:
      • 上報資料接口
      • 統計查詢接口

 

  • 上線跟進:
    • 服務業務基本正常
    • 每天的上報表有上千萬的資料

 

冗餘,自動化

 

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

 

  • 冗餘
    • 資料庫備份
    • 備用服務器
  • 自動化
    • 自動化監控
    • 自動化報警
    • 自動化降級

 

通過GitLab事件,我們應該反思,做了備份資料並不代表就萬無一失了,我們需要保證高可用性,首先備份是否正常進行,備份資料是否可用,需要我們進行定期的檢查,或者自動化監控, 還有包括如何避免人為上的操作失誤問題。

 

總結

 

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

 

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

 

 

來源:http://blog.thankbabe.com/

    赞(0)

    分享創造快樂