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

• 調用層，一般是處於端上的browser或者APP

• 站點層，一般是拼裝html或者json返回的web-server層

• 服務層，一般是提供RPC調用接口的service層

• 數據層，提供固化數據存儲的db

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

• 庫存查詢，stock-service本質上執行的是 select num from stock where sid=$sid

• 庫存扣減，stock-service本質上執行的是 update stock set num=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），是一種常見的降低讀寫鎖沖突，保證數據一致性的方法。

總結

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

• 調用“設置庫存”接口，能夠保證數據的冪等性

• 在實現“設置庫存”接口時，需要加上原有庫存的比較，才允許設置成功，能解決高並發下庫存扣減的一致性問題

庫存扣多了，到底怎麽整