設計搶購業務時，請務必注意這4個要點
———— / BEGIN / ————
案例：馬上就到雙十一了，上級給我安排了一個秒殺搶購的活動，讓我設計一個方案，那我應該如何下手呢？
頁面上面的設計，這裡我就不多說了，各大網站上都有很多案例了！
現在我重點來講一下需要注意的幾點：
一、超賣問題
假如你的庫存有10，現在3個使用者來購買，a使用者購買3個，b使用者購買5個，c使用者購買3個，合起來就是準備購買11個。
如果三個使用者是同時併發購買，會出現怎樣的情況呢？
每個使用者進行減庫存的時候，資料庫都會去修改一下資料，如下：update goods set amount=amount-購買數量 where goods_id=xxx。
mysql會鎖定這一行資料（使用innodb儲存引擎），資料庫加的是排他鎖。
根據排他鎖的特點： 其他執行緒不能讀、不能寫此行資料。
排他鎖情況下，那麼其他使用者就是等待狀態了。
1. a使用者執行update的時候，鎖定庫存資料。update執行完畢後，減去了3個後，mysql自動釋放鎖。
2. b使用者執行，減去了5個。此時，已經賣掉8個庫存了，庫存數為2了。
3. 但是c使用者接著執行，Update goods set amount=amount-1 where goods_id=xxx。
結果庫存數量變成-1了。
思考：把庫存數量欄位的型別，設計成正數型別，不允許出現負數，會怎麼樣呢?
測驗結果：資料庫會直接報錯，通不過。
解決辦法：只有庫存數量，大於或等於購買數量的時候，才能去減庫存；其他情況，提示資訊，庫存不足。
二、併發的問題
為了更好的理解併發和同步，我們需要先明白兩個重要的概念：同步和非同步。
同步和非同步的區別和聯絡：
- 所謂同步，可以理解為在執行完一個函式或方法之後，一直等待系統返回值或訊息，這時程式是出於阻塞的，只有接收到返回的值或訊息後才往下執行其它的命令。
- 非同步，執行完函式或方法後，不必阻塞性地等待返回值或訊息，只需要向系統委託一個非同步過程，那麼當系統接收到返回值或訊息時，系統會自動觸發委託的非同步過程，從而完成一個完整的流程。
同步在一定程度上可以看做是單執行緒，這個執行緒請求一個方法後就待這個方法給他回覆，否則他不往下執行。非同步在一定程度上可以看做是多執行緒的，請求一個方法後，就不管了，繼續執行其他的方法。
如何處理併發和同步？
首先需要明白，鎖機制有兩個層面：
- 一種是程式碼層次上的，如：java中的同步鎖，典型的就是同步關鍵字synchronized，這裡我不在做過多的講解；
- 另外一種是資料庫層次上的，比較典型的就是悲觀鎖和樂觀鎖。這裡我們重點講解的就是悲觀鎖（傳統的物理鎖）和樂觀鎖。
悲觀鎖 （Pessimistic Locking）：
悲觀鎖，正如其名，它指的是對資料被外界（包括本系統當前的其他事務，以及來自 外部系統的事務處理）修改持保守態度，因此，在整個資料處理過程中，將資料處於鎖定狀態。
悲觀鎖的實現，往往依靠資料庫提供的鎖機制（也只有資料庫層提供的鎖機制才能 真正保證資料訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系 統不會修改資料）。
第一種問題中描述的超賣現象，其實是併發搶購時出現的情況。用到的是資料庫內帶的加排他鎖方式，阻止了其他執行緒讀取、訪問資料，這樣等待的時間就比較長。而業界一般的解決是使用樂觀鎖的辦法來解決：使用資料庫的樂觀鎖是通用解決辦法。
樂觀鎖：
相對悲觀鎖而言，樂觀鎖機制採取了更加寬鬆的加鎖機制。悲觀鎖大多數情況下依靠資料庫的鎖機制實現，以保證操作最大程度的獨佔性。
但隨之而來的就是資料庫效能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。
如：一個金融系統，當某個操作員讀取使用者的資料，並在讀出的使用者資料的基礎上進 行修改時（如更改使用者帳戶餘額），如果採用悲觀鎖機制，也就意味著整個操作過程中（從操作員讀出資料、開始修改直至提交修改結果的全過程，甚至還包括操作員中途去煮咖啡的時間），資料庫記錄始終處於加鎖狀態。
可以想見：如果面對幾百上千個併發，這樣的情況將導致怎樣的後果。
樂觀鎖機制在一定程度上解決了這個問題。
通俗說就是： 修改資料的時候，不給資料加鎖。
樂觀鎖意思是不鎖定表的情況下，利用業務的控制來解決併發問題，這樣即保證資料的併發可讀性又保證儲存資料的排他性，保證效能的同時解決了併發帶來的髒資料問題。
所以很多情況下都會採用樂觀鎖來解決業務上的問題。
高併發的解決方法主要有以下幾點：
（1）前臺優化
- 減少http請求——css檔案合併 ，js檔案合併；
- 壓縮js，css檔案；
- 使用雪碧圖；
- 懶載入（只加載看到的第一屏內容，下拉之後看到其他的內容）；
- 預載入（只加載預設圖）；
- cdn 加速。
（2）服務端優化：
- 頁面靜態化；
- 負載均衡、叢集；
- 分散式；
- 使用佇列。
（3）SQL/">MySQL優化：
- 查詢優化，能單表的單表
- 查詢一條資料使用limit
- 生成查詢快取
- 使用索引
- 多表查詢使用id進行關聯
- 資料庫分表
- 資料庫分割槽
- 資料庫叢集
- 要查詢的欄位避免使用*號，指定需要的欄位
- 避免使用%字首的模糊查詢
- 避免使用負向查詢
- 避免使用or查詢
- 避免使用子查詢
- 避免使用MySQL自帶函式
- 不要是rand
- 有順序的讀取
- 設定合適的資料型別
- 避免使用text型別
- 避免使用null
（4）程式碼優化：
- 用單引號代替雙引號，雙引號會查詢變數；
- 避免使用require_once require_once會判斷檔案是否載入過；
- 使用靜態方法代替普通方法，靜態方法速度比普通方法快4倍；
- 變數使用完之後需要銷燬；
- 儘量不要使用@；
- include用絕對路徑，不要使用相對路徑，相對路徑會有查詢的過程；
- 避免使用__SET __GET __AUTOLOAD；
- 迴圈的時候先確定迴圈次數，不要每次迴圈都要計算；
- 避免迴圈查庫；
- 避免多層foreach巢狀；
- 避免使用遞迴 ，遞迴比較浪費資源。
三、下單和減庫存要在一個事務中
如果不在一個事務內，可能出現兩種現象：
1. 訂單入庫失敗、減庫存成功。 發現訂單入庫失敗，減庫存就不要繼續進行下去了。
2. 訂單入庫成功、減庫存失敗。 實際下了20個訂單，庫存卻沒有減。資料不一致了。
四、設計虛擬庫存和真實庫存兩套方案
有些人下單完後，最終並不會去付款。
如果一下單就馬上減庫存,很多人下單，最終並不會去付款，可能導致庫存數最後為0，別的使用者無法下單了。
而實際中倉庫中卻有庫存在——這樣庫存資料是不準確的。
什麼時候減庫存？
是下單完成減庫存、還是付款完後減庫存呢?
付款後，才減庫存，可能出現的現象：使用者下完單，接著去付款，結果庫存不夠了，這樣使用者體驗很不好。但是淘寶的設計是3天（大廠就是比較任性哦）
買家拍下商品後，“等待買家付款”的狀態下系統會給予買家3天的時間進行付款，此時的付款動作是將錢款支付到支付寶公司。
此付款時間無法延長，若逾期未付款，交易將自動關閉，如您仍想購買，建議重新購買並及時付款。但是如果下完單就減庫存，並能夠保證使用者下單隻要付款，就一定能買到這個商品。
這樣的使用者體驗會較好。
具體技術實現辦法：下單後，馬上減去庫存。另外設定一個定時指令碼，掃描超過30分未支付的訂單，把訂單中的商品數量返回到庫存中去，訂單關閉。
如唯品會的購物下單：
為什麼使用虛擬庫存和真實庫存兩套方案？
假設庫存數是50，a訂單購買了5個件商品，支付完畢，庫存數減去5，庫存數變成了45件。
由於還沒有發貨，實際庫存中還有50件商品，這樣會出現混淆了。
使用兩套庫存記錄方案是有必要的！
- 下單-操作虛擬庫存數
- 商品發貨出庫-操作真實庫存數
五、減少頻繁讀資料庫的壓力
使用者每次點選一個商品詳情頁面，都要讀取庫存，判斷：有沒有庫存。如果讀庫存走的是資料庫判斷，很多人來搶購的情況下，資料庫的壓力會很大。
假設是1萬個使用者同時訪問搶購頁面，資料庫接受的訪問次數是1萬個併發。
使用者還要進行重新整理頁面操作，由於每次重新整理都會走資料庫判斷庫存。數量會更大，資料庫的壓力就更大了。所以最好是，把庫存總數，快取在redis中去。
記憶體中快取的庫存數量，只用來做讀判斷，這樣壓力扛住了。而更改資料庫的庫存總數了，程式馬上要把庫存總數，同步到快取中去。
系統抗壓力問題：
- 如何限流？
- 如何防止惡意刷資料？
防止限流就是寫程式碼去阻止部分人進行頻繁請求，為了識別是機器還是人工。加一些友好一點的驗證碼，這樣不管是從體驗上還是從系統的穩定性方面都是比較好的。
如下圖淘寶做的驗證：
滑塊驗證碼方案，驗證碼後臺針對使用者產生的行為軌跡資料進行機器學習建模，結合訪問頻率、地理位置、歷史記錄等多個維度資訊，快速、準確的返回人機判定結果。
攻與防技術都是在對抗中不斷升級的，無解的驗證碼還不存在，但防的一方可以不斷提升破解成本。
應用選擇滑塊驗證，也有部分因素是因為競爭激烈的網際網路很看重使用者體驗。拖動畢竟是趣味性互動且容易完成，而圖形驗證碼既容易被黑客攻破，對使用者也並沒有那麼友好——肉眼識別無趣（可能還很艱難），鍵盤手動輸入更浪費時間，體驗不太好。
總結
本文介紹了產品在設計搶購閃購商品活動中應該注意的幾點事項，在設計閃購活動時，會圍繞如何處理併發、扣除庫存、防止惡意刷資料等問題。
各公司可以先根據自己的業務情況來設計相對應的方案，然後再用成本計演算法，反算開發時間與成本，這樣既保證了專案進度，效能體驗等也不錯。
———— / END / ————
作者：香魚