大家有沒有遇到過，庫存異常的情況：

• 系統重試，導致庫存扣了多次；
• 系統并發，導致庫存設置錯誤；

今天和大家聊一聊庫存扣減里的方案設計。

庫存微服務一般提供什么接口？

提供庫存的查詢、扣減、設置等RPC接口：

• 庫存查詢接口，微服務一般執行：

select num from stock where sid=$sid

• 庫存扣減接口，微服務一般執行：

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

• 庫存設置接口，微服務一般執行：

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

庫存操作，一般是什么業務場景？

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

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

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

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

簡言之，一般是“先查后減”。

庫存“先查后減”會遇到什么問題？

系統往往有重試機制，這個重試機制可能實現在系統底層，例如：服務連接池重試，數據庫連接池重試，業務代碼不可控。

如果通過扣減接口來修改庫存，在重試時會導致重復扣減：

如上圖所示，try和retry，導致一次扣減執行兩次，最終得到一個錯誤庫存。

如何解決“重試導致庫存異常”的問題？

這里的根本原因：“reduce”操作是一個非冪等的操作，不能夠重復執行，可以升級為“set”操作：

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

因此，應該“先查后設”。

庫存“先查后設”會遇到什么問題？

并發量很大時，還是可能導致庫存異常：

如上圖所示，兩個并發的操作，查詢庫存，都得到了庫存是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應該失敗掉；

畫外音：有條件的成功。

接口實現優化升級，將庫存設置接口執行的：

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），是一種常見的降低讀寫鎖沖突，保證數據一致性的方法。

總結

• “先查后減”，在重試，并發的場景下，容易出現異常；
• “先查后設”，冪等性優化，能夠解決重試的問題；
• “先查后設，有條件的射”，CAS優化，能夠解決并發的問題；

知其然，知其所以然。

思路比結論更重要。