秒殺的設計就是目的 就是限制訪問db導致宕機的問題
可以從如下幾個方案解決
1客戶端，例如:禁止用戶重復提交請求；到時間的是只能點擊一次限制，限制用戶在x秒之內只能提交一次請求
2站點層面的請求攔截，例如: 可以記憶體儲存 5s只能提交一個請求，頁面快取，同一個uid，限制訪問頻度，做頁面快取，x秒內到達站點層的請求，均回傳同一頁面
3 服務層來攔截，控制所有的請求到都到資料庫層
具體方案: 用Redis和RabbitMQ中間件 redis 記錄商品數量，有庫存的創建訂單號寫入RabbitMQ ， 回傳訂單號，跳轉到支付頁面，可以輪訓一下（因為可能mq添加訂單，可能還沒有成功） ，根據訂單號拿到數待支付的訂單，成功后后續操作扣減庫存等等， 沒有庫存的，直接到沒搶到頁面，這樣就用redis控制了有限的訪問資料庫層，其實還有一種復雜點，是不需要redis計數的，是在消費端控制數量，假設 庫存數量是100個，并發是10萬，只要消費端沒有消費100個，佇列會一直添加資料，知道消費完了100個，這時候發個訊息給添加的佇列的，通知他不需要加了，這時候在請求的時候直接回傳已售完，但是在佇列的一些也需要回傳，可以了輪訓或者其他技術、知道知否已經添加完訂單，
4 資料庫層： 問題不大了，再扛不住，機器擴容 集群負載均衡搞一波，
總結
（1）盡量將請求攔截在系統上游（越上游越好）；
（2）讀多寫少的常用多使用快取（快取抗讀壓力）；
瀏覽器和APP：做限速
站點層：按照uid做限速，做頁面快取
服務層：按照業務做寫請求佇列控制流量，做資料快取
資料層：閑庭信步
并且：結合業務做優化
https://www.cnblogs.com/hello-/articles/10345026.html 參考文章
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/244256.html
標籤：其他