什么是秒殺

秒殺場(chǎng)景一般會(huì)在電商網(wǎng)站舉行一些活動(dòng)或者節(jié)假日在12306網(wǎng)站上搶票時(shí)遇到。對(duì)于電商網(wǎng)站中一些稀缺或者特價(jià)商品，電商網(wǎng)站一般會(huì)在約定時(shí)間點(diǎn)對(duì)其進(jìn)行限量銷售，因?yàn)檫@些商品的特殊性，會(huì)吸引大量用戶前來?yè)屬?gòu)，并且會(huì)在約定的時(shí)間點(diǎn)同時(shí)在秒殺頁(yè)面進(jìn)行搶購(gòu)。

秒殺系統(tǒng)場(chǎng)景特點(diǎn)

• 秒殺時(shí)大量用戶會(huì)在同一時(shí)間同時(shí)進(jìn)行搶購(gòu)，網(wǎng)站瞬時(shí)訪問流量激增。
• 秒殺一般是訪問請(qǐng)求數(shù)量遠(yuǎn)遠(yuǎn)大于庫(kù)存數(shù)量，只有少部分用戶能夠秒殺成功。
• 秒殺業(yè)務(wù)流程比較簡(jiǎn)單，一般就是下訂單減庫(kù)存。

秒殺架構(gòu)設(shè)計(jì)理念

限流：?鑒于只有少部分用戶能夠秒殺成功，所以要限制大部分流量，只允許少部分流量進(jìn)入服務(wù)后端。

削峰：對(duì)于秒殺系統(tǒng)瞬時(shí)會(huì)有大量用戶涌入，所以在搶購(gòu)一開始會(huì)有很高的瞬間峰值。高峰值流量是壓垮系統(tǒng)很重要的原因，所以如何把瞬間的高流量變成一段時(shí)間平穩(wěn)的流量也是設(shè)計(jì)秒殺系統(tǒng)很重要的思路。實(shí)現(xiàn)削峰的常用的方法有利用緩存和消息中間件等技術(shù)。

異步處理：秒殺系統(tǒng)是一個(gè)高并發(fā)系統(tǒng)，采用異步處理模式可以極大地提高系統(tǒng)并發(fā)量，其實(shí)異步處理就是削峰的一種實(shí)現(xiàn)方式。

內(nèi)存緩存：秒殺系統(tǒng)最大的瓶頸一般都是數(shù)據(jù)庫(kù)讀寫，由于數(shù)據(jù)庫(kù)讀寫屬于磁盤IO，性能很低，如果能夠把部分?jǐn)?shù)據(jù)或業(yè)務(wù)邏輯轉(zhuǎn)移到內(nèi)存緩存，效率會(huì)有極大地提升。

可拓展：當(dāng)然如果我們想支持更多用戶，更大的并發(fā)，最好就將系統(tǒng)設(shè)計(jì)成彈性可拓展的，如果流量來了，拓展機(jī)器就好了。像淘寶、京東等雙十一活動(dòng)時(shí)會(huì)增加大量機(jī)器應(yīng)對(duì)交易高峰。

架構(gòu)方案

一般秒殺系統(tǒng)架構(gòu)

設(shè)計(jì)思路

將請(qǐng)求攔截在系統(tǒng)上游，降低下游壓力：秒殺系統(tǒng)特點(diǎn)是并發(fā)量極大，但實(shí)際秒殺成功的請(qǐng)求數(shù)量卻很少，所以如果不在前端攔截很可能造成數(shù)據(jù)庫(kù)讀寫鎖沖突，甚至導(dǎo)致死鎖，最終請(qǐng)求超時(shí)。?
充分利用緩存：利用緩存可極大提高系統(tǒng)讀寫速度。?
消息隊(duì)列：消息隊(duì)列可以削峰，將攔截大量并發(fā)請(qǐng)求，這也是一個(gè)異步處理過程，后臺(tái)業(yè)務(wù)根據(jù)自己的處理能力，從消息隊(duì)列中主動(dòng)的拉取請(qǐng)求消息進(jìn)行業(yè)務(wù)處理。

