《電商那些年，我摸爬打滾出的高并發(fā)架構(gòu)實(shí)戰(zhàn)精髓》要點(diǎn)：
本文介紹了電商那些年，我摸爬打滾出的高并發(fā)架構(gòu)實(shí)戰(zhàn)精髓，希望對您有用。如果有疑問，可以聯(lián)系我們。

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

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

來源：SFLYQ的博客

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

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

• 服務(wù)端：導(dǎo)致站點(diǎn)服務(wù)器/DB服務(wù)器資源被占滿崩潰,數(shù)據(jù)的存儲和更新結(jié)果和理想的設(shè)計(jì)是不一樣的,比如：出現(xiàn)重復(fù)的數(shù)據(jù)記錄,多次添加了用戶積分等.
• 用戶角度：尼瑪,這么卡,老子來參加活動(dòng)的,刷新了還是這樣,垃圾網(wǎng)站,再也不來了!
• 我的經(jīng)歷：在做公司產(chǎn)品網(wǎng)站的過程中,經(jīng)常會有這樣的需求,比如搞個(gè)活動(dòng)專題、抽獎(jiǎng)、簽到、積分競拍等等,如果沒有考慮到高并發(fā)下的數(shù)據(jù)處理,那就Game Over了,很容易導(dǎo)致抽獎(jiǎng)被多抽走,簽到發(fā)現(xiàn)一個(gè)用戶有多條記錄等等,各種超出正常邏輯的現(xiàn)象,這就是做產(chǎn)品網(wǎng)站必須考慮的問題,因?yàn)檫@些都是面向大量用戶的,而不是像做ERP管理系統(tǒng)、OA系統(tǒng)那樣,只是面向員工.

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

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

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

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

• 需求點(diǎn)：?

  【簽到功能】一天一個(gè)用戶只能簽到一次,簽到成功后用戶獲取到一個(gè)積分.

• 已知表：

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

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

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

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

• 需求點(diǎn)：【抽獎(jiǎng)功能】抽獎(jiǎng)一次消耗一個(gè)積分,抽獎(jiǎng)中獎(jiǎng)后編輯剩余獎(jiǎng)品總數(shù),剩余獎(jiǎng)品總數(shù)為0,或者用戶積分為0的時(shí)候無法進(jìn)行抽獎(jiǎng).
• 已知表：用戶表,包含積分字段 獎(jiǎng)品表,包含獎(jiǎng)品剩余數(shù)量字段.
• 高并發(fā)意淫分析(屬于開發(fā)前的猜測)：在高并發(fā)的情況下,會導(dǎo)致用戶參與抽獎(jiǎng)的時(shí)候積分被扣除,而獎(jiǎng)品實(shí)際上已經(jīng)被抽完了.
• 我的設(shè)計(jì)：在事物里,通過WITH(UPDLOCK)鎖住商品表,或者Update 表的獎(jiǎng)品剩余數(shù)量和最后編輯時(shí)間字段,來把數(shù)據(jù)行鎖住,然后進(jìn)行用戶積分的消耗,都完成后提交事物,失敗就回滾. 這樣就可以保證,只有可能存在一個(gè)操作在操作這件商品的數(shù)量,只有等到這個(gè)操作事物提交后,其他的操作這個(gè)商品行的事物才會繼續(xù)執(zhí)行.

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

• 需求點(diǎn)：【緩存數(shù)據(jù)到cache里】,當(dāng)緩存不存在的時(shí)候,從數(shù)據(jù)庫中獲取并保存在cache里,如果存在從cache里獲取,每天10點(diǎn)必須更新一次,其他時(shí)間點(diǎn)緩存兩個(gè)小時(shí)更新一次 到10點(diǎn)的時(shí)候,凡是打開頁面的用戶會自動(dòng)刷新頁面.
• 問題點(diǎn)：這里有個(gè)邏輯用戶觸發(fā)緩存的更新,用戶刷新頁面,當(dāng)緩存存在的時(shí)候,會取到最后一次緩存更新時(shí)間,如果當(dāng)前時(shí)間大于十點(diǎn),并且最后緩存時(shí)間是10點(diǎn)前,則會從數(shù)據(jù)庫中重新獲取數(shù)據(jù)保存到cache中. 還有客戶端頁面會在10點(diǎn)時(shí)候用js發(fā)起頁面的刷新,就是因?yàn)橛羞@樣的邏輯,導(dǎo)致10點(diǎn)的時(shí)候有很多并發(fā)請求同時(shí)過來,然后就會導(dǎo)致很多的sql查詢操作,理想的邏輯是,只有一個(gè)請求會去數(shù)據(jù)庫獲取,其他都是從緩存中獲取數(shù)據(jù).(因?yàn)檫@個(gè)sql查詢很耗服務(wù)器性能,所以導(dǎo)致在10點(diǎn)的時(shí)候,突然間數(shù)據(jù)庫服務(wù)器壓力暴增)
• 解決問題：C#通過(鎖)lock,在從數(shù)據(jù)讀取到緩存的那段代碼前面加上鎖,這樣在并發(fā)的情況下只會有一個(gè)請求是從數(shù)據(jù)庫里獲取數(shù)據(jù),其他都是從緩存中獲取.

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

