那年還很low（db）
剛開始我們的營銷專案組身單力薄，人微言輕；那時營銷業務才剛開始發展，此時我們把業務放到第一位，技術方案為滿足時間內業務發展所讓步。大家應該可以猜到，這個時候我們很low的庫存扣減方案-直接上資料庫。根據業務訴求，每個活動會儲存乙份實時變化的庫存，參與活動時，實時扣減資料庫，操作步驟如下：
①接收業務扣減庫存請求
②資料庫查詢單個活動庫存，並對查詢的單條資料加鎖（select * from 庫存表 for update）
③驗證庫存是否滿足扣減數量，滿足則扣除
線上遇到了問題(db鎖優化)
可想而知，好景不長，當線上業務逐漸增長，資料庫出現了瓶頸。表現主要是資料庫效能低，大量的資源處於等待鎖的狀態，影響線上業務，影響使用者體驗。當然這裡主要原因還是活動庫存記錄為熱點資料，當收到大量扣減庫存請求時，針對同乙個活動的庫存扣減會因為資料庫行鎖導致大量執行緒等待。
高併發下餘額扣減
當請求a執行是 先加入鎖阻塞 請求b直到 請求a完成之後 請求b才繼續執行 開始事務 begin 消費金額 spend 10 查詢使用者餘額 user select id,fee from users where id 12 for update 計算金額 newfee user fee spend...
mysql餘額高併發 高併發下作餘額扣減的一些經驗
前一段時間參加了優化乙個老的計費系統，學習了一些高併發下做餘額扣減的常用手段，也做了一些嘗試，因此在這裡總結記錄一下。問題描述 對於乙個計費系統來說，併發問題事實上分為兩類，一類是應用併發高，也就是純粹的使用者量大，訪問量多，這類問題和一般的高併發問題沒有區別，用分布式等手段就可以解決 另外一類問題...
高併發下防止庫存超賣的解決方案
最近在看秒殺相關的專案，針對防止庫存超賣的問題，查閱了很多資料，其解決方案可以分為悲觀鎖 樂觀鎖 分布式鎖 redis原子操作 佇列序列化等等，這裡進行淺顯的記錄總結。首先我們來看下庫存超賣問題是怎樣產生的 1 2 3 45 6 1.查詢出商品 庫存資訊 select stock from t go...