前端方案

瀏覽器端(js)：

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

后端方案

服務(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ù)層知道庫(kù)存只有100臺(tái)手機(jī)，那完全沒有必要把100W個(gè)請(qǐng)求都傳遞到數(shù)據(jù)庫(kù)啊，那么可以先把這些請(qǐng)求都寫到消息隊(duì)列緩存一下，數(shù)據(jù)庫(kù)層訂閱消息減庫(kù)存，減庫(kù)存成功的請(qǐng)求返回秒殺成功，失敗的返回秒殺結(jié)束。

利用緩存應(yīng)對(duì)讀請(qǐng)求：對(duì)類似于12306等購(gòu)票業(yè)務(wù)，是典型的讀多寫少業(yè)務(wù)，大部分請(qǐng)求是查詢請(qǐng)求，所以可以利用緩存分擔(dān)數(shù)據(jù)庫(kù)壓力。

利用緩存應(yīng)對(duì)寫請(qǐng)求：緩存也是可以應(yīng)對(duì)寫請(qǐng)求的，比如我們就可以把數(shù)據(jù)庫(kù)中的庫(kù)存數(shù)據(jù)轉(zhuǎn)移到Redis緩存中，所有減庫(kù)存操作都在Redis中進(jìn)行，然后再通過后臺(tái)進(jìn)程把Redis中的用戶秒殺請(qǐng)求同步到數(shù)據(jù)庫(kù)中。

數(shù)據(jù)庫(kù)層

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

案例：利用消息中間件和緩存實(shí)現(xiàn)簡(jiǎn)單的秒殺系統(tǒng)

Redis是一個(gè)分布式緩存系統(tǒng)，支持多種數(shù)據(jù)結(jié)構(gòu)，我們可以利用Redis輕松實(shí)現(xiàn)一個(gè)強(qiáng)大的秒殺系統(tǒng)。

我們可以采用Redis 最簡(jiǎn)單的key-value數(shù)據(jù)結(jié)構(gòu)，用一個(gè)原子類型的變量值(AtomicInteger)作為key，把用戶id作為value，庫(kù)存數(shù)量便是原子變量的最大值。對(duì)于每個(gè)用戶的秒殺，我們使用?RPUSH key value插入秒殺請(qǐng)求， 當(dāng)插入的秒殺請(qǐng)求數(shù)達(dá)到上限時(shí)，停止所有后續(xù)插入。

然后我們可以在臺(tái)啟動(dòng)多個(gè)工作線程，使用?LPOP key?讀取秒殺成功者的用戶id，然后再操作數(shù)據(jù)庫(kù)做最終的下訂單減庫(kù)存操作。

當(dāng)然，上面Redis也可以替換成消息中間件如ActiveMQ、RabbitMQ等，也可以將緩存和消息中間件 組合起來，緩存系統(tǒng)負(fù)責(zé)接收記錄用戶請(qǐng)求，消息中間件負(fù)責(zé)將緩存中的請(qǐng)求同步到數(shù)據(jù)庫(kù)。

參考文檔：https://my.oschina.net/xianggao/blog/524943

============================

導(dǎo)論

曾經(jīng)被問過好多次怎樣實(shí)現(xiàn)秒殺系統(tǒng)的問題。昨天又在CSDN架構(gòu)師微信群被問到了。因此這里把我設(shè)想的實(shí)現(xiàn)秒殺系統(tǒng)的價(jià)格設(shè)計(jì)分享出來。供大家參考。

秒殺系統(tǒng)的架構(gòu)設(shè)計(jì)

秒殺系統(tǒng)，是典型的短時(shí)大量突發(fā)訪問類問題。對(duì)這類問題，有三種優(yōu)化性能的思路：?
寫入內(nèi)存而不是寫入硬盤?
異步處理而不是同步處理?
分布式處理?
用上這三招，不論秒殺時(shí)負(fù)載多大，都能輕松應(yīng)對(duì)。更好的是，Redis能夠滿足上述三點(diǎn)。因此，用Redis就能輕松實(shí)現(xiàn)秒殺系統(tǒng)。?
用我這個(gè)方案，無論是電商平臺(tái)特價(jià)秒殺，12306火車票秒殺，都不是事:)

