目錄

• 一、為什么難
• 二、常見架構(gòu)
• 三、優(yōu)化方向
• 四、優(yōu)化細節(jié)
• 五、Redis
• 六、總結(jié)

一、為什么難

秒殺系統(tǒng)難做的原因：庫存只有一份，所有人會在集中的時間讀和寫這些數(shù)據(jù)。例如小米手機每周二的秒殺，可能手機只有1萬部，但瞬時進入的流量可能是幾百幾千萬。又例如12306搶票，亦與秒殺類似，瞬時流量更甚。這篇文章主要介紹了秒殺場景的緩存、隊列、鎖使用Redis優(yōu)化設(shè)計方案，文中通過示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下

主要需要解決的問題有兩個：

• 高并發(fā)對數(shù)據(jù)庫產(chǎn)生的壓力
• 競爭狀態(tài)下如何解決庫存的正確減少（超賣問題）

對于第一個問題，已經(jīng)很容易想到用緩存來處理搶購，避免直接操作數(shù)據(jù)庫，例如使用Redis。重點在于第二個問題，常規(guī)寫法：
查詢出對應(yīng)商品的庫存，看是否大于0，然后執(zhí)行生成訂單等操作，但是在判斷庫存是否大于0處，如果在高并發(fā)下就會有問題，導(dǎo)致庫存量出現(xiàn)負數(shù)

二、常見架構(gòu)

流量到了億級別，常見站點架構(gòu)如上：

• 瀏覽器端，最上層，會執(zhí)行到一些JS代碼
• 站點層，這一層會訪問后端數(shù)據(jù)，拼html頁面返回給瀏覽器
• 服務(wù)層，向上游屏蔽底層數(shù)據(jù)細節(jié)
• 數(shù)據(jù)層，最終的庫存是存在這里的，mysql是一個典型

三、優(yōu)化方向

1）將請求盡量攔截在系統(tǒng)上游：傳統(tǒng)秒殺系統(tǒng)之所以掛，請求都壓倒了后端數(shù)據(jù)層，數(shù)據(jù)讀寫鎖沖突嚴重，并發(fā)高響應(yīng)慢，幾乎所有請求都超時，流量雖大，下單成功的有效流量甚小【一趟火車其實只有2000張票，200w個人來買，基本沒有人能買成功，請求有效率為0】
2）充分利用緩存：這是一個典型的讀多寫少的應(yīng)用場景【一趟火車其實只有2000張票，200w個人來買，最多2000個人下單成功，其他人都是查詢庫存，寫比例只有0.1%，讀比例占99.9%】，非常適合使用緩存。

四、優(yōu)化細節(jié)

4.1）瀏覽器層請求攔截

點擊了“查詢”按鈕之后，系統(tǒng)那個卡呀，進度條漲的慢呀，作為用戶，我會不自覺的再去點擊“查詢”，繼續(xù)點，繼續(xù)點，點點點。。。有用么？平白無故的增加了系統(tǒng)負載（一個用戶點5次，80%的請求是這么多出來的），怎么整？

a 產(chǎn)品層面，用戶點擊“查詢”或者“購票”后，按鈕置灰，禁止用戶重復(fù)提交請求
b JS層面，限制用戶在x秒之內(nèi)只能提交一次請求

如此限流，80%流量已攔。

4.2）站點層請求攔截與頁面緩存

瀏覽器層的請求攔截，只能攔住小白用戶（不過這是99%的用戶喲），高端的程序員根本不吃這一套，寫個for循環(huán)，直接調(diào)用你后端的http請求，怎么整？

a 同一個uid，限制訪問頻度，做頁面緩存，x秒內(nèi)到達站點層的請求，均返回同一頁面
b 同一個item的查詢，例如手機車次，做頁面緩存，x秒內(nèi)到達站點層的請求，均返回同一頁面

如此限流，又有99%的流量會被攔截在站點層

4.3）服務(wù)層請求攔截與數(shù)據(jù)緩存站點層的請求攔截，只能攔住普通程序員，高級黑客，假設(shè)他控制了10w臺肉雞（并且假設(shè)買票不需要實名認證），這下uid的限制不行了吧？怎么整？

a 大哥，我是服務(wù)層，我清楚的知道小米只有1萬部手機，我清楚的知道一列火車只有2000張車票，我透10w個請求去數(shù)據(jù)庫有什么意義呢？對于寫請求，做請求隊列，每次只透有限的寫請求去數(shù)據(jù)層，如果均成功再放下一批，如果庫存不夠則隊列里的寫請求全部返回“已售完”

b 對于讀請求，還要我說么？cache抗，不管是memcached還是redis，單機抗個每秒10w應(yīng)該都是沒什么問題的

如此限流，只有非常少的寫請求，和非常少的讀緩存mis的請求會透到數(shù)據(jù)層去，又有99.9%的請求被攔住了

4.4）數(shù)據(jù)層到了數(shù)據(jù)這一層，幾乎就沒有什么請求了，單機也能扛得住，還是那句話，庫存是有限的，小米的產(chǎn)能有限，透這么多請求來數(shù)據(jù)庫沒有意義。

4.5）mysql批量入庫提高INSERT效率

五、Redis

使用redis隊列（list），push和pop操作保證了原子性的實現(xiàn)。即使有很多用戶同時到達，也是依次執(zhí)行。（mysql事務(wù)在高并發(fā)下性能下降很厲害）

先將商品庫存存入隊列：

<?php  $store=1000;  //商品庫存$redis=new Redis();  $result=$redis->connect("127.0.0.1",6379);  $res=$redis->llen("goods_store");   for($i=0; $i<$store; $i++){      $redis->lpush("goods_store",1);  }  echo $redis->llen("goods_store");  ?>

客戶執(zhí)行下單操作：

$redis=new Redis();  $result=$redis->connect("127.0.0.1",6379);$count = $redis->lpop("goods_store");if(!$count){    echo "搶購失??！";    return;}

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

六、總結(jié)

沒什么總結(jié)了，上文應(yīng)該描述的非常清楚了，對于秒殺系統(tǒng)，再次重復(fù)下兩個架構(gòu)優(yōu)化思路：
1）盡量將請求攔截在系統(tǒng)上游2）讀多寫少經(jīng)量多使用緩存3) redis隊列緩存 + mysql 批量入庫

到此這篇關(guān)于秒殺場景的緩存、隊列、鎖使用Redis優(yōu)化設(shè)計方案的文章就介紹到這了,更多相關(guān)Redis秒殺優(yōu)化設(shè)計內(nèi)容請搜索以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持！