電商那些年，我摸爬打滾出的高併發架構實戰精髓

 

1、關於高併發

高併發是指在同一個時間點，有不少用戶同時訪問URL地址，好比：淘寶的雙十一、雙12，就會產生高併發。又如貼吧的爆吧，就是惡意的高併發請求，也就是DDOS攻擊，再屌絲點的說法就像玩LOL被ADC暴擊了同樣，那傷害你懂的。

來源：SFLYQ的博客

原文：http://blog.thankbabe.com/2016/09/14/high-concurrency-scheme/

一、高併發會來帶的後果

• 服務端：致使站點服務器/DB服務器資源被佔滿崩潰，數據的存儲和更新結果和理想的設計是不同的，好比：出現重複的數據記錄，屢次添加了用戶積分等。
• 用戶角度：尼瑪，這麼卡，老子來參加活動的，刷新了仍是這樣，垃圾網站，不再來了！
• 個人經歷：在作公司產品網站的過程當中，常常會有這樣的需求，好比搞個活動專題、抽獎、簽到、積分競拍等等，若是沒有考慮到高併發下的數據處理，那就Game Over了，很容易致使抽獎被多抽走，簽到發現一個用戶有多條記錄等等，各類超出正常邏輯的現象，這就是作產品網站必須考慮的問題，由於這些都是面向大量用戶的，而不是像作ERP管理系統、OA系統那樣，只是面向員工。

下面我進行實例分析，簡單粗暴，動態分析，純屬本人經驗分享，若有說錯或者更好的建議，請留言，你們一塊兒成長。

二、併發下的數據處理

經過表設計，如：記錄表添加惟一約束，數據處理邏輯使用事物防止併發下的數據錯亂問題。經過服務端鎖進程防止包併發下的數據錯亂問題。這裏主要講述的是在併發請求下的數據邏輯處理的接口，如何保證數據的一致性和完整性，這裏的併發多是大量用戶發起的，也可能攻擊者經過併發工具發起的併發請求。

例子1：經過表設計防止併發致使數據錯亂

• 需求點： 

  【簽到功能】一天一個用戶只能簽到一次，簽到成功後用戶獲取到一個積分。

• 已知表：

  一、用戶表，包含積分字段；

  二、高併發意淫分析(屬於開發前的猜想)： 在高併發的狀況下，會致使一個用戶簽到記錄會有多條，或者用戶簽到後不止加一積分。

