當請求a執行是 先加入鎖阻塞 請求b直到 請求a完成之後 請求b才繼續執行
//開始事務
begin;
//消費金額
$spend = 10;
//查詢使用者餘額
$user = select id,fee from users where id = 12 for update;
//計算金額
$newfee = $user['fee'] - $spend;
//...檢查餘額是否足夠
//更新餘額
update users set fee = $newfee where id = 12;
//確認成功之後，提交事務
commit
在更新的時候使用初始值（即查詢出來的當前餘額）作為條件compare限制只有初始值沒有改變時才允許更新成功set
compare and set（cas）
//消費金額
$spend = 10;
//查詢使用者餘額
$user = select id,fee from users where id =12;
$oldfee = $user['fee'];
//計算金額
$newfee = $user['fee'] - $spend;
//...檢查餘額是否足夠
//更新餘額
update users set fee = $newfee where id = 12 and fee = $oldfee ;
update users set fee = fee - $spend where id = 12;
這裡要再加上餘額的判斷避免出現負數金額
update users set fee = fee - $spend where id = 12 and fee >= $spend;
稍微改一下這裡的更新 語句 也能完成正確的更新 就算是併發也將正常
但是這樣做將產生乙個問題 不冪等？
什麼是不冪等？
在相同的條件下，執行同一請求，得到的結果相同才符合冪等性
也就是說
fee = fee - $spend 不冪等
fee = $newfee 冪等
不冪等的情況下 如果發生重複執行的額情況將產生重複扣款
mysql餘額高併發 高併發下作餘額扣減的一些經驗
前一段時間參加了優化乙個老的計費系統，學習了一些高併發下做餘額扣減的常用手段，也做了一些嘗試，因此在這裡總結記錄一下。問題描述 對於乙個計費系統來說，併發問題事實上分為兩類，一類是應用併發高，也就是純粹的使用者量大，訪問量多，這類問題和一般的高併發問題沒有區別，用分布式等手段就可以解決 另外一類問題...
高併發下的庫存扣減方案
那年還很low db 剛開始我們的營銷專案組身單力薄，人微言輕 那時營銷業務才剛開始發展，此時我們把業務放到第一位，技術方案為滿足時間內業務發展所讓步。大家應該可以猜到，這個時候我們很low的庫存扣減方案 直接上資料庫。根據業務訴求，每個活動會儲存乙份實時變化的庫存，參與活動時，實時扣減資料庫，操作...
高併發下搶購
了解高併發以及怎麼處理後，測試一下專案中下單的 邏輯很簡單，goods表中stock設定為unsigned。剛開始你可能會覺得這樣會出現超單的情況，但是測試後，沒有出現超單的情況。看似沒有問題，但是看過日誌發現問題還挺多的。這之前請看下這篇文章裡面有處理高併發下單的情況。goods id num g...