下面介紹一下為什么上述三種性能優(yōu)化思路能夠解決秒殺系統(tǒng)的性能問題：

• 寫入內(nèi)存而不是寫入硬盤?
  傳統(tǒng)硬盤的讀寫性能是相當(dāng)差的。SSD硬盤比傳統(tǒng)硬盤快100倍。而內(nèi)存又比SSD硬盤快10倍以上。因此，寫入內(nèi)存而不是寫入硬盤，就能使系統(tǒng)的能力提升上千倍。也就是說，原來你的秒殺系統(tǒng)可能需要1000臺(tái)服務(wù)器支撐，現(xiàn)在1臺(tái)服務(wù)器就可以扛住了。?
  你可能會(huì)有這樣的疑問：寫入內(nèi)存而不是持久化，那么如果此時(shí)計(jì)算機(jī)宕機(jī)了，那么寫入的數(shù)據(jù)不就全部丟失了嗎？如果你就這么倒霉碰到服務(wù)器宕機(jī)，那你就沒秒到了，有什么大不了？?
  最后，后面真正處理秒殺訂單時(shí)，我們會(huì)把信息持久化到硬盤中。因此不會(huì)丟失關(guān)鍵數(shù)據(jù)。?
  Redis是一個(gè)緩存系統(tǒng)，數(shù)據(jù)寫入內(nèi)存后就返回給客戶端了，能夠支持這個(gè)特性。

• 異步處理而不是同步處理?
  像秒殺這樣短時(shí)大并發(fā)的系統(tǒng)，在性能負(fù)載上有一個(gè)明顯的波峰和長(zhǎng)期的波谷。為了應(yīng)對(duì)相當(dāng)短時(shí)間的大并發(fā)而準(zhǔn)備大量服務(wù)器來應(yīng)對(duì)，在經(jīng)濟(jì)上是相當(dāng)不合算的。?
  因此，對(duì)付秒殺類需求，就應(yīng)該化同步為異步。用戶請(qǐng)求寫入內(nèi)存后立刻返回。后臺(tái)啟動(dòng)多個(gè)線程從內(nèi)存池中異步讀取數(shù)據(jù)，進(jìn)行處理。如用戶請(qǐng)求可能是1秒鐘內(nèi)進(jìn)入的，系統(tǒng)實(shí)際處理完成可能花30分鐘。那么一臺(tái)服務(wù)器在異步情況下其處理能力大于同步情況下1800多倍！?
  異步處理，通常用MQ(消息隊(duì)列)來實(shí)現(xiàn)。Redis可以看作是一個(gè)高性能的MQ。因?yàn)樗臄?shù)據(jù)讀寫都發(fā)生在內(nèi)存中。

• 分布式處理?
  好吧。也許你的客戶很多，秒殺系統(tǒng)即使用了上面兩招，還是捉襟見肘。沒關(guān)系，我們還有大招：分布式處理。如果一臺(tái)服務(wù)器撐不住秒殺系統(tǒng)，那么就多用幾臺(tái)服務(wù)器。10臺(tái)不行，就上100臺(tái)。分布式處理，就是把海量用戶的請(qǐng)求分散到多個(gè)服務(wù)器上。一般使用hash實(shí)現(xiàn)均勻分布。?
  這類系統(tǒng)在大數(shù)據(jù)云計(jì)算時(shí)代的今天已經(jīng)有很多了。無非是用Paxos算法和Hash Ring實(shí)現(xiàn)的。?
  Redis Cluster正是這樣一個(gè)分布式的產(chǎn)品。

使用Redis實(shí)現(xiàn)描述系統(tǒng)

