秒殺系統的場景特點
秒殺時大量使用者會在同一時間同時迸行搶購,網站瞬時訪問流量激增
秒殺一般是訪問請求量遠遠大於庫存數量,只有少部分使用者能夠秒殺成功
秒殺業務流程比較簡單,一般就是下訂單操作
秒殺架構設計理念
- 限流
鑑於只有少部分使用者能夠秒殺成功,所以要限制大部分流量,只允許少部分流裡量進入服務後端(暫未處理);
- 削峰
對於秒殺系統瞬時的大量使用者湧入,所以在搶購開始會有很髙的瞬時峰值。實現削峰的常用方法有利用快取或者訊息中介軟體等技術
- 非同步處理
對於高併發系統,採用非同步處理模式可以極大地高系統併發量,非同步處理就是削峰的一種實現方式
- 記憶體快取
秒殺系統最大的瓶頸最終都可能會是資料庫的讀寫,主要休現在的磁碟的I/O,效能會很低,如果能把大部分的業務邏輯都搬到快取來處理,效率會有極大的提升
- 可擴充
如果需要支援更多的使用者或者更大的併發,將系統設計為彈性可擴充的,如果流量來了,擴充機器就好;
秒殺設計思路
如果前端是屬於小程式端,所以不存在前端部分的訪問壓力,所以前端的訪問壓力就無從談起;
秒殺相關的活動頁面相關的介面,所有查詢能加快取的,全部新增 redis的快取;
活動相關真實庫存、鎖定庫存、限購、下單處理狀態等全放 redis;
當有請求進來時,進入活動ID為粒度的分散式鎖,第一步進行使用者購買的重複性校驗,滿足條件進入下一步,否則返回已下單的提示
第二步,判斷當前可鎖定的庫存是否大於購買的數量,滿足條件進入下一步,否則返回已售罄的提示
第三步,鎖走當前請求的購買庫存,從鎖定庫存中減除,並將下單的請求放入kafka訊息佇列;
第四步,在 redis中標記一個 polling的key(用於輪詢的請求接囗判斷使用者是否下訂單成功),在 kafka消費端消費完成建立訂單之後需要刪除該key,並且維護一個活動id+使用者id的key,防止重複購買;
第五步,訊息佇列消費,建立訂單,建立訂單成功則扣減redis中的真實庫存,並且刪除 polling的key。如果下單過程出現異常,則刪除限購的key,返還鎖定庫存,提示使用者下單失敗;
第六步,提供一個輪詢介面,給前端在完成搶購動作後,檢查最終下訂單操作是否成功,主要判斷依據是red中的 polling的key的狀態
整個流程會將所有到後滿的請求攔截的在redis的快取層面,除了最終能下訂單的庫存限制訂單會與數擺庫存在互動外,基本上無其他的互動,將資料庫/O壓力降到了最低;
本作品採用《CC 協議》，轉載必須註明作者和本文連結