在開發(fā)中遇到過這樣一個問題

一個看視頻記錄,更新到100就表示看完了,后面再有請求不繼續(xù)更新了.

結(jié)果是:

導(dǎo)致,里面很多數(shù)據(jù)出現(xiàn)問題.

推測是以下的情況才會導(dǎo)致

第一條請求 事務(wù)在執(zhí)行中,還未提交(因為本地有時候比較難再現(xiàn),于是手動在程序中,第一條記錄處理的時候,sleep了幾秒,就達到這種效果了)

第二條請求 事務(wù)已經(jīng)開始執(zhí)行,這個時候查到的歷史最大值不是100,才會去進行了更新

網(wǎng)上看了一下解決方案:

悲觀鎖

直接鎖行記錄

這個我在本地測試,確實有效,一個事務(wù)開始沒結(jié)束,第二個事務(wù)一個等待,不過會導(dǎo)致處于阻塞狀態(tài),因為系統(tǒng)并發(fā),不敢考慮,也就是記錄下這個方式.

手動模擬:

執(zhí)行第一個事務(wù):

-- 視頻100BEGIN;SELECT * FROM `biz_coursestudyhistory` WHERE sid = 5777166;UPDATE biz_coursestudyhistory set studyStatus = 100,versionNO=versionNO+1 WHERE sid = 1 AND versionNO = 0;-- commit ; 先不執(zhí)行,先注解掉,只執(zhí)行上面的

接著執(zhí)行第二個事務(wù):

BEGIN; UPDATE biz_coursestudyhistory set studyStatus = 90,versionNO=versionNO+1 WHERE sid = 1 AND versionNO = 0; SELECT * FROM `biz_coursestudyhistory` WHERE sid = 1 FOR UPDATE; COMMIT;

會發(fā)現(xiàn)成功不了,一直處于等待狀態(tài).

查看鎖

確實被鎖住了,這里只要執(zhí)行第一個事務(wù)的commit ,第二個事務(wù)就會執(zhí)行.

從這里可以看出,行鎖可以直接達到理想的數(shù)據(jù)統(tǒng)一狀態(tài),一個事務(wù)修改,其他都不能操作,感覺這種比較適合銀行這種安全性的項目

樂觀鎖:

這種比較簡單,并且不會造成阻塞

方式就是加上版本號

var maxver = select max(version) from table

更新的話使用

update table set studystatus = xxx,version = version +1 where id =1 and version = maxver

寫入的話

INSERT into table (contentStudyID,courseWareID,studyStatus,studyTime,endTime)SELECT 27047358,3163,100,333,NOW() FROM dual WHERE NOT EXISTS (SELECT 1 FROM table WHERE contentStudyID =27047358 ANDcourseWareID = 3163 )

這種方式,可以在更新或者寫入的時候,直接判斷庫里面存在的數(shù)據(jù)是否存在,如果不存在則是別其他的線程使用了.

修改為這種寫法后,使用jmeter進行多線程測試,從最開始的多條記錄更新成功,變成只有一個成功,后面的失敗.

從最開始的插入多條記錄,到后來的只能插入一條數(shù)據(jù)了

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持好吧啦網(wǎng)。