Redis和Redis Cluster（分布式版本），是一個(gè)分布式緩存系統(tǒng)。其支持多種數(shù)據(jù)結(jié)構(gòu)，也支持MQ。Redis在性能上做了大量?jī)?yōu)化。因此使用Redis或者Redis Cluster就可以輕松實(shí)現(xiàn)一個(gè)強(qiáng)大的秒殺系統(tǒng)。?
基本上，你用Redis的這些命令就可以了。?
RPUSH key value?
插入秒殺請(qǐng)求

當(dāng)插入的秒殺請(qǐng)求數(shù)達(dá)到上限時(shí)，停止所有后續(xù)插入。?
后臺(tái)啟動(dòng)多個(gè)工作線程，使用?
LPOP key?
讀取秒殺成功者的用戶id，進(jìn)行后續(xù)處理。?
或者使用LRANGE key start end命令讀取秒殺成功者的用戶id，進(jìn)行后續(xù)處理。?
每完成一條秒殺記錄的處理，就執(zhí)行INCR key_num。一旦所有庫(kù)存處理完畢，就結(jié)束該商品的本次秒殺，關(guān)閉工作線程，也不再接收秒殺請(qǐng)求。

要是還撐不住，該怎么辦

也許你會(huì)說，我們的客戶很多。即使部署了Redis Cluster，仍然撐不住。那該怎么辦呢？?
記得某個(gè)偉人曾經(jīng)說過：辦法總比困難多！

下面，我們具體分析下，還有哪些情況會(huì)壓垮我們架構(gòu)在Redis（Cluster）上的秒殺系統(tǒng)。

腳本攻擊

如現(xiàn)在有很多搶火車票的軟件。它們會(huì)自動(dòng)發(fā)起http請(qǐng)求。一個(gè)客戶端一秒會(huì)發(fā)起很多次請(qǐng)求。如果有很多用戶使用了這樣的軟件，就可能會(huì)直接把我們的交換機(jī)給壓垮了。

這個(gè)問題其實(shí)屬于網(wǎng)絡(luò)問題的范疇，和我們的秒殺系統(tǒng)不在一個(gè)層面上。因此不應(yīng)該由我們來解決。很多交換機(jī)都有防止一個(gè)源IP發(fā)起過多請(qǐng)求的功能。開源軟件也有不少能實(shí)現(xiàn)這點(diǎn)。如linux上的TC可以控制。流行的Web服務(wù)器Nginx（它也可以看做是一個(gè)七層軟交換機(jī)）也可以通過配置做到這一點(diǎn)。一個(gè)IP，一秒鐘我就允許你訪問我2次，其他軟件包直接給你丟了，你還能壓垮我嗎？

交換機(jī)撐不住了

可能你們的客戶并發(fā)訪問量實(shí)在太大了，交換機(jī)都撐不住了。?
這也有辦法。我們可以用多個(gè)交換機(jī)為我們的秒殺系統(tǒng)服務(wù)。?
原理就是DNS可以對(duì)一個(gè)域名返回多個(gè)IP，并且對(duì)不同的源IP，同一個(gè)域名返回不同的IP。如網(wǎng)通用戶訪問，就返回一個(gè)網(wǎng)通機(jī)房的IP；電信用戶訪問，就返回一個(gè)電信機(jī)房的IP。也就是用CDN了！?
我們可以部署多臺(tái)交換機(jī)為不同的用戶服務(wù)。 用戶通過這些交換機(jī)訪問后面數(shù)據(jù)中心的Redis Cluster進(jìn)行秒殺作業(yè)。

總結(jié)

有了Redis Cluster的幫助，做個(gè)支持海量用戶的秒殺系統(tǒng)其實(shí)So Easy！?
這里介紹的方案雖然是針對(duì)秒殺系統(tǒng)的，但其背后的原理對(duì)其他高并發(fā)系統(tǒng)一樣有效。?
最后，我們?cè)僦販匾幌赂咝阅芟到y(tǒng)的優(yōu)化原則：?
寫入內(nèi)存而不是寫入硬盤?
異步處理而不是同步處理?
分布式處理

總結(jié)

以上是生活随笔為你收集整理的用Redis轻松实现秒杀系统的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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