業務復雜、數據量大、并發量大的業務場景下，典型的互聯網架構，一般會分為這么幾層：

• 調用層，一般是處于端上的browser或者APP
• 站點層，一般是拼裝html或者json返回的web-server層
• 服務層，一般是提供RPC調用接口的service層
• 數據層，提供固化數據存儲的db

對于庫存業務，一般有個庫存服務，提供庫存的查詢、扣減、設置等RPC接口：

• 庫存查詢，stock-service本質上執行的是

select num from stock where sid=$sid 

• 庫存扣減，stock-service本質上執行的是

update stock set numnum=num-$reduce where sid=$sid 

• 庫存設置，stock-service本質上執行的是

update stock set num=$num_new where sid=$sid 

用戶下單前，一般會對庫存進行查詢，有足夠的存量才允許扣減：

如上圖所示，通過查詢接口，得到庫存是5。

用戶下單時，接著會對庫存進行扣減：

如上圖所示，購買3單位的商品，通過扣減接口，最終得到庫存是2。

希望設計往往有容錯機制，例如“重試”，如果通過扣減接口來修改庫存，在重試時，可能會得到錯誤的數據，導致重復扣減：

如上圖所示，如果數據庫層面有重試容錯機制，可能導致一次扣減執行兩次，最終得到一個負數的錯誤庫存。

重試導致錯誤的根本原因，是因為“扣減”操作是一個非冪等的操作，不能夠重復執行，改成設置操作則不會有這個問題：

如上圖所示，同樣是購買3單位的商品，通過設置庫存操作，即使有重試容錯機制，也不會得到錯誤的庫存，設置庫存是一個冪等操作。

在并發量很大的情況下，還會有其他的問題：

如上圖所示，兩個并發的操作，查詢庫存，都得到了庫存是5。

接下來用戶發生了并發的購買動作(秒殺類業務特別容易出現)：

如上圖所示：

• 用戶1購買了3個庫存，于是庫存要設置為2
• 用戶2購買了2個庫存，于是庫存要設置為3
• 這兩個設置庫存的接口并發執行，庫存會先變成2，再變成3，導致數據不一致(實際賣出了5件商品，但庫存只扣減了2，***一次設置庫存會覆蓋和掩蓋前一次并發操作)

其根本原因是，設置操作發生的時候，沒有檢查庫存與查詢出來的庫存有沒有變化，理論上：

• 庫存為5時，用戶1的庫存設置才能成功
• 庫存為5時，用戶2的庫存設置才能成功

實際執行的時候：

• 庫存為5，用戶1的set stock 2確實應該成功
• 庫存變為2了，用戶2的set stock 3應該失敗掉

升級修改很容易，將庫存設置接口，stock-service上執行的：

update stock set num=$y where sid=$sid 

升級為：

update stock set num=$num_new where sid=$sid and num=$num_old 

這正是大家常說的“Compare And Set”(CAS)，是一種常見的降低讀寫鎖沖突，保證數據一致性的方法。

總結

在業務復雜，數據量大，并發量大的情況下，庫存扣減容易引發數據的不一致，常見的優化方案有兩個：

• 調用“設置庫存”接口，能夠保證數據的冪等性
• 在實現“設置庫存”接口時，需要加上原有庫存的比較，才允許設置成功，能解決高并發下庫存扣減的一致性問題

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文