典型互聯網架構
業務複雜、數據量大、併發量大的業務場景下,典型的互聯網架構,一般會分爲這麼幾層:
•調用層,一般是處於端上的browser或者APP
•站點層,一般是拼裝html或者json返回的web-server層
•服務層,一般是提供RPC調用接口的service層
•數據層,提供固化數據存儲的db
1.對於庫存業務,一般有個庫存服務,提供庫存的查詢、扣減、設置等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
2.用戶下單前,一般會對庫存進行查詢,有足夠的存量才允許扣減:
如上圖所示,通過查詢接口,得到庫存是5。
3.用戶下單時,接着會對庫存進行扣減:
如上圖所示,購買3單位的商品,通過扣減接口,最終得到庫存是2。
希望設計往往有容錯機制,例如“重試”,如果通過扣減接口來修改庫存,在重試時,可能會得到錯誤的數據,導致重複扣減:
如上圖所示,如果數據庫層面有重試容錯機制,可能導致一次扣減執行兩次,最終得到一個負數的錯誤庫存。
重試導致錯誤的根本原因,是因爲“扣減”操作是一個非冪等的操作,不能夠重複執行,改成設置操作則不會有這個問題:
如上圖所示,同樣是購買3單位的商品,通過設置庫存操作,即使有重試容錯機制,也不會得到錯誤的庫存,設置庫存是一個冪等操作。
4.在併發量很大的情況下,還會有其他的問題:
如上圖所示,兩個併發的操作,查詢庫存,都得到了庫存是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=sid
升級爲:
update stock set num=sid and num=$num_old
這正是大家常說的“Compare And Set”(CAS),是一種常見的降低讀寫鎖衝突,保證數據一致性的方法。
總結
在業務複雜,數據量大,併發量大的情況下,庫存扣減容易引發數據的不一致,常見的優化方案有兩個:
•調用“設置庫存”接口,能夠保證數據的冪等性
•在實現“設置庫存”接口時,需要加上原有庫存的比較,才允許設置成功,能解決高併發下庫存扣減的一致性問題