• 需求： 用戶行為數(shù)據(jù)統(tǒng)計(jì)接口,用來記錄商品展示次數(shù),用戶通過點(diǎn)擊圖片,或者鏈接,或者其他方式進(jìn)入到商品詳情的行為次數(shù).
• 問題點(diǎn)：這接口是給前端ajax使用,訪問量會很大,一頁面展示的時(shí)候就會有幾十件商品的展示,滾動(dòng)條滾到到頁面顯示商品的時(shí)候就會請求接口進(jìn)行展示數(shù)據(jù)的統(tǒng)計(jì),每次翻頁又會加載幾十件.
• 意淫分析：設(shè)想如果同時(shí)有1W個(gè)用戶同時(shí)在線訪問頁面,一個(gè)次拉動(dòng)滾動(dòng)條屏幕頁面展示10件商品,這樣就會有10W個(gè)請求過來,服務(wù)端需要把請求數(shù)據(jù)入庫.在實(shí)際線上環(huán)境可能還會超過這個(gè)請求量,如果不經(jīng)過進(jìn)行高并發(fā)設(shè)計(jì)處理,服務(wù)器分分鐘給跪了.
• 解決問題：我們通過nodejs寫了一個(gè)數(shù)據(jù)處理接口,把統(tǒng)計(jì)數(shù)據(jù)先存到redis的list里.(使用nodejs寫接口的好處是,nodejs使用單線程異步事件機(jī)制,高并發(fā)處理能力強(qiáng),不會因?yàn)閿?shù)據(jù)邏輯處理問題導(dǎo)致服務(wù)器資源被占用而導(dǎo)致服務(wù)器宕機(jī)) 然后再使用nodejs寫了一個(gè)腳本,腳本功能就是從redis里出列數(shù)據(jù)保存到mysql數(shù)據(jù)庫中.這個(gè)腳本會一直運(yùn)行,當(dāng)redis沒有數(shù)據(jù)需要同步到數(shù)據(jù)庫中的時(shí)候,sleep,讓在進(jìn)行數(shù)據(jù)同步操作.

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

以下我所知道的：

1. 服務(wù)器代理nginx,做服務(wù)器的均衡負(fù)載,把壓力均衡到多臺服務(wù)器；
2. 部署集群MySQL數(shù)據(jù)庫, Redis服務(wù)器,或者M(jìn)ongoDB服務(wù)器,把一些常用的查詢數(shù)據(jù),并且不會經(jīng)常的變化的數(shù)據(jù)保存到其他NoSQL DB服務(wù)器中,來減少數(shù)據(jù)庫服務(wù)器的壓力,加快數(shù)據(jù)的響應(yīng)速度；
3. 數(shù)據(jù)緩存,Cache；
4. 在高并發(fā)接口的設(shè)計(jì)中可以使用具有高并發(fā)能力的編程語言去開發(fā),如：nodejs做web接口；
5. 服務(wù)器部署,圖片服務(wù)器分離,靜態(tài)文件走CDN；
6. DBA數(shù)據(jù)庫的優(yōu)化查詢條件,索引優(yōu)化；
7. 消息存儲機(jī)制,將數(shù)據(jù)添加到信息隊(duì)列中(redis list),然后再寫工具去入庫
8. 腳本合理控制請求,如,防止用戶重復(fù)點(diǎn)擊導(dǎo)致的ajax多余的請求,等等.

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

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

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

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

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

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

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

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

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

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

服務(wù)器：

• 均衡負(fù)載(如：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ù),需要進(jìn)行并發(fā)的測試,通過大量的數(shù)據(jù)分析評估出整個(gè)架構(gòu)可以支撐的并發(fā)量.

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

第三方服務(wù):

• 阿里云性能測試

并發(fā)測試工具：

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

3、實(shí)戰(zhàn)方案

1)通用方案

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

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

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

說明：

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

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

方案如：

用戶簽到獲取積分：

