高并發扣款,如何保證結果一致性
在金融系統中,我們會跟錢打交道,而保證在高并發下場景下,對賬戶余額操作的一致性,是非常重要的,如果代碼寫的時候沒考慮并發一致性,就會導致資損,本人在金融行業干了 8 年多,對這塊稍微有點經驗,所以這篇聊一下,如何在并發場景下,保證賬戶余額的一致性
1. 扣款流程是什么樣的?
圖片
public void payout(long uid,var payAmount){
# 查詢賬戶總額
var amount= "SELECT amount FROM account WHERE uid=$uid";
# 計算賬戶余額
var balanceAmount = amount-payAmount;
if(balanceAmount<0) throw 異常
#更新余額
update account set amount=balanceAmount where uid=$uid;
}
以上流程如果并發量非常低的情況下是沒問題的,但是如果在高并發下是很容易出現問題。
2. 在高并發下會出現什么問題?
- 訂單a和訂單 b同一時間都查詢到了,賬戶余額為1000
圖片
- 訂單a扣款200,訂單b扣款 100,都滿足1000-減去扣款金額大于0
圖片
- 執行扣款,訂單 a修改賬戶余額為800,訂單 b 修改為賬戶余額為900
圖片
此時就出現問題了,如果訂單 a 先執行更新,訂單 b后執行,那么賬戶余額最終為900,反之為 800,都不正確,正確余額應該是700,那怎么處理呢?
3. 并發扣款怎么處理?
a. 使用悲觀鎖
在執行扣款時使用redis、zk或者數據庫的for update對賬戶數據進行行級鎖,使執行并發操作串型化操作,這里推薦使用for update操作,因為引用redis、zk還要考慮他們的異常情況,數據庫最簡單,也是目前的常規做法,本人曾經參與幾大銀行項目也是這種方式。
- 查詢余額,在查詢語句上加上for update,但是一定要注意where 條件是唯一索引,否則會導致多行數據被鎖,同時必須要開始事務,否則for update沒效果,使用分布式數據庫中間件還要注意,for update可能會路由到讀節點上。偽代碼:
public void payout(long uid,var payAmount){
try{
begin 事務
# 查詢賬戶總額
var amount= "SELECT amount FROM account WHERE uid=$uid for update";
# 計算賬戶余額
var balanceAmount = amount - payAmount;
if(balanceAmount<0) throw 異常
#更新余額
update account set amount=balanceAmount where uid=$uid;
}catch(Exception e){
rollback 事務;
拋出異常;
}
commit 事務
}
b. 使用樂觀鎖(CAS)
樂觀鎖的方式也就是是CAS的方式,適合并發量不高情況,如果并發量高大概率都失敗在重試,開銷也不比悲觀鎖小,
注意這也是面試題:CAS 適合在使用場景下使用?
1. 增加版本號方式
- 在賬戶表增加樂觀鎖版本號
account(uid,amout,version)
- 查詢余額時,同時查詢版本號。
SELECT amount,version FROM account WHERE uid=$uid
- 每次更新余額時,必須版本號相等,并且版本號每次要修改。
update account set amount=余額,version=newVersion where uid=$uid and version=$oldVersion
2. 使用原有金額值比對更新
在執行賬戶余額更新時,where 條件中增加第一次查出來的賬戶余額,即初始余額,如果在執行更新時,初始余額沒變則更新成功,否則肯定是更新了,同時數據庫也會返回受影響的行數,來判斷是否更新成功,如果沒成功就再次重試。
update account set amount=余額 where uid=$uid and amount=$oldAmount
以下是偽代碼,遇到失敗回滾事務并拋出異常,上層調用方法要考慮捕獲異常在進行重試
public void payout(long uid,var payAmount){
try{
begin 事務
# 查詢賬戶總額
var amount= "SELECT amount FROM account WHERE uid=$uid for update";
# 計算賬戶余額
var balanceAmount = amount- payAmount;
if(balanceAmount<0) throw 異常
#更新余額
int count=update account set amount=$balanceAmount where uid=$uid and amount=$amount;
###注意如果更新成功返回count為1
if(count<1){
拋出異常重試;
}
}catch(Exception e){
rollback 事務;
拋出異常;
}
commit 事務
}
具體到以上示例
訂單a 執行
update account set amount=800 where uid=$uid and amount=1000;
訂單b 執行
update account set amount=900 where uid=$uid and amount=1000;
以上兩筆執行只有一筆能成功,因為amount 變了。
4. 使用樂觀鎖會不會存在aba 的問題
什么是 aba?
線程 1:獲取出數據的初始值是a,如果數據仍是a的時候,修改才能成功
線程 2:將數據修改成b
線程 3:將數據修改成 a
線程 1:執行cas,發現數據還是 a,進行數據修改
上述場景,線程1在修改數據時,雖然還是a,但已經不是初始條件的a了,中間發生了a變b,b又變a,此 a 非彼 a,但是成功修改了,在有些場景下會有問題,這就是 aba
但是以上場景,對賬戶扣款不會出現問題,因為余額 1000 就是 1000,是相同的,舉個例子,
訂單a:獲取出賬戶余額為 1000,期望余額是 1000的時候,才能修改成功。
訂單b:取了 100,將余額修改成了900。
訂單c:存進去了100,將余額修改成了 1000。
訂單 a:檢查賬戶余額為1000,進行扣款200,賬戶余額變成了800。
以上場景賬戶資金損失嗎沒有吧,不過為了避免產生誤解,推薦還是使用版本號的方式!
5. 總結
以上我們講了在高并發場景在如何保證結果一致性方式,在并發量高情況下推薦使用悲觀鎖的方式,如果并發量不高可以考慮使用樂觀鎖,推薦使用版本號方式。同時樂觀鎖場景要注意 aba 的問題。