欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

秒殺場景的緩存、隊列、鎖使用Redis優(yōu)化設(shè)計方案

 更新時間:2022年12月14日 08:59:34   投稿:yin  
這篇文章主要介紹了秒殺場景的緩存、隊列、鎖使用Redis優(yōu)化設(shè)計方案,文中通過示例代碼介紹的非常詳細(xì),具有一定的參考價值,感興趣的小伙伴們可以參考一下

一、為什么難

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

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

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

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

二、常見架構(gòu)

圖片描述

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

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

三、優(yōu)化方向

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

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

4.1)瀏覽器層請求攔截

點擊了“查詢”按鈕之后,系統(tǒng)那個卡呀,進度條漲的慢呀,作為用戶,我會不自覺的再去點擊“查詢”,繼續(xù)點,繼續(xù)點,點點點。。。有用么?平白無故的增加了系統(tǒng)負(fù)載(一個用戶點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è)買票不需要實名認(rèn)證),這下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),pushpop操作保證了原子性的實現(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)文章希望大家以后多多支持腳本之家!

相關(guān)文章

最新評論