• 計(jì)算出用戶分布的key,Redis,hash中查找用戶今日簽到信息
• 如果查詢到簽到信息,返回簽到信息
• 如果沒有查詢到,DB查詢今日是否簽到過,如果有簽到過,就把簽到信息同步Redis緩存.
• 如果DB中也沒有查詢到今日的簽到記錄,就進(jìn)行簽到邏輯,操作DB添加今日簽到記錄,添加簽到積分(這整個(gè)DB操作是一個(gè)事務(wù))
• 緩存簽到信息到Redis,返回簽到信息
• 注意這里會有并發(fā)情況下的邏輯問題,如：一天簽到多次,發(fā)放多次積分給用戶.

用戶訂單：

• 這里我們只緩存用戶第一頁的訂單信息,一頁40條數(shù)據(jù),用戶一般也只會看第一頁的訂單數(shù)據(jù)
• 用戶訪問訂單列表,如果是第一頁讀緩存,如果不是讀DB
• 計(jì)算出用戶分布的key,Redis,hash中查找用戶訂單信息
• 如果查詢到用戶訂單信息,返回訂單信息
• 如果不存在就進(jìn)行DB查詢第一頁的訂單數(shù)據(jù),然后緩存redis,返回訂單信息

用戶中心：

• 計(jì)算出用戶分布的key,Redis hash中查找用戶訂單信息
• 如果查詢到用戶信息,返回用戶信息
• 如果不存在進(jìn)行用戶DB查詢,然后緩存redis,返回用戶信息

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

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

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

2)消息隊(duì)列

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

場景：定時(shí)領(lǐng)取紅包等.

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

說明：

• 場景中的定時(shí)領(lǐng)取是一個(gè)高并發(fā)的業(yè)務(wù),像秒殺活動(dòng)用戶會在到點(diǎn)的時(shí)間涌入,DB瞬間就接受到一記暴擊,hold不住就會宕機(jī),然后影響整個(gè)業(yè)務(wù)；
• 像這種不是只有查詢的操作并且會有高并發(fā)的插入或者更新數(shù)據(jù)的業(yè)務(wù),前面提到的通用方案就無法支撐,并發(fā)的時(shí)候都是直接命中DB；
• 設(shè)計(jì)這塊業(yè)務(wù)的時(shí)候就會使用消息隊(duì)列的,可以將參與用戶的信息添加到消息隊(duì)列中,然后再寫個(gè)多線程程序去消耗隊(duì)列,給隊(duì)列中的用戶發(fā)放紅包；

方案如：

• 定時(shí)領(lǐng)取紅包；
• 一般習(xí)慣使用 redis的 list；
• 當(dāng)用戶參與活動(dòng),將用戶參與信息push到隊(duì)列中；
• 然后寫個(gè)多線程程序去pop數(shù)據(jù),進(jìn)行發(fā)放紅包的業(yè)務(wù)；
• 這樣可以支持高并發(fā)下的用戶可以正常的參與活動(dòng),并且避免數(shù)據(jù)庫服務(wù)器宕機(jī)的危險(xiǎn).

附加：?通過消息隊(duì)列可以做很多的服務(wù).
如：定時(shí)短信發(fā)送服務(wù),使用sset(sorted set),發(fā)送時(shí)間戳作為排序依據(jù),短信數(shù)據(jù)隊(duì)列根據(jù)時(shí)間升序,然后寫個(gè)程序定時(shí)循環(huán)去讀取sset隊(duì)列中的第一條,當(dāng)前時(shí)間是否超過發(fā)送時(shí)間,如果超過就進(jìn)行短信發(fā)送.

3)一級緩存

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

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

這時(shí)候就出現(xiàn)了一級緩存的方案,一級緩存就是使用站點(diǎn)服務(wù)器緩存去存儲數(shù)據(jù),注意只存儲部分請求量大的數(shù)據(jù),并且緩存的數(shù)據(jù)量要控制,不能過分的使用站點(diǎn)服務(wù)器的內(nèi)存而影響了站點(diǎn)應(yīng)用程序的正常運(yùn)行,一級緩存需要設(shè)置秒單位的過期時(shí)間,具體時(shí)間根據(jù)業(yè)務(wù)場景設(shè)定,目的是當(dāng)有高并發(fā)請求的時(shí)候可以讓數(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ù),一級緩存畢竟是使用站點(diǎn)服務(wù)器緩存所以還是要善用.

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

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

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

CDN節(jié)點(diǎn)同步有一定的延遲性,所以找一個(gè)靠譜的CDN服務(wù)器商也很重要.

5)其他方案

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

 

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/4408.html