偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

高并發(fā)扣款,如何保證結(jié)果一致性

開發(fā) 前端
以上我們講了在高并發(fā)場景在如何保證結(jié)果一致性方式,在并發(fā)量高情況下推薦使用悲觀鎖的方式,如果并發(fā)量不高可以考慮使用樂觀鎖,推薦使用版本號方式。同時樂觀鎖場景要注意 aba 的問題。

在金融系統(tǒng)中,我們會跟錢打交道,而保證在高并發(fā)下場景下,對賬戶余額操作的一致性,是非常重要的,如果代碼寫的時候沒考慮并發(fā)一致性,就會導(dǎo)致資損,本人在金融行業(yè)干了 8 年多,對這塊稍微有點經(jīng)驗,所以這篇聊一下,如何在并發(fā)場景下,保證賬戶余額的一致性

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;   
}

以上流程如果并發(fā)量非常低的情況下是沒問題的,但是如果在高并發(fā)下是很容易出現(xiàn)問題。

2. 在高并發(fā)下會出現(xiàn)什么問題?

  1. 訂單a和訂單 b同一時間都查詢到了,賬戶余額為1000

圖片圖片

  1. 訂單a扣款200,訂單b扣款 100,都滿足1000-減去扣款金額大于0

圖片圖片

  1. 執(zhí)行扣款,訂單 a修改賬戶余額為800,訂單 b 修改為賬戶余額為900

圖片圖片

此時就出現(xiàn)問題了,如果訂單 a 先執(zhí)行更新,訂單 b后執(zhí)行,那么賬戶余額最終為900,反之為 800,都不正確,正確余額應(yīng)該是700,那怎么處理呢?

3. 并發(fā)扣款怎么處理?

a. 使用悲觀鎖

在執(zhí)行扣款時使用redis、zk或者數(shù)據(jù)庫的for update對賬戶數(shù)據(jù)進行行級鎖,使執(zhí)行并發(fā)操作串型化操作,這里推薦使用for update操作,因為引用redis、zk還要考慮他們的異常情況,數(shù)據(jù)庫最簡單,也是目前的常規(guī)做法,本人曾經(jīng)參與幾大銀行項目也是這種方式。

  1. 查詢余額,在查詢語句上加上for update,但是一定要注意where 條件是唯一索引,否則會導(dǎo)致多行數(shù)據(jù)被鎖,同時必須要開始事務(wù),否則for update沒效果,使用分布式數(shù)據(jù)庫中間件還要注意,for update可能會路由到讀節(jié)點上。偽代碼:
public  void payout(long uid,var payAmount){
   try{
    begin 事務(wù)
      # 查詢賬戶總額
      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 事務(wù);
      拋出異常; 
   }  
  commit 事務(wù)     
}

b. 使用樂觀鎖(CAS)

樂觀鎖的方式也就是是CAS的方式,適合并發(fā)量不高情況,如果并發(fā)量高大概率都失敗在重試,開銷也不比悲觀鎖小,

注意這也是面試題:CAS 適合在使用場景下使用?

1. 增加版本號方式
  1. 在賬戶表增加樂觀鎖版本號
account(uid,amout,version)
  1. 查詢余額時,同時查詢版本號。
SELECT amount,version FROM account WHERE uid=$uid
  1. 每次更新余額時,必須版本號相等,并且版本號每次要修改。
update account set amount=余額,version=newVersion where uid=$uid and version=$oldVersion
2. 使用原有金額值比對更新

在執(zhí)行賬戶余額更新時,where 條件中增加第一次查出來的賬戶余額,即初始余額,如果在執(zhí)行更新時,初始余額沒變則更新成功,否則肯定是更新了,同時數(shù)據(jù)庫也會返回受影響的行數(shù),來判斷是否更新成功,如果沒成功就再次重試。

update account set amount=余額  where uid=$uid and amount=$oldAmount

以下是偽代碼,遇到失敗回滾事務(wù)并拋出異常,上層調(diào)用方法要考慮捕獲異常在進行重試

public void payout(long uid,var payAmount){
     try{
      
      begin 事務(wù)
        # 查詢賬戶總額
        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 事務(wù);
           拋出異常; 
    }
   commit 事務(wù)     
  
}

具體到以上示例

訂單a 執(zhí)行

update account set amount=800 where uid=$uid and amount=1000;

訂單b 執(zhí)行

update account set amount=900 where uid=$uid and amount=1000;

以上兩筆執(zhí)行只有一筆能成功,因為amount 變了。

4. 使用樂觀鎖會不會存在aba 的問題

什么是 aba?

線程 1:獲取出數(shù)據(jù)的初始值是a,如果數(shù)據(jù)仍是a的時候,修改才能成功

線程 2:將數(shù)據(jù)修改成b

線程 3:將數(shù)據(jù)修改成 a

線程 1:執(zhí)行cas,發(fā)現(xiàn)數(shù)據(jù)還是 a,進行數(shù)據(jù)修改

上述場景,線程1在修改數(shù)據(jù)時,雖然還是a,但已經(jīng)不是初始條件的a了,中間發(fā)生了a變b,b又變a,此 a 非彼 a,但是成功修改了,在有些場景下會有問題,這就是 aba

但是以上場景,對賬戶扣款不會出現(xiàn)問題,因為余額 1000 就是 1000,是相同的,舉個例子,

訂單a:獲取出賬戶余額為 1000,期望余額是 1000的時候,才能修改成功。

訂單b:取了 100,將余額修改成了900。

訂單c:存進去了100,將余額修改成了 1000。

訂單 a:檢查賬戶余額為1000,進行扣款200,賬戶余額變成了800。

以上場景賬戶資金損失嗎沒有吧,不過為了避免產(chǎn)生誤解,推薦還是使用版本號的方式!

5. 總結(jié)

以上我們講了在高并發(fā)場景在如何保證結(jié)果一致性方式,在并發(fā)量高情況下推薦使用悲觀鎖的方式,如果并發(fā)量不高可以考慮使用樂觀鎖,推薦使用版本號方式。同時樂觀鎖場景要注意 aba 的問題。

責任編輯:武曉燕 來源: 架構(gòu)成長指南
相關(guān)推薦

2022-10-19 12:22:53

并發(fā)扣款一致性

2019-08-30 12:46:10

并發(fā)扣款查詢SQL

2024-12-26 15:01:29

2020-08-05 08:46:10

NFS網(wǎng)絡(luò)文件系統(tǒng)

2025-03-27 08:20:54

2023-09-07 08:11:24

Redis管道機制

2019-09-08 22:45:48

并發(fā)扣款一致性冪等性

2021-03-04 06:49:53

RocketMQ事務(wù)

2020-06-01 22:09:48

緩存緩存同步緩存誤用

2024-08-20 16:13:52

2023-05-26 07:34:50

RedisMySQL緩存

2023-12-11 12:27:31

并發(fā)Zookeeper數(shù)據(jù)

2019-09-05 08:54:38

一致性CASABA

2021-07-21 15:50:42

Serverless 業(yè)務(wù)部署

2021-12-14 07:15:57

MySQLRedis數(shù)據(jù)

2019-10-16 00:06:08

CPU內(nèi)存存儲

2020-04-01 15:50:17

TiDBMySQL數(shù)據(jù)庫

2024-01-22 08:52:00

AQS雙異步數(shù)據(jù)一致性

2024-10-28 12:41:25

2024-01-15 10:38:20

多級緩存數(shù)據(jù)一致性分布式緩存
點贊
收藏

51CTO技術(shù)棧公眾號