[分散式][高併發]高併發架構

前言

 

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

 

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

 

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

 

伺服器架構

 

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

 

一個可以支援高併發的服務少不了好的伺服器架構，需要有均衡負載，資料庫需要主從叢集，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，返回簽到資訊

  • 注意這裡會有併發情況下的邏輯問題，如：一天簽到多次，發放多次積分給使用者。

  • 我的博文《大話程式猿眼裡的高併發》（http://blog.thankbabe.com/2016/04/01/high-concurrency/）有相關的處理方案。

• 使用者訂單

  • 這裡我們只快取使用者第一頁的訂單資訊，一頁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瀏覽器，可以快取資料到本地，然後每次請求介面的時候上傳當前快取資料的版本號，服務端接收到版本號判斷版本號與最新資料版本號是否一致，如果不一樣就進行最新資料的查詢並返回最新資料和最新版本號，如果一樣就返回狀態碼告知資料已經是最新。減少伺服器壓力：資源、頻寬等.

 

 

分層，分割，分散式

 

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

 

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

 

 

 

• 分層

  • 將系統在橫向維度上切分成幾個部分，每個部門負責一部分相對簡單並比較單一的職責，然後通過上層對下層的依賴和排程組成一個完整的系統

  • 比如把電商系統分成：應用層，服務層，資料層。(具體分多少個層次根據自己的業務場景)

  • 應用層：網站首頁，使用者中心，商品中心，購物車，紅包業務，活動中心等，負責具體業務和檢視展示

  • 服務層：訂單服務，使用者管理服務，紅包服務，商品服務等，為應用層提供服務支援

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

 

總結

 

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