自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

數(shù)據(jù)庫update時(shí)這樣干,你就悲劇了

運(yùn)維 數(shù)據(jù)庫運(yùn)維
數(shù)據(jù)庫update時(shí)切忌這樣干,這樣干是什么?請(qǐng)隨我來看看。

數(shù)據(jù)庫update時(shí)切忌這樣干,這樣干是什么?請(qǐng)隨我來看看。

早些時(shí)候,客戶發(fā)來這樣一段文字“XX的,XXXXXXXX有個(gè)10萬沒到賬,幫加上去。”我馬上動(dòng)手查看數(shù)據(jù)庫,尋找原因,隨后回復(fù)了這樣一句話“開玩笑吧”。雖然之前發(fā)生過類似這樣的問題,但都是小額資金,就手動(dòng)在數(shù)據(jù)庫里加了,遇到這么大的資金還是頭一次,于是我加緊翻看數(shù)據(jù)庫記錄的節(jié)奏。

我發(fā)現(xiàn)用戶的入金記錄的確已經(jīng)是審核通過狀態(tài),而用戶的可用資金卻沒有加上,這已經(jīng)讓人意外了。

接著我查看代碼,并沒有發(fā)現(xiàn)邏輯上的問題,這又讓我感到迷茫。

再翻看日志,發(fā)現(xiàn)沒有任何異常,好吧,感覺被設(shè)了局一樣。

回頭想想,這種情況并不多見,程序在多數(shù)情況下并沒有這種情況,一切正常。這糟了,沒有錯(cuò)誤日志就是***的錯(cuò)誤。

 

[[135474]]

靜下心來,我想有可能是事務(wù)出現(xiàn)的問題,因?yàn)閷?duì)于資金表,同一個(gè)用戶的資金在同一個(gè)時(shí)間點(diǎn)是可能同時(shí)被更新的,我猜想,是入金記錄先插入了出入金記錄表,等到更新資金表的時(shí)候被鎖住,事務(wù)超時(shí)后插入的記錄沒有回滾,于是我通過這樣的方式來證明一下。

  1. START TRANSACTION
  2. INSERT INTO record VALUES(1,123); 
  3. UPDATE money SET money = money + 10; 
  4. COMMIT
  5.  
  6. START TRANSACTION
  7. UPDATE money SET money = money + 100; 
  8. COMMIT

通過手動(dòng)控制事務(wù)鎖,發(fā)現(xiàn)不是我想的那樣。然后我又試了試下面這種方式:

 

  1. START TRANSACTION
  2. UPDATE money SET money = money + 10; 
  3. INSERT INTO record VALUES(1,123); 
  4. COMMIT
  5.  
  6. START TRANSACTION
  7. UPDATE money SET money = money + 100; 
  8. COMMIT

發(fā)現(xiàn)兩者的效果是一樣的,事務(wù)都會(huì)回滾。

這個(gè)時(shí)候,我的思路被禁錮了,我和同事討論起來,看看他有什么想法,經(jīng)過一番思想斗爭后,果然同事還是給出了他的想法,我深感贊同。

 

  1. MoneyUser moneyUser = moneyUserMapper.selectByPrimaryKey(members.getUid()); 
  2.    // 凍結(jié)資金-出金金額 
  3.    moneyUser.setFrozenl(moneyUser.getFrozen().subtract(moneyTransfer.getount())); 
  4.    // 可用資金+出金金額 
  5.    moneyUser.setTotaaymoney(moneyUser.getTotalpayey().add(moneyTransfer.getount())); 
  6. this.moneyUserMapper.updateByPrimaryKey(moneyUser); 

這樣的代碼在出現(xiàn)并發(fā)的時(shí)候,獲取moneyUser對(duì)象的時(shí)候,其中的凍結(jié)資金和可用資金加入都是0,那么兩個(gè)并發(fā)在update的時(shí)候,兩個(gè)都執(zhí)行了,但是起初的凍結(jié)資金和可用資金相同,就會(huì)導(dǎo)致有一筆資金沒有加上。

調(diào)試的時(shí)候更容易發(fā)現(xiàn)這個(gè)問題。OH,my 噶,真是個(gè)大問題,還出在資金的問題時(shí),我真慶幸這個(gè)問題發(fā)生的頻率不夠高。不過我到底是應(yīng)該慶幸還是不慶幸呢,也許次數(shù)發(fā)生的多起來的時(shí)候,我就更容易來反思來找出問題的癥結(jié)所在。

那么問題怎么解決呢?

 

  1. UPDATE moneser 
  2.   SET 
  3.   frozapital = frozpital - #{amount,jdbcType=DECIMAL}, 
  4.   totaloney = totaloney + #{amount,jdbcType=DECIMAL
  5.   WHERE uid = #{uid,jdbcType=INTEGER

通過在sql語句中進(jìn)行字段的更新操作,而不是在Java類中,因?yàn)閙ysql本身是會(huì)有這方面的處理方式的。

這個(gè)問題,之前領(lǐng)導(dǎo)有建議我在update數(shù)據(jù)的時(shí)候盡量在sql語句中加入,而不是類字段中做處理。

總結(jié):這個(gè)問題,如果你不經(jīng)意的話,很容易發(fā)生這個(gè)問題,我當(dāng)初就沒有這樣的意識(shí),真是可悲可嘆!

博文出處:http://blog.csdn.net/qing_gee/article/details/46233301
 

責(zé)任編輯:Ophira 來源: CSDN博客
相關(guān)推薦

2017-07-10 16:19:36

IT發(fā)財(cái)離婚

2021-10-18 09:09:16

數(shù)據(jù)庫

2020-10-24 14:05:34

CEO互聯(lián)網(wǎng)開發(fā)者

2020-06-17 21:22:56

Serverless面試官架構(gòu)

2020-08-06 11:25:29

數(shù)據(jù)庫鏈接池線程

2018-09-28 09:32:57

2021-09-15 06:21:36

Update語句數(shù)據(jù)庫

2021-01-06 10:52:02

MySQL數(shù)據(jù)庫安全

2025-02-08 12:05:44

MySQLMyISAMInnoDB

2022-09-15 08:41:16

數(shù)據(jù)異構(gòu)分庫分表

2011-06-30 15:26:28

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

2020-04-21 23:14:08

數(shù)據(jù)并發(fā)控制

2019-08-16 08:50:52

代碼日志程序員

2020-08-14 07:42:33

數(shù)據(jù)庫加密脫庫

2021-07-14 15:06:50

SDK版本 jar

2010-10-28 10:30:16

云計(jì)算關(guān)系數(shù)據(jù)庫

2022-12-06 08:45:33

數(shù)據(jù)庫OS產(chǎn)品

2021-07-29 09:47:06

IDEA 項(xiàng)目maven

2020-03-12 10:33:40

運(yùn)維架構(gòu)技術(shù)
點(diǎn)贊
收藏

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