【併發】關於併發、超賣處理的思路

作電商網站，常常會有各類秒殺和熱門商品，因此高併發的處理一直是電商最重要的事情。這裏記錄下當初本身是如何處理的

寫在前面：

一、本文設計到的併發處理均是針對縱向，不針對橫向擴展，即只設計從PHP層面到數據庫層面的處理，不涉及多臺服務器，集羣、大帶寬等的橫向設計。

二、本文中涉及到的高併發並非淘寶京東等幾百萬幾千萬等的高併發，僅僅只是普通最多上萬的併發處理

三、本文不對悲觀鎖樂觀鎖作設計

問題：

普通電商中的秒殺中的併發問題，超賣問題

實例：商品數量爲100，秒殺人數爲10000，整點開始秒殺

秒殺大概流程：

①商品詳情點擊購買(秒殺)--》②輸入信息提交訂單--》③進行支付

解決思路：

一、人數閥門設計

二、會員排隊設計

三、問答問題設計

四、庫存緩存設計

五、頁面靜態設計

思路理解：

1、人數閥門設計：進行用戶人羣過濾。

商品數量只有100份，秒殺人數有10000人，那麼咱們就設計1道閥門（根據狀況，能夠設計3道或者2道均可以的）。

在整點的時候，咱們對點擊了「購買」按鈕後，咱們只運行500人進入信息填寫頁面，信息填寫完成後提交訂單。效果以下：

①商品詳情點擊購買(秒殺)--》②輸入信息提交訂單--》③進行支付

               10000人                          500人                    （這裏也能夠設計閥門，只容許多少人進入支付）

其餘未進入的如何處理乃？顯示已搶完或者排隊等待（這就是後面要提到的排隊系統設計）。

2、會員排隊設計：對用戶進行排隊，排在前面的先購買

這至關因而消息隊列模式了，若是秒殺是當即知道結果，排隊可能會有點雞肋。

在第二步②輸入信息提交訂單後進行排隊，排在前面的先購買，排在後面的後購買

3、問答問題設計：過濾掉一些反應慢的用戶

在第一步①點擊購買後跳轉到問題頁面，用戶必須回答正確問題後，方可進入後面的流程

4、庫存緩存設計：緩存庫存，判斷用戶購買的商品是否還有，不讀取數據庫，速度快，也不會增長數據庫負擔，通過前面的過濾，超賣的可能性比較低了

提早將商品庫存緩存起來，到下單購買的時候，用戶購買了就減1，每次都經過庫存緩存判斷一下，若是爲0就顯示已搶完。

5、頁面靜態設計：儘可能靜態緩存化【CDN那些這裏不作考慮】

第一步①商品詳情頁面，儘可能進行緩存，減輕大批量用戶在訪問商品頁面的時候，大量查詢數據庫。

問答問題頁面：全靜態，加載快，無數據庫負擔。

排隊等待頁面：全靜態，加載快，無數據庫負擔。

排隊結束頁面：全靜態，加載快，無數據庫負擔。

小試牛刀：

上面說了那麼多廢話，總歸在一塊兒，流程大概就成了下面這樣：

①商品詳情點擊購買(秒殺)  --》 ②進入問題回答頁面      --》③排隊等待 --》 ④輸入信息提交訂單    --》  ⑤進行支付

    頁面緩存                                        問題過濾                      閥門過濾                                       緩存庫存減小

                                                          頁面緩存                      頁面緩存

實戰：

代碼怎麼獨立出來乃？仍是本身寫一個流程。今天先到這裏吧，代碼實戰再單獨寫一個

 

附件：

1、參考資料

①、淘寶閥門設計

②、各大電商網站秒殺流程

③、網絡上面的各類文獻資料

 

寫在最後：

本人對併發處理並不深刻，所知道的知識都是來源於網絡資料和各類網站參考。雖然我這樣的設計已經用於系統中，而且基本上解決了普通的這些問題，可是這樣的設計可能存在必定的問題或者不完善，或者根本就是錯誤的。

轉自：https://my.oschina.net/kenblog/blog/516659