一、關(guān)于高并發(fā)

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

?

1 高并發(fā)會來帶的后果

• 服務(wù)端：導(dǎo)致站點服務(wù)器/DB服務(wù)器資源被占滿崩潰，數(shù)據(jù)的存儲和更新結(jié)果和理想的設(shè)計是不一樣的，比如：出現(xiàn)重復(fù)的數(shù)據(jù)記錄，多次添加了用戶積分等。

• 用戶角度：尼瑪，這么卡，老子來參加活動的，刷新了還是這樣，垃圾網(wǎng)站，再也不來了！

• 我的經(jīng)歷：在做公司產(chǎn)品網(wǎng)站的過程中，經(jīng)常會有這樣的需求，比如搞個活動專題、抽獎、簽到、積分競拍等等，如果沒有考慮到高并發(fā)下的數(shù)據(jù)處理，那就Game Over了，很容易導(dǎo)致抽獎被多抽走，簽到發(fā)現(xiàn)一個用戶有多條記錄等等，各種超出正常邏輯的現(xiàn)象，這就是做產(chǎn)品網(wǎng)站必須考慮的問題，因為這些都是面向大量用戶的，而不是像做ERP管理系統(tǒng)、OA系統(tǒng)那樣，只是面向員工。

下面我進行實例分析，簡單粗暴，動態(tài)分析，純屬本人經(jīng)驗分享，如有說錯或者更好的建議，請留言，大家一起成長。

?

2 并發(fā)下的數(shù)據(jù)處理

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

?

例子1：通過表設(shè)計防止并發(fā)導(dǎo)致數(shù)據(jù)錯亂

• 需求點：?

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

• 已知表：

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

  2、高并發(fā)意淫分析(屬于開發(fā)前的猜測)：?在高并發(fā)的情況下，會導(dǎo)致一個用戶簽到記錄會有多條，或者用戶簽到后不止加一積分。

