使如何使項(xiàng)目的并發(fā)性更高?使用ID自增保證排隊(duì)順序
發(fā)表時間:2023-08-30 來源:明輝站整理相關(guān)軟件相關(guān)文章人氣:
[摘要]場景分析這里以搶紅包場景為例,需求如下: 1.紅包有個數(shù)限制,假設(shè)紅包的個數(shù)限制為X。2.紅包金額上線限制,假設(shè)金額上線為Y。3.要求用戶搶紅包的時候,不超過紅包的個數(shù)限制X。4.要求用戶搶紅包的時候,不超過紅包的金額Y。5.每個用戶一次紅包活動只能搶一個。常規(guī)思路這里提一下最常見的思路: ...
場景分析
這里以搶紅包場景為例,需求如下:
1.紅包有個數(shù)限制,假設(shè)紅包的個數(shù)限制為X。
2.紅包金額上線限制,假設(shè)金額上線為Y。
3.要求用戶搶紅包的時候,不超過紅包的個數(shù)限制X。
4.要求用戶搶紅包的時候,不超過紅包的金額Y。
5.每個用戶一次紅包活動只能搶一個。
常規(guī)思路
這里提一下最常見的思路:
1.在用戶搶紅包時,檢查當(dāng)前發(fā)出去紅包數(shù)量和金額,并加鎖。
2.檢查紅包數(shù)量和金額正常的后,隨機(jī)用戶紅包金額。
3.然后修改紅包發(fā)出去的數(shù)量和金額,并給用戶贈送紅包,然后解鎖。
常規(guī)思路的優(yōu)缺點(diǎn)
首先是優(yōu)點(diǎn)
1.思路簡單
2.編不下去了。。。
然后是缺點(diǎn)
1.鎖數(shù)據(jù)回造成大量進(jìn)程等待,造成浪費(fèi)資源。
2.鎖造成的等待,用戶體驗(yàn)奇差。
3.對于鎖機(jī)制不太了解的同學(xué)會產(chǎn)生一定的危險性。
優(yōu)化思路
先分析,為什么常規(guī)思路會慢?
1.在搶紅包的時候,每次都需要檢查紅包的上限 X 和 Y。
2.鎖會造成大量進(jìn)程卡頓。
3.生成紅包的金額時還需要檢查與上限 X 跟 Y 是否有沖突。
優(yōu)化解決方案
紅包生成前置
例如紅包個數(shù)上限為X,金額上限為Y。
那么,我在活動進(jìn)行前就把這 X 個紅包插入到數(shù)據(jù)庫
并生成序號:HB1、HB2、HB3。。。。HBX
那么實(shí)際上,到時候用戶就只需要按照先后順序去領(lǐng)取這個有序的紅包隊(duì)列了。
這個操作減少了到時候線上所產(chǎn)生的很多的計(jì)算量。最重要的是,能夠簡單且有效的保證了整個活動的可控性。
利用ID自增保證排隊(duì)順序
這里利用到了一個ID生成表,通過建立 user_id 的唯一索引,保證每個人只能拿到一個序號。
搶紅包步驟如下
1.活動創(chuàng)建之前,創(chuàng)建一張ID生成表,ID從 1 開始自增,且 user_id 唯一。
2.活動開始,用戶開始搶紅包操作。
3.搶紅包之前,先插入ID表,獲取插入ID,如果ID > X,通知用戶已被搶完。
4.如果 ID <= X,那么恭喜了,去紅包表領(lǐng)取序號為 ID 的紅包,并走異步發(fā)紅包過程。
5.活動結(jié)束之后,把相關(guān)用戶領(lǐng)取信息存儲在紅包表,刪除ID生成表。
方案優(yōu)點(diǎn)
1.不需要代碼實(shí)現(xiàn)鎖機(jī)制。
2.邏輯簡單。
3.mysql保證每個用戶只能拿到一個,且有序。
更多思考
有些朋友提到,可以用 redis 隊(duì)列存儲紅包信息,但是實(shí)際上 redis 比較占用內(nèi)存,需要長期存儲數(shù)據(jù)最好還是放在mysql。實(shí)際上,這里可以使用 redis 的 incr 命令,得到類似在上面提到的 ID 生成表的功能,更加快速且嚴(yán)格遞增,能夠使整個項(xiàng)目的并發(fā)性更高。
【相關(guān)推薦】
1. 免費(fèi)mysql在線視頻教程
2. MySQL最新手冊教程
3. 數(shù)據(jù)庫設(shè)計(jì)那些事
以上就是使如何使項(xiàng)目的并發(fā)性更高?利用ID自增保證排隊(duì)順序的詳細(xì)內(nèi)容,更多請關(guān)注php中文網(wǎng)其它相關(guān)文章!
學(xué)習(xí)教程快速掌握從入門到精通的SQL知識。