前言

如果你第一次接觸秒殺，可能還不太理解，庫存100件就賣100件，在資料庫里減到0就好了，這有什麼麻煩的?理論上是這樣，但是具體到業務場景中就沒那麼簡單了。今天就聊聊減庫存的設計，之後以高可用方案來結束秒殺設計的全部內容。

一、秒殺中的減庫存

減庫存操作一般有如下幾個方式：

1.下單減庫存：下單後，在商品的總庫存中減去購買數量，下單減庫存是最簡單的減庫存方式，也是控制最精確的一種，下單時直接通過資料庫的事務機制控制商品庫存，這樣一定不會出現超賣的情況。

2.付款減庫存：下單後，並不立即減庫存，而是等到付款後才真正減庫存，否則庫存一直保留給其他買家，但因為付款時才減庫存，如果併發比較高，有可能出現買家下單後付不了款的情況，可能商品已經被其他人買走了。

3.預扣庫存：下單後，庫存為其保留一定的時間， 超過這個時間，庫存將會自動釋放，釋放後其他買家就可以繼續購買，在買家付款前，系統會校驗該庫存是否還有保留，如果沒有保留，則再次嘗試預扣；如果庫存不足則不允許繼續付款；如果預扣成功，則完成付款並實際地減去庫存，這種方式相對複雜一些。

以上這幾種減庫存的方式都會存在一些問題。  假如我們採用“下單減庫存”的方式，正常情況下，買家下單後付款的概率會很高，所以不會有太大問題，但是有一種場景例外，就是當賣家參加某個活動時，此時活動的有效時間是商品的黃金售賣時間，通過惡意下單的方式將該賣家的商品全部下單，那麼這款商品就不能正常售賣了。要知道，這些惡意下單的人是不會真正付款的。

既然“下單減庫存”可能導致惡意下單，從而影響賣家的商品銷售，那麼有沒有辦法解決呢?你可能會想，採用“付款減庫存”的方式是不是就可以了?的確可以，但是 “付款減庫存”又會 導致另外一個問題：庫存超賣。假如有10件商品，因為下單時不會減庫存，就可能出現100人下單成功的情況，這樣一 來，就會導致很多買家下單成功但是付不了款，購物體驗自然比較差。

既然“下單減庫存”和“付款減庫存”都有缺點，我們能否採用“預扣庫存”這種方式呢? 這種方案確實可以在一定程度上緩解上面的問題，但是否就徹底解決了呢?針對惡意 下單這種情況，雖然把有效的付款時間設置為10分鐘，但是惡意買家完全可以在10分鐘後再次下單。

針對這種情況，解決辦法還是要結合反作弊的措施來制止， 例如，設置最大購買件數，對重覆下單不付款的操作進行次數限制等。針對“庫存超賣”這種情況，在10分鐘時間內下單的數量仍然有可能超過庫存數量，遇到這種情況只能區別對待：對普通的商品下單數量超過庫存數量的情況，可以通過補貨來解決；但是有些賣家完全不允許庫存為負數的情況，那隻能在買家付款時提示庫存不足。

由於參加秒殺的商品成功下單後卻不付款的情況比較少，再加上賣家對秒殺商品的庫存有嚴格限制，所以秒殺商品採用“下單減庫存”更加合理。一般我們有多種解決方案：一種是在應用程式中通過事務來判斷，即保證減後庫存不能為負數，否則就回滾；另一種辦法是直接設置資料庫的欄位數據為 無符號整數， 這樣減後庫存欄位值小於零時會直接執行SQL語句來報錯。 

二、秒殺中的高可用

高可用涉及架構階段、編碼階段、測試階段、運行階段。

1.架構階段：架構階段主要考慮系統的可擴展性和容錯性，要避免系統出現單點問題，例如多機房部署，即使某個機房出現整體故障，仍然不會影響整體網站的運轉。

2.編碼階段：編碼最重要的是保證代碼的健壯性，例如涉及遠程調用問題時，要設置合理的超時退出機制，防止被其他系統拖垮。

3.測試階段：測試主要是保證測試用例的覆蓋度，保證最壞情況發生時，我們也有相應的處理流 程。

4.運行階段：系統大部分時間都會處於運行態，運行態最重要的是對系統的監控要準確及時，發現問題能夠準確報警並且報警數據要準確詳細，以便於排查問題。

 為什麼系統的高可用建設要放到整個生命周期中全面考慮?因為我們在每個環節中都可能犯錯， 而有些環節犯的錯是無法彌補的。例如在架構階段，沒有消除單點問題，那麼系統 上線後，遇到突發流量把單點給掛了，加機器都加不進去。

那麼針對秒殺系統，我們重點介紹在遇到大流量時，應該從哪些方面來保障系統的穩定運行，所 以更多的是看如何針對運行階段進行處理，這就引出了接下來的內容：降級、限流。

降級：就是當系統的容量達到一定程度時，限制或者關閉系統的某些非核心功能，從而把有限的資源保留給更核心的業務。降級方案可以這樣設計：當秒殺流量達到5w/s時，把成交記錄的獲取從展示20條降級到只展示5條。 

執行降級無疑是在系統性能和用戶體驗之間選擇了前者，降級後肯定會影響一部分用戶的體驗，。 所以降級的核心目標是犧牲次要的功能和用戶體驗來保證核心業務流程的穩定，是一個不得已而 為之的舉措。

限流： 如果說降級是犧牲了一部分次要的功能和用戶的體驗效果，那麼限流就是更極端的一種保護措施 了。限流就是當系統容量達到瓶頸時，我們需要通過限制一部分流量來保護系統，並做到既可以人工執行開關，也支持自動化保護的措施。

首先，來分別說下客戶端限流和服務端限流的優缺點。 客戶端限流，好處可以限制請求的發出，通過減少發出無用請求從而減少對系統的消耗，缺點 就是當客戶端比較分散時，沒法設置合理的限流閾值。如果閾值設的太小，會導致服務端沒有 達到瓶頸時客戶端已經被限制；而如果設的太大，則起不到限制的作用。 服務端限流，好處是可以根據服務端的性能設置合理的閾值，而缺點就是被限制的請求都是無效的請求，處理這些無效的請求本身也會消耗伺服器資源。

以上的內容就是我所介紹的秒殺系統設計中的難點和一些解決思路，不是每個方案都完美，選擇一個適合自己的才重要。