在今天雙 11 這個(gè)萬眾狂歡的節(jié)日，對(duì)于阿里員工來說，每個(gè)環(huán)節(jié)都將面臨前所未有的考驗(yàn)，特別是技術(shù)環(huán)節(jié)，今天我們就一起來探討下雙11天量交易額背后的技術(shù)。

一、阿里雙11秒殺場(chǎng)景

[[249104]]

今日凌晨零點(diǎn)，2018年天貓雙11全球狂歡節(jié)，根據(jù)現(xiàn)場(chǎng)實(shí)時(shí)數(shù)據(jù)，雙11開場(chǎng)2分05秒破百億，26分03秒破500億，1小時(shí)47分26秒破千億。

根據(jù)公開數(shù)據(jù)，在2017年雙11購物狂歡節(jié)上，開場(chǎng)28秒鐘成交額破10億， 3分01秒成交額破百億，9小時(shí)04秒破千億。交易峰值32.5萬/秒，支付峰值25.6萬/秒，刷新全球紀(jì)錄。同時(shí)誕生的還有數(shù)據(jù)庫處理峰值，4200萬次/秒。

幾乎毫無懸念，今年天貓雙11將刷新去年1682億的銷售記錄，技術(shù)的各種峰值數(shù)據(jù)也將再次打破全球記錄。

然而在這樣的業(yè)務(wù)場(chǎng)景下，背后是靠什么樣的技術(shù)來支持如此龐大的秒殺場(chǎng)景?

二、阿里雙11背后的技術(shù)

1. 云計(jì)算

利用云計(jì)算彈性能力，支撐交易峰值每秒32.5萬筆、支付峰值每秒25.6萬筆的混合云彈性架構(gòu)。

2. 分布式消息引擎

在雙11當(dāng)天實(shí)現(xiàn)萬億級(jí)消息流轉(zhuǎn)。

3. Docker技術(shù)

交易核心應(yīng)用容器化撐起雙11交易下單峰值，解放資源的超大規(guī)模Docker化技術(shù)。

4. 在線交易的數(shù)據(jù)實(shí)時(shí)和離線計(jì)算能力

支撐全球最大規(guī)模在線交易的數(shù)據(jù)實(shí)時(shí)和離線計(jì)算能力，包括承載阿里巴巴集團(tuán)核心大數(shù)據(jù)的離線計(jì)算平臺(tái)，以及雙十一保證每秒處理億條日志的計(jì)算。

5. 阿里人工智能

在搜索、推薦以及客服場(chǎng)景下的創(chuàng)新應(yīng)用，包括人工智能賦能的數(shù)千家品牌商家店鋪的個(gè)性化運(yùn)營和粉絲會(huì)員的精準(zhǔn)營銷。

6. VR技術(shù)

虛擬購物環(huán)境背后的VR技術(shù)。

7. 前端技術(shù)

應(yīng)對(duì)前端極限挑戰(zhàn)的淘寶直播首屏秒開，以及應(yīng)用世界級(jí)開源跨平臺(tái)移動(dòng)開發(fā)工具Weex實(shí)現(xiàn)雙11會(huì)場(chǎng)幾近全覆蓋，實(shí)現(xiàn)全網(wǎng)首屏渲染完美踐行“秒開”體驗(yàn)。

8. 監(jiān)控技術(shù)

千萬量級(jí)監(jiān)控項(xiàng)，PB級(jí)監(jiān)控?cái)?shù)據(jù)，億級(jí)報(bào)警通知背后的技術(shù)。

9. 物流技術(shù)

菜鳥通過包裹預(yù)測(cè)、供應(yīng)鏈入庫、訂單下沉、訂單路由調(diào)度、電子面單及智能分單，以及末端小件員，涉及十億級(jí)包裹的雙11之戰(zhàn)。

總之，雙11將涉及：基礎(chǔ)設(shè)施、存儲(chǔ)、中間件、云計(jì)算、業(yè)務(wù)架構(gòu)、大數(shù)據(jù)、認(rèn)知計(jì)算與人工智能、交互技術(shù)等技術(shù)領(lǐng)域。

由于篇幅有限無法完全詳細(xì)展開，我就以其中一個(gè)大家最關(guān)心的雙11秒殺場(chǎng)景為例，貫穿這些部分技術(shù)的應(yīng)用和設(shè)計(jì)思路。

三、雙11秒殺架構(gòu)設(shè)計(jì)思路

秒殺系統(tǒng)特點(diǎn)是并發(fā)量極大，但實(shí)際秒殺成功的請(qǐng)求數(shù)量卻很少，所以如果不在前端攔截很可能造成數(shù)據(jù)庫讀寫鎖沖突，甚至導(dǎo)致死鎖，最終請(qǐng)求超時(shí)。

