一、秒殺商品模型

二、架構(gòu)設(shè)計(jì)

2.1 Redis + MQ

• 緩存預(yù)熱：秒殺商品一般時(shí)效性比較強(qiáng)，一場(chǎng)秒殺活動(dòng)持續(xù)的時(shí)間不會(huì)很長(zhǎng)，當(dāng)在后臺(tái)設(shè)置秒殺活動(dòng)添加秒殺商品時(shí)，把商品對(duì)應(yīng)的庫(kù)存直接存到 Redis，但是要注意的是，設(shè)置緩存時(shí)一定要設(shè)置過(guò)期時(shí)間。
• 削減請(qǐng)求流量：當(dāng)用戶進(jìn)到秒殺商品詳情及后續(xù)所有操作都應(yīng)當(dāng)進(jìn)行庫(kù)存、秒殺資格校驗(yàn)
• 扣減 Redis 庫(kù)存：當(dāng)用戶從秒殺商品詳情到賬單頁(yè)請(qǐng)求下單時(shí)，加分布式鎖防止用戶重復(fù)提交請(qǐng)求，等后續(xù)校驗(yàn)通過(guò)后，扣減 Redis 庫(kù)存，通過(guò) Redis 保證線程安全，也能保證商品不會(huì)超賣，但是此時(shí)并不扣減 DB 庫(kù)存
• 扣減 DB 庫(kù)存：用戶支付核銷監(jiān)聽(tīng)交易支付成功消息，以樂(lè)觀鎖形式扣減 DB 庫(kù)存。因?yàn)橹挥袚尩綆?kù)存后才能到后續(xù)的支付邏輯，一般到秒殺支付邏輯的流量已經(jīng)很少了，當(dāng)并發(fā)通過(guò)樂(lè)觀鎖扣減 DB 庫(kù)存失敗時(shí)，消息會(huì)重試，保證 Redis 庫(kù)存與 DB 庫(kù)存的一致性
• 歸還 Redis 庫(kù)存：用戶搶到庫(kù)存不一定會(huì)支付，當(dāng)用戶取消訂單或者訂單超時(shí)未支付時(shí)，監(jiān)聽(tīng)訂單取消消息，歸還 Redis 庫(kù)存
• 歸還 Redis 與 DB 庫(kù)存：用戶下單支付后請(qǐng)求退款，應(yīng)當(dāng)歸還 Redis 與 DB 的庫(kù)存，這里可以考慮監(jiān)聽(tīng)交易消息，也可以通過(guò)交易直調(diào)接口的形式處理，因?yàn)橥丝顖?chǎng)景比較少，一般不會(huì)有很大的流量

這種方式實(shí)現(xiàn)起來(lái)比較簡(jiǎn)單，對(duì)于流量不是特別大的業(yè)務(wù)一般夠用了，當(dāng)流量特別大時(shí)就需要在上游進(jìn)行流量控制了，整個(gè)過(guò)程要考慮是否會(huì)出現(xiàn)緩存穿透、緩存雪崩問(wèn)題。

總結(jié)

以上是生活随笔為你收集整理的业务总结002:秒杀活动架构设计的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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