庫存系統實現

前言

最近在重構以前系統中的庫存處理邏輯。 老的系統中庫存處理邏輯只是一個類裏面的幾個方法，同時是直連DB操做，有緩存處理，可是在數據一致性保障上並無特別的可靠。 隨着運營投入的愈來愈多，新的運營策略在產品表現上會出現大庫存狀況，好比引入package的方式，這樣原有的庫存處理邏輯的QPS就須要變爲百倍了，在高峯期對於數據庫系統的寫QPS是很大的壓力，同時系統不能簡單的經過機器擴容或者橫向擴展解決，因此須要將庫存處理邏輯單獨到獨立的服務系統中進行解決。

業界方案

阿里在數據一致性的處理上採用了數據庫方案，固然爲處理高併發寫入，阿里有能力在數據庫角度進行了優化，能夠支持高併發寫入和事務控制，通常公司不具有這樣的技術能力，須要在業務層進行顯示控制。

系統關鍵點

考慮基於DB解決數據一致性問題，首先要解決單點瓶頸和數據過多形成的數據傾斜問題。

同時系統須要考慮單元化場景下的庫存扣減邏輯，核心邏輯在於庫存扣減是否和用戶產生直接關係。

事務控制

因爲不具有數據庫層面的高併發事務控制，須要在系統層面進行實現。

採用樂觀鎖 整個加鎖時間

start transaction
lock budget record and get its value
subtract budget record by
insert business orders...
commit

經過sql層面更新取代先讀後更新邏輯。

SQL優化批量處理 SQL組合在一塊兒，和DB一次交互，更新語句保持條件更新，保證更新後餘額大於等於0。 SQL添加commit_on_success（減小commit請求網絡交互），target_affect_row 1標籤。

系統分片

單個數據庫沒法支撐高併發寫入，考慮「桶拆分」，根據userId進行分桶，子桶配額不足時，路由到主桶。 主桶和子桶按比例分配，子桶適合時機回收。

設置分桶閾值，自動分桶，同時基於日誌流水（定時任務）進行分桶合併，異步將庫存分桶合併到主桶。可下降更新頻率，只在合併時發生更新一次，經過定時任務消除分桶碎片，定時任務進行補償。

分佈式事務

庫存扣減設計到下游多個服務聚合，須要保證事務一致性，在一個下游服務失敗後能夠主動感知。

• 兩階段提交：方案過於悲觀，放棄。
• 設計基於輕消息組件，引入事件記錄，保證事件記錄和數據操做在一個DB事務中，基於消息實現事件通知，事務1失敗，進行反向扣減處理（都只是預操做），第二階段進行總體事務commit，方案需引入minibus方案。

結論

基於以上方案重構庫存系統服務，單記錄（子桶）維持在8kqps，摸高到1w+qps，32個子庫壓測達30wQPS性能。