• 個人設計：首先根據需求我會添加一張簽到記錄表，重點來了，這張表須要把用戶惟一標識字段(ID,Token)和簽到日期字段添加爲惟一約束，或者惟一索引，這樣就能夠防止併發的時候插入重複用戶的簽到記錄。而後再程序代碼邏輯裏，先執行簽到數據的添加(這裏能夠防止併發，添加成功後再進行積分的添加，這樣就能夠防止重複地添加積分了。最後我仍是建議全部的數據操做都寫在一個sql事務裏面， 這樣在添加失敗，或者編輯用戶積分失敗的時候能夠回滾數據。

例子2：事務+經過更新鎖，防止併發致使數據錯亂；或者事物+Update的鎖表機制

• 需求點：【抽獎功能】抽獎一次消耗一個積分，抽獎中獎後編輯剩餘獎品總數，剩餘獎品總數爲0，或者用戶積分爲0的時候沒法進行抽獎。
• 已知表：用戶表，包含積分字段 獎品表，包含獎品剩餘數量字段。
• 高併發意淫分析(屬於開發前的猜想)：在高併發的狀況下，會致使用戶參與抽獎的時候積分被扣除，而獎品實際上已經被抽完了。
• 個人設計：在事物裏，經過WITH(UPDLOCK)鎖住商品表，或者Update 表的獎品剩餘數量和最後編輯時間字段，來把數據行鎖住，而後進行用戶積分的消耗，都完成後提交事物，失敗就回滾。 這樣就能夠保證，只有可能存在一個操做在操做這件商品的數量，只有等到這個操做事物提交後，其餘的操做這個商品行的事物纔會繼續執行。

例子3：經過程序代碼防止包併發下的數據錯亂問題

• 需求點：【緩存數據到cache裏】，當緩存不存在的時候，從數據庫中獲取並保存在cache裏，若是存在從cache裏獲取，天天10點必須更新一次，其餘時間點緩存兩個小時更新一次 到10點的時候，凡是打開頁面的用戶會自動刷新頁面。
• 問題點：這裏有個邏輯用戶觸發緩存的更新，用戶刷新頁面，當緩存存在的時候，會取到最後一次緩存更新時間，若是當前時間大於十點，而且最後緩存時間是10點前，則會從數據庫中從新獲取數據保存到cache中。 還有客戶端頁面會在10點時候用js發起頁面的刷新，就是由於有這樣的邏輯，致使10點的時候有不少併發請求同時過來，而後就會致使不少的sql查詢操做，理想的邏輯是，只有一個請求會去數據庫獲取，其餘都是從緩存中獲取數據。(由於這個sql查詢很耗服務器性能，因此致使在10點的時候，忽然間數據庫服務器壓力暴增)
• 解決問題：C#經過（鎖）lock，在從數據讀取到緩存的那段代碼前面加上鎖，這樣在併發的狀況下只會有一個請求是從數據庫裏獲取數據，其餘都是從緩存中獲取。

三、訪問量大的數據統計接口

• 需求： 用戶行爲數據統計接口，用來記錄商品展現次數，用戶經過點擊圖片，或者連接，或者其餘方式進入到商品詳情的行爲次數。
• 問題點：這接口是給前端ajax使用，訪問量會很大，一頁面展現的時候就會有幾十件商品的展現，滾動條滾到到頁面顯示商品的時候就會請求接口進行展現數據的統計，每次翻頁又會加載幾十件。
• 意淫分析：設想若是同時有1W個用戶同時在線訪問頁面，一個次拉動滾動條屏幕頁面展現10件商品，這樣就會有10W個請求過來，服務端須要把請求數據入庫。在實際線上環境可能還會超過這個請求量，若是不通過進行高併發設計處理，服務器分分鐘給跪了。
• 解決問題：咱們經過nodejs寫了一個數據處理接口，把統計數據先存到redis的list裏。(使用nodejs寫接口的好處是，nodejs使用單線程異步事件機制，高併發處理能力強，不會由於數據邏輯處理問題致使服務器資源被佔用而致使服務器宕機) 而後再使用nodejs寫了一個腳本，腳本功能就是從redis裏出列數據保存到mysql數據庫中。這個腳本會一直運行，當redis沒有數據須要同步到數據庫中的時候，sleep，讓在進行數據同步操做。

四、高併發的下的服務器壓力均衡，合理站點架設，DB部署

如下我所知道的：

1. 服務器代理nginx，作服務器的均衡負載，把壓力均衡到多臺服務器；
2. 部署集羣MySQL數據庫， Redis服務器，或者MongoDB服務器，把一些經常使用的查詢數據，而且不會常常的變化的數據保存到其餘NoSQL DB服務器中，來減小數據庫服務器的壓力，加快數據的響應速度；
3. 數據緩存，Cache；
4. 在高併發接口的設計中可使用具備高併發能力的編程語言去開發，如：nodejs作web接口；
5. 服務器部署，圖片服務器分離，靜態文件走CDN；
6. DBA數據庫的優化查詢條件，索引優化；
7. 消息存儲機制，將數據添加到信息隊列中(redis list)，而後再寫工具去入庫
8. 腳本合理控制請求，如，防止用戶重複點擊致使的ajax多餘的請求，等等。

五、併發測試神器推薦

1. Apache JMeter
2. Microsoft Web Application Stress Tool
3. Visual Studio 性能負載

2、關於高併發架構

爲了讓業務能夠流暢地運行而且給用戶一個好的交互體驗，咱們須要根據業務場景預估達到的併發量等因素，來設計適合本身業務場景的高併發處理方案。

在電商相關產品開發的這些年，我有幸遇到了併發下的各類坑，這一路摸爬滾打過來有着很多的血淚史，這裏進行總結，做爲本身的歸檔記錄，同時分享給你們。

一、服務器架構

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

一個能夠支持高併發的服務少不了好的服務器架構，須要有均衡負載，數據庫須要主從集羣，NoSQL緩存須要主從集羣，靜態文件須要上傳CDN，這些都是能讓業務程序流暢運行的強大後盾。

服務器這塊可能是須要運維人員來配合搭建，具體我就很少說了，點到爲止。

大體須要用到的服務器架構以下：

服務器：

• 均衡負載(如：nginx，阿里雲SLB)
• 資源監控
• 分佈式

數據庫：

• 主從分離，集羣
• DBA 表優化，索引優化，等
• 分佈式

NoSQL：

• Redis

  主從分離，集羣

• MongoDB

  主從分離，集羣

• memcache

  主從分離，集羣

CDN：

• html
• css
• js
• image

二、併發測試

高併發相關的業務，須要進行併發的測試，經過大量的數據分析評估出整個架構能夠支撐的併發量。

測試高併發可使用第三方服務器或者本身測試服務器，利用測試工具進行併發請求測試，分析測試數據獲得能夠支撐併發數量的評估，這個能夠做爲一個預警參考，俗話說知己自彼百戰不殆。

第三方服務:

• 阿里雲性能測試

併發測試工具：

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

三、實戰方案

1）通用方案

日用戶流量大，可是比較分散，偶爾會有用戶高聚的狀況；

場景： 用戶簽到，用戶中心，用戶訂單等。

服務器架構圖： 

說明：

場景中的這些業務基本是用戶進入APP後會操做到的，除了活動日(61八、雙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查詢的鎖住操做。

以上例子是一個相對簡單的高併發架構，併發量不是很高的狀況能夠很好的支撐，可是隨着業務的壯大，用戶併發量增長，咱們的架構也會進行不斷的優化和演變，好比對業務進行服務化，每一個服務有本身的併發架構，本身的均衡服務器，分佈式數據庫，NoSQL主從集羣，如：用戶服務、訂單服務。

2）消息隊列

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

場景：定時領取紅包等。

服務器架構圖：

說明：

• 場景中的定時領取是一個高併發的業務，像秒殺活動用戶會在到點的時間涌入，DB瞬間就接受到一記暴擊，hold不住就會宕機，而後影響整個業務；
• 像這種不是隻有查詢的操做而且會有高併發的插入或者更新數據的業務，前面提到的通用方案就沒法支撐，併發的時候都是直接命中DB；
• 設計這塊業務的時候就會使用消息隊列的，能夠將參與用戶的信息添加到消息隊列中，而後再寫個多線程程序去消耗隊列，給隊列中的用戶發放紅包；

方案如：

• 定時領取紅包；
• 通常習慣使用 redis的 list；
• 當用戶參與活動，將用戶參與信息push到隊列中；
• 而後寫個多線程程序去pop數據，進行發放紅包的業務；
• 這樣能夠支持高併發下的用戶能夠正常的參與活動，而且避免數據庫服務器宕機的危險。

附加： 經過消息隊列能夠作不少的服務。
如：定時短信發送服務，使用sset(sorted set)，發送時間戳做爲排序依據，短信數據隊列根據時間升序，而後寫個程序定時循環去讀取sset隊列中的第一條，當前時間是否超過發送時間，若是超過就進行短信發送。

3）一級緩存

高併發請求鏈接緩存服務器超出服務器可以接收的請求鏈接量，部分用戶出現創建鏈接超時沒法讀取到數據的問題；

所以須要有個方案當高併發時候時候能夠減小命中緩存服務器；

這時候就出現了一級緩存的方案，一級緩存就是使用站點服務器緩存去存儲數據，注意只存儲部分請求量大的數據，而且緩存的數據量要控制，不能過度的使用站點服務器的內存而影響了站點應用程序的正常運行，一級緩存須要設置秒單位的過時時間，具體時間根據業務場景設定，目的是當有高併發請求的時候可讓數據的獲取命中到一級緩存，而不用鏈接緩存NoSQL數據服務器，減小NoSQL數據服務器的壓力。

好比APP首屏商品數據接口，這些數據是公共的不會針對用戶自定義，並且這些數據不會頻繁的更新，像這種接口的請求量比較大就能夠加入一級緩存；

服務器架構圖：

合理地規範和使用NoSQL緩存數據庫，根據業務拆分緩存數據庫的集羣，這樣基本能夠很好支持業務，一級緩存畢竟是使用站點服務器緩存因此仍是要善用。

4）靜態化數據

高併發請求數據不變化的狀況下若是能夠不請求本身的服務器獲取數據那就能夠減小服務器的資源壓力。

對於更新頻繁度不高，而且數據容許短期內的延遲，能夠經過數據靜態化成JSON、XML、HTML等數據文件上傳CDN，在拉取數據的時候優先到CDN拉取，若是沒有獲取到數據再從緩存，數據庫中獲取，當管理人員操做後臺編輯數據再從新生成靜態文件上傳同步到CDN，這樣在高併發的時候可使數據的獲取命中在CDN服務器上。

CDN節點同步有必定的延遲性，因此找一個靠譜的CDN服務器商也很重要。

5）其餘方案

對於更新頻繁度不高的數據，APP、PC瀏覽器，能夠緩存數據到本地，而後每次請求接口的時候上傳當前緩存數據的版本號，服務端接收到版本號判斷版本號與最新數據版本號是否一致，若是不同就進行最新數據的查詢並返回最新數據和最新版本號，若是同樣就返回狀態碼告知數據已是最新。減小服務器壓力：資源、帶寬。