业务总结002:秒杀活动架构设计
生活随笔
收集整理的這篇文章主要介紹了
业务总结002:秒杀活动架构设计
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
一、秒殺商品模型
二、架構設計
2.1 Redis + MQ
- 緩存預熱:秒殺商品一般時效性比較強,一場秒殺活動持續的時間不會很長,當在后臺設置秒殺活動添加秒殺商品時,把商品對應的庫存直接存到 Redis,但是要注意的是,設置緩存時一定要設置過期時間。
- 削減請求流量:當用戶進到秒殺商品詳情及后續所有操作都應當進行庫存、秒殺資格校驗
- 扣減 Redis 庫存:當用戶從秒殺商品詳情到賬單頁請求下單時,加分布式鎖防止用戶重復提交請求,等后續校驗通過后,扣減 Redis 庫存,通過 Redis 保證線程安全,也能保證商品不會超賣,但是此時并不扣減 DB 庫存
- 扣減 DB 庫存:用戶支付核銷監聽交易支付成功消息,以樂觀鎖形式扣減 DB 庫存。因為只有搶到庫存后才能到后續的支付邏輯,一般到秒殺支付邏輯的流量已經很少了,當并發通過樂觀鎖扣減 DB 庫存失敗時,消息會重試,保證 Redis 庫存與 DB 庫存的一致性
- 歸還 Redis 庫存:用戶搶到庫存不一定會支付,當用戶取消訂單或者訂單超時未支付時,監聽訂單取消消息,歸還 Redis 庫存
- 歸還 Redis 與 DB 庫存:用戶下單支付后請求退款,應當歸還 Redis 與 DB 的庫存,這里可以考慮監聽交易消息,也可以通過交易直調接口的形式處理,因為退款場景比較少,一般不會有很大的流量
這種方式實現起來比較簡單,對于流量不是特別大的業務一般夠用了,當流量特別大時就需要在上游進行流量控制了,整個過程要考慮是否會出現緩存穿透、緩存雪崩問題。
總結
以上是生活随笔為你收集整理的业务总结002:秒杀活动架构设计的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 业务总结001:优惠券与礼包活动
- 下一篇: 股权代码查询官网全球(股权代码查询官网)