很重要的設(shè)計(jì)思路：將請(qǐng)求攔截在系統(tǒng)上游，降低下游壓力。

1. 充分利用分布式緩存(tair+redis)

利用緩存可極大提高系統(tǒng)讀寫速度。

2. 充分利用消息中間件削峰

這里有相關(guān)的阿里消息中間件(Notify和MetaQ)，以及開源的(ActiveMQ、Kafka等)。

消息隊(duì)列可以削峰，將攔截大量并發(fā)請(qǐng)求，這也是一個(gè)異步處理過程，后臺(tái)業(yè)務(wù)根據(jù)自己的處理能力，從消息隊(duì)列中主動(dòng)的拉取請(qǐng)求消息進(jìn)行業(yè)務(wù)處理。

3. 前端設(shè)計(jì)優(yōu)化

• 頁面靜態(tài)化：將活動(dòng)頁面上的所有可以靜態(tài)的元素全部靜態(tài)化，并盡量減少動(dòng)態(tài)元素，通過CDN來抗峰值。
• 禁止重復(fù)提交：用戶提交之后按鈕置灰，禁止重復(fù)提交，防止一秒鐘內(nèi)多次寫入數(shù)據(jù)庫。
• 用戶限流：在某一時(shí)間段內(nèi)只允許用戶提交一次請(qǐng)求，比如可以采取IP限流

4. 后端設(shè)計(jì)優(yōu)化

• 服務(wù)端控制器層(網(wǎng)關(guān)層)
• 限制uid(UserID)訪問頻率：我們上面攔截了瀏覽器訪問的請(qǐng)求，但針對(duì)某些惡意攻擊或其它插件，在服務(wù)端控制層需要針對(duì)同一個(gè)訪問uid，限制訪問頻率。
• 服務(wù)層：上面只攔截了一部分訪問請(qǐng)求，當(dāng)秒殺的用戶量很大時(shí)，即使每個(gè)用戶只有一個(gè)請(qǐng)求，到服務(wù)層的請(qǐng)求數(shù)量還是很大。比如我們有100W用戶同時(shí)搶100臺(tái)手機(jī)，服務(wù)層并發(fā)請(qǐng)求壓力至少為100W。
• 采用消息隊(duì)列緩存請(qǐng)求：既然服務(wù)層知道庫存只有100臺(tái)手機(jī)，那完全沒有必要把100W個(gè)請(qǐng)求都傳遞到數(shù)據(jù)庫啊，那么可以先把這些請(qǐng)求都寫到消息隊(duì)列緩存一下，數(shù)據(jù)庫層訂閱消息減庫存，減庫存成功的請(qǐng)求返回秒殺成功，失敗的返回秒殺結(jié)束。
• 利用緩存應(yīng)對(duì)讀請(qǐng)求：比如雙11秒殺搶購，是典型的讀多寫少業(yè)務(wù)，大部分請(qǐng)求是查詢請(qǐng)求，所以可以利用緩存分擔(dān)數(shù)據(jù)庫壓力。
• 利用緩存應(yīng)對(duì)寫請(qǐng)求：緩存也是可以應(yīng)對(duì)寫請(qǐng)求的，比如我們就可以把數(shù)據(jù)庫中的庫存數(shù)據(jù)轉(zhuǎn)移到Redis緩存中，所有減庫存操作都在Redis中進(jìn)行，然后再通過后臺(tái)進(jìn)程把Redis中的用戶秒殺請(qǐng)求同步到數(shù)據(jù)庫中。

5. 數(shù)據(jù)庫層

數(shù)據(jù)庫層是最脆弱的一層，一般在應(yīng)用設(shè)計(jì)時(shí)在上游就需要把請(qǐng)求攔截掉，數(shù)據(jù)庫層只承擔(dān)“能力范圍內(nèi)”的訪問請(qǐng)求。所以，上面通過在服務(wù)層引入隊(duì)列和緩存，讓最底層的數(shù)據(jù)庫高枕無憂。

淘寶在09年的時(shí)候就已經(jīng)提前把數(shù)據(jù)庫按照業(yè)務(wù)進(jìn)行垂直拆分，再結(jié)合業(yè)務(wù)需要進(jìn)行水平拆分。現(xiàn)在對(duì)數(shù)據(jù)庫的拆分，都是利用數(shù)據(jù)庫層中間件(淘寶 tddl)，來進(jìn)行無縫對(duì)數(shù)據(jù)庫的侵入設(shè)計(jì)。

除此以外還會(huì)涉及到分布式小文件存儲(chǔ)以及搜索引擎，以及服務(wù)器集群監(jiān)控等技術(shù)。