前一段時間參加了優化乙個老的計費系統，學習了一些高併發下做餘額扣減的常用手段，也做了一些嘗試，因此在這裡總結記錄一下。
問題描述
對於乙個計費系統來說，併發問題事實上分為兩類，一類是應用併發高，也就是純粹的使用者量大，訪問量多，這類問題和一般的高併發問題沒有區別，用分布式等手段就可以解決；另外一類問題則是一般分布式手段無法解決的使用者高併發問題，也是本文要著重說的。
這類問題源自對某些高頻賬號，大量的併發訪問，會導致瓶頸首先出現在某些資料庫記錄上，大量操作由於無法競爭到資料庫的行鎖而導致等待，這些等待中的操作又會占用其他資源，最終導致系統不可用。
針對這類問題，下邊介紹一些常用的處理辦法。
不設定餘額字段
由於對於乙個穩定的計費來說，一定是會記錄計費流水明細的，所以完全可以不設定餘額字段，而採用根據流水明細計算的方式來獲取餘額。
不過這種方法不是萬能的，比如拿廣告業務的計費系統來說，頻率非常高，而每次的金額很小，這時候想通過計算求和去算餘額，顯然是不現實的。
合併與拆分
這是兩種方式，因為有一些相似之處，都是要降低對單條資料庫記錄的訪問壓力，所以也就放到一起說了。
合併，就是對單個賬號的數次請求作合併處理，再往資料庫寫，這樣就等於降低了數倍的壓力。
拆分，則是把乙個主賬號拆分成數個子賬號，然後把請求分配到各個子賬號上，這樣單個賬號的壓力就小了。然後再用其他手段把子賬號的資料合併成主賬號資料，返回給使用者。
減少行鎖占用時間
<
高併發下餘額扣減
當請求a執行是 先加入鎖阻塞 請求b直到 請求a完成之後 請求b才繼續執行 開始事務 begin 消費金額 spend 10 查詢使用者餘額 user select id,fee from users where id 12 for update 計算金額 newfee user fee spend...
高併發下的MySQL
對於遊戲來說，db存在大量的insert update 可謂玩家的很多動作都會與db溝通。本文暫時忽略os 中的 io利用率，網絡卡流量，cpu變化情況，介紹如何檢視mysql部分引數 檢視每秒事務數 show global status like com commit show global st...
高併發下搶購
了解高併發以及怎麼處理後，測試一下專案中下單的 邏輯很簡單，goods表中stock設定為unsigned。剛開始你可能會覺得這樣會出現超單的情況，但是測試後，沒有出現超單的情況。看似沒有問題，但是看過日誌發現問題還挺多的。這之前請看下這篇文章裡面有處理高併發下單的情況。goods id num g...