• 我的設(shè)計：首先根據(jù)需求我會添加一張簽到記錄表，重點來了，這張表需要把用戶唯一標(biāo)識字段(ID,Token)和簽到日期字段添加為唯一約束，或者唯一索引，這樣就可以防止并發(fā)的時候插入重復(fù)用戶的簽到記錄。然后再程序代碼邏輯里，先執(zhí)行簽到數(shù)據(jù)的添加(這里可以防止并發(fā)，添加成功后再進行積分的添加，這樣就可以防止重復(fù)地添加積分了。最后我還是建議所有的數(shù)據(jù)操作都寫在一個sql事務(wù)里面， 這樣在添加失敗，或者編輯用戶積分失敗的時候可以回滾數(shù)據(jù)。

?

例子2：事務(wù)+通過更新鎖，防止并發(fā)導(dǎo)致數(shù)據(jù)錯亂；或者事物+Update的鎖表機制

• 需求點：【抽獎功能】抽獎一次消耗一個積分，抽獎中獎后編輯剩余獎品總數(shù)，剩余獎品總數(shù)為0，或者用戶積分為0的時候無法進行抽獎。

• 已知表：用戶表，包含積分字段 獎品表，包含獎品剩余數(shù)量字段。

• 高并發(fā)意淫分析(屬于開發(fā)前的猜測)：在高并發(fā)的情況下，會導(dǎo)致用戶參與抽獎的時候積分被扣除，而獎品實際上已經(jīng)被抽完了。

• 我的設(shè)計：在事物里，通過WITH(UPDLOCK)鎖住商品表，或者Update 表的獎品剩余數(shù)量和最后編輯時間字段，來把數(shù)據(jù)行鎖住，然后進行用戶積分的消耗，都完成后提交事物，失敗就回滾。 這樣就可以保證，只有可能存在一個操作在操作這件商品的數(shù)量，只有等到這個操作事物提交后，其他的操作這個商品行的事物才會繼續(xù)執(zhí)行。

?

例子3：通過程序代碼防止包并發(fā)下的數(shù)據(jù)錯亂問題

• 需求點：【緩存數(shù)據(jù)到cache里】，當(dāng)緩存不存在的時候，從數(shù)據(jù)庫中獲取并保存在cache里，如果存在從cache里獲取，每天10點必須更新一次，其他時間點緩存兩個小時更新一次 到10點的時候，凡是打開頁面的用戶會自動刷新頁面。

• 問題點：這里有個邏輯用戶觸發(fā)緩存的更新，用戶刷新頁面，當(dāng)緩存存在的時候，會取到最后一次緩存更新時間，如果當(dāng)前時間大于十點，并且最后緩存時間是10點前，則會從數(shù)據(jù)庫中重新獲取數(shù)據(jù)保存到cache中。 還有客戶端頁面會在10點時候用js發(fā)起頁面的刷新，就是因為有這樣的邏輯，導(dǎo)致10點的時候有很多并發(fā)請求同時過來，然后就會導(dǎo)致很多的sql查詢操作，理想的邏輯是，只有一個請求會去數(shù)據(jù)庫獲取，其他都是從緩存中獲取數(shù)據(jù)。(因為這個sql查詢很耗服務(wù)器性能，所以導(dǎo)致在10點的時候，突然間數(shù)據(jù)庫服務(wù)器壓力暴增)

• 解決問題：C#通過（鎖）lock，在從數(shù)據(jù)讀取到緩存的那段代碼前面加上鎖，這樣在并發(fā)的情況下只會有一個請求是從數(shù)據(jù)庫里獲取數(shù)據(jù)，其他都是從緩存中獲取。

?

3 訪問量大的數(shù)據(jù)統(tǒng)計接口

• 需求：?用戶行為數(shù)據(jù)統(tǒng)計接口，用來記錄商品展示次數(shù)，用戶通過點擊圖片，或者鏈接，或者其他方式進入到商品詳情的行為次數(shù)。

• 問題點：這接口是給前端ajax使用，訪問量會很大，一頁面展示的時候就會有幾十件商品的展示，滾動條滾到到頁面顯示商品的時候就會請求接口進行展示數(shù)據(jù)的統(tǒng)計，每次翻頁又會加載幾十件。

• 意淫分析：設(shè)想如果同時有1W個用戶同時在線訪問頁面，一個次拉動滾動條屏幕頁面展示10件商品，這樣就會有10W個請求過來，服務(wù)端需要把請求數(shù)據(jù)入庫。在實際線上環(huán)境可能還會超過這個請求量，如果不經(jīng)過進行高并發(fā)設(shè)計處理，服務(wù)器分分鐘給跪了。

• 解決問題：我們通過nodejs寫了一個數(shù)據(jù)處理接口，把統(tǒng)計數(shù)據(jù)先存到redis的list里。(使用nodejs寫接口的好處是，nodejs使用單線程異步事件機制，高并發(fā)處理能力強，不會因為數(shù)據(jù)邏輯處理問題導(dǎo)致服務(wù)器資源被占用而導(dǎo)致服務(wù)器宕機) 然后再使用nodejs寫了一個腳本，腳本功能就是從redis里出列數(shù)據(jù)保存到mysql數(shù)據(jù)庫中。這個腳本會一直運行，當(dāng)redis沒有數(shù)據(jù)需要同步到數(shù)據(jù)庫中的時候，sleep，讓在進行數(shù)據(jù)同步操作。

?

4 高并發(fā)的下的服務(wù)器壓力均衡，合理站點架設(shè)，DB部署

以下我所知道的：

服務(wù)器代理nginx，做服務(wù)器的均衡負載，把壓力均衡到多臺服務(wù)器；

部署集群MySQL數(shù)據(jù)庫， Redis服務(wù)器，或者MongoDB服務(wù)器，把一些常用的查詢數(shù)據(jù)，并且不會經(jīng)常的變化的數(shù)據(jù)保存到其他NoSQL DB服務(wù)器中，來減少數(shù)據(jù)庫服務(wù)器的壓力，加快數(shù)據(jù)的響應(yīng)速度；

數(shù)據(jù)緩存，Cache；

在高并發(fā)接口的設(shè)計中可以使用具有高并發(fā)能力的編程語言去開發(fā)，如：nodejs做web接口；

服務(wù)器部署，圖片服務(wù)器分離，靜態(tài)文件走CDN；

DBA數(shù)據(jù)庫的優(yōu)化查詢條件，索引優(yōu)化；

消息存儲機制，將數(shù)據(jù)添加到信息隊列中(redis list)，然后再寫工具去入庫

腳本合理控制請求，如，防止用戶重復(fù)點擊導(dǎo)致的ajax多余的請求，等等。

?

5 并發(fā)測試神器推薦

Apache JMeter

Microsoft Web Application Stress Tool

Visual Studio 性能負載

?

二、關(guān)于高并發(fā)架構(gòu)

為了讓業(yè)務(wù)可以流暢地運行并且給用戶一個好的交互體驗，我們需要根據(jù)業(yè)務(wù)場景預(yù)估達到的并發(fā)量等因素，來設(shè)計適合自己業(yè)務(wù)場景的高并發(fā)處理方案。

?

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

?

1 服務(wù)器架構(gòu)

業(yè)務(wù)從發(fā)展的初期到逐漸成熟，服務(wù)器架構(gòu)也是從相對單一到集群，再到分布式服務(wù)。?

一個可以支持高并發(fā)的服務(wù)少不了好的服務(wù)器架構(gòu)，需要有均衡負載，數(shù)據(jù)庫需要主從集群，NoSQL緩存需要主從集群，靜態(tài)文件需要上傳CDN，這些都是能讓業(yè)務(wù)程序流暢運行的強大后盾。

?

服務(wù)器這塊多是需要運維人員來配合搭建，具體我就不多說了，點到為止。

大致需要用到的服務(wù)器架構(gòu)如下：

?

服務(wù)器：

• 均衡負載(如：nginx，阿里云SLB)

• 資源監(jiān)控

• 分布式

?

數(shù)據(jù)庫：

• 主從分離，集群

• DBA 表優(yōu)化，索引優(yōu)化，等

• 分布式

?

NoSQL：

• Redis

  主從分離，集群

• MongoDB

  主從分離，集群

• memcache

  主從分離，集群

?

CDN：

• html

• css

• js

• image

?

2 并發(fā)測試

高并發(fā)相關(guān)的業(yè)務(wù)，需要進行并發(fā)的測試，通過大量的數(shù)據(jù)分析評估出整個架構(gòu)可以支撐的并發(fā)量。

?

測試高并發(fā)可以使用第三方服務(wù)器或者自己測試服務(wù)器，利用測試工具進行并發(fā)請求測試，分析測試數(shù)據(jù)得到可以支撐并發(fā)數(shù)量的評估，這個可以作為一個預(yù)警參考，俗話說知己自彼百戰(zhàn)不殆。

?

第三方服務(wù):

• 阿里云性能測試

?

并發(fā)測試工具：

• Apache JMeter

• Visual Studio性能負載測試

• Microsoft Web Application Stress Tool

?

3 實戰(zhàn)方案

1）通用方案

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

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

服務(wù)器架構(gòu)圖：?

說明：

場景中的這些業(yè)務(wù)基本是用戶進入APP后會操作到的，除了活動日(618、雙11等)，這些業(yè)務(wù)的用戶量都不會高聚集，同時這些業(yè)務(wù)相關(guān)的表都是大數(shù)據(jù)表，業(yè)務(wù)多是查詢操作，所以我們需要減少用戶直接命中DB的查詢；優(yōu)先查詢緩存，如果緩存不存在，再進行DB查詢，將查詢結(jié)果緩存起來。

?

更新用戶相關(guān)緩存需要分布式存儲，比如使用用戶ID進行hash分組，把用戶分布到不同的緩存中，這樣一個緩存集合的總量不會很大，不會影響查詢效率。

方案如：

?

用戶簽到獲取積分：

• 計算出用戶分布的key，Redis，hash中查找用戶今日簽到信息

• 如果查詢到簽到信息，返回簽到信息

• 如果沒有查詢到，DB查詢今日是否簽到過，如果有簽到過，就把簽到信息同步Redis緩存。

• 如果DB中也沒有查詢到今日的簽到記錄，就進行簽到邏輯，操作DB添加今日簽到記錄，添加簽到積分(這整個DB操作是一個事務(wù))

• 緩存簽到信息到Redis，返回簽到信息

• 注意這里會有并發(fā)情況下的邏輯問題，如：一天簽到多次，發(fā)放多次積分給用戶。

?

用戶訂單：

• 這里我們只緩存用戶第一頁的訂單信息，一頁40條數(shù)據(jù)，用戶一般也只會看第一頁的訂單數(shù)據(jù)

• 用戶訪問訂單列表，如果是第一頁讀緩存，如果不是讀DB

• 計算出用戶分布的key，Redis，hash中查找用戶訂單信息

• 如果查詢到用戶訂單信息，返回訂單信息

• 如果不存在就進行DB查詢第一頁的訂單數(shù)據(jù)，然后緩存redis，返回訂單信息

?

用戶中心：

• 計算出用戶分布的key，Redis hash中查找用戶訂單信息

• 如果查詢到用戶信息，返回用戶信息

• 如果不存在進行用戶DB查詢，然后緩存redis，返回用戶信息

?

其他業(yè)務(wù)：

• 上面例子多是針對用戶存儲緩存，如果是公用的緩存數(shù)據(jù)需要注意一些問題，如：公用的緩存數(shù)據(jù)需要考慮并發(fā)下的可能會導(dǎo)致大量命中DB查詢，可以使用管理后臺更新緩存，或者DB查詢的鎖住操作。

?

以上例子是一個相對簡單的高并發(fā)架構(gòu)，并發(fā)量不是很高的情況可以很好的支撐，但是隨著業(yè)務(wù)的壯大，用戶并發(fā)量增加，我們的架構(gòu)也會進行不斷的優(yōu)化和演變，比如對業(yè)務(wù)進行服務(wù)化，每個服務(wù)有自己的并發(fā)架構(gòu)，自己的均衡服務(wù)器，分布式數(shù)據(jù)庫，NoSQL主從集群，如：用戶服務(wù)、訂單服務(wù)。

?

2）消息隊列

秒殺、秒搶等活動業(yè)務(wù)，用戶在瞬間涌入產(chǎn)生高并發(fā)請求。

?

場景：定時領(lǐng)取紅包等。

服務(wù)器架構(gòu)圖：

說明：

• 場景中的定時領(lǐng)取是一個高并發(fā)的業(yè)務(wù)，像秒殺活動用戶會在到點的時間涌入，DB瞬間就接受到一記暴擊，hold不住就會宕機，然后影響整個業(yè)務(wù)；

• 像這種不是只有查詢的操作并且會有高并發(fā)的插入或者更新數(shù)據(jù)的業(yè)務(wù)，前面提到的通用方案就無法支撐，并發(fā)的時候都是直接命中DB；

• 設(shè)計這塊業(yè)務(wù)的時候就會使用消息隊列的，可以將參與用戶的信息添加到消息隊列中，然后再寫個多線程程序去消耗隊列，給隊列中的用戶發(fā)放紅包；

?

方案如：

• 定時領(lǐng)取紅包；

• 一般習(xí)慣使用 redis的 list；

• 當(dāng)用戶參與活動，將用戶參與信息push到隊列中；

• 然后寫個多線程程序去pop數(shù)據(jù)，進行發(fā)放紅包的業(yè)務(wù)；

• 這樣可以支持高并發(fā)下的用戶可以正常的參與活動，并且避免數(shù)據(jù)庫服務(wù)器宕機的危險。

?

附加：?通過消息隊列可以做很多的服務(wù)。?

如：定時短信發(fā)送服務(wù)，使用sset(sorted set)，發(fā)送時間戳作為排序依據(jù)，短信數(shù)據(jù)隊列根據(jù)時間升序，然后寫個程序定時循環(huán)去讀取sset隊列中的第一條，當(dāng)前時間是否超過發(fā)送時間，如果超過就進行短信發(fā)送。

?

3）一級緩存

高并發(fā)請求連接緩存服務(wù)器超出服務(wù)器能夠接收的請求連接量，部分用戶出現(xiàn)建立連接超時無法讀取到數(shù)據(jù)的問題；

?

因此需要有個方案當(dāng)高并發(fā)時候時候可以減少命中緩存服務(wù)器；

?

這時候就出現(xiàn)了一級緩存的方案，一級緩存就是使用站點服務(wù)器緩存去存儲數(shù)據(jù)，注意只存儲部分請求量大的數(shù)據(jù)，并且緩存的數(shù)據(jù)量要控制，不能過分的使用站點服務(wù)器的內(nèi)存而影響了站點應(yīng)用程序的正常運行，一級緩存需要設(shè)置秒單位的過期時間，具體時間根據(jù)業(yè)務(wù)場景設(shè)定，目的是當(dāng)有高并發(fā)請求的時候可以讓數(shù)據(jù)的獲取命中到一級緩存，而不用連接緩存NoSQL數(shù)據(jù)服務(wù)器，減少NoSQL數(shù)據(jù)服務(wù)器的壓力。

?

比如APP首屏商品數(shù)據(jù)接口，這些數(shù)據(jù)是公共的不會針對用戶自定義，而且這些數(shù)據(jù)不會頻繁的更新，像這種接口的請求量比較大就可以加入一級緩存；

?

服務(wù)器架構(gòu)圖：

?

合理地規(guī)范和使用NoSQL緩存數(shù)據(jù)庫，根據(jù)業(yè)務(wù)拆分緩存數(shù)據(jù)庫的集群，這樣基本可以很好支持業(yè)務(wù)，一級緩存畢竟是使用站點服務(wù)器緩存所以還是要善用。

?

4）靜態(tài)化數(shù)據(jù)

高并發(fā)請求數(shù)據(jù)不變化的情況下如果可以不請求自己的服務(wù)器獲取數(shù)據(jù)那就可以減少服務(wù)器的資源壓力。

?

對于更新頻繁度不高，并且數(shù)據(jù)允許短時間內(nèi)的延遲，可以通過數(shù)據(jù)靜態(tài)化成JSON、XML、HTML等數(shù)據(jù)文件上傳CDN，在拉取數(shù)據(jù)的時候優(yōu)先到CDN拉取，如果沒有獲取到數(shù)據(jù)再從緩存，數(shù)據(jù)庫中獲取，當(dāng)管理人員操作后臺編輯數(shù)據(jù)再重新生成靜態(tài)文件上傳同步到CDN，這樣在高并發(fā)的時候可以使數(shù)據(jù)的獲取命中在CDN服務(wù)器上。

?

CDN節(jié)點同步有一定的延遲性，所以找一個靠譜的CDN服務(wù)器商也很重要。

?

5）其他方案

對于更新頻繁度不高的數(shù)據(jù)，APP、PC瀏覽器，可以緩存數(shù)據(jù)到本地，然后每次請求接口的時候上傳當(dāng)前緩存數(shù)據(jù)的版本號，服務(wù)端接收到版本號判斷版本號與最新數(shù)據(jù)版本號是否一致，如果不一樣就進行最新數(shù)據(jù)的查詢并返回最新數(shù)據(jù)和最新版本號，如果一樣就返回狀態(tài)碼告知數(shù)據(jù)已經(jīng)是最新。減少服務(wù)器壓力：資源、帶寬。

總結(jié)

以上是生活随笔為你收集整理的电商那些年，我摸爬打滚出的高并发架构实战精髓的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。