有一個用戶表,欄位分別是, id, username, password ,分別記錄用戶的ID(主鍵),用戶名,和密碼。
我的業務邏輯中,要求用戶名欄位,絕對不能有重復。 否則整個系統就完全亂套了。
我之前的辦法是,控制層中,在插入新用戶之前,先判斷一下這個用戶名,是否已經存在?如果已經存在,就報錯提示給用戶,如果不存在,則執行插入操作。
偽代碼如下:
事務開始
if(xxxDao.isUsernameExist("love")){
return "你輸入的用戶名已被占用,請嘗試其他用戶名,謝謝!";
/** 使用的SQL陳述句為:
select * from user where username = 'love'
*/
}else{
xxxDao.insertUser(user);
return "用戶注冊成功,請回傳登錄頁面登錄!";
/** 使用的SQL陳述句為:
INSERT INTO user(id,username,password) VALUES('xxxx','love','xxxxxxx')
*/
}
事務結束
一開始我自己測驗,這段程式運行的灰常完美,什么問題也沒有!
但是后來,問題,無情的來了。。。
當有多個人,比如100個人,并發訪問的時候,就出現問題了:
這100個同志,同時注冊 "love" 這個用戶名,那么他們首先執行 if(xxxDao.isUsernameExist("love")) 這條陳述句,來判斷user表里,是不是存在 love 這個用戶名,那么他們同時得到的結果,是不存在,可以注冊這個用戶名,然后緊接著開始執行 INSERT INTO...操作了。 后果就是我的user表里,出現了100個用戶名是 love的記錄。。。。
這一下就完蛋了。。
那么我想請教一下各位大神,如果我把以上代碼稍微做下修改,修改成下面這樣:
事務開始
if(xxxDao.isUsernameExist("love")){
return "你輸入的用戶名已被占用,請嘗試其他用戶名,謝謝!";
/** 使用的SQL陳述句為:
select * from user where username = 'love'
*/
}else{
xxxDao.insertUser(user);
return "用戶注冊成功,請回傳登錄頁面登錄!";
/** 使用的SQL陳述句為:
INSERT INTO user(id,username,password) SELECT 'xxxx','love','xxxxxxx' FROM DUAL WHERE NOT EXISTS ( SELECT * FROM user WHERE username = 'love' )
*/
}
事務結束
這樣的話,還會不會存在以上那個并發問題?求大神指點我,盡量的能不用鎖就不去用鎖,能不去修改事務隔離級別,就盡量不修改,除非實在沒辦法了
uj5u.com熱心網友回復:
要做到并發不出問題,必須做到離子級別。只用邏輯代碼無法做到防止并發,所以必須用鎖。這個鎖有個技巧,加“動態的鎖”。用username這個變數來做鎖synchronized(username.intern()){xxxxx},在username后加上intern()方法的呼叫。這樣就可以把相同用戶名并發的列為排隊,不相同的不用排隊。(加在查詢判斷上面)
uj5u.com熱心網友回復:
用存盤程序 或者 行級鎖uj5u.com熱心網友回復:
說的不錯,很好哎
uj5u.com熱心網友回復:
資料庫表設定 username 為 unique 就可以了,重復插入就會插入失敗,只有一個能插入成功uj5u.com熱心網友回復:
#4樓正解,加唯一索引uj5u.com熱心網友回復:
單用程式的邏輯判斷是不夠~ username欄位加唯一約束~ 包括mysql的鎖機制也可以防止并發問題~ 參考:http://blog.csdn.net/speedme/article/details/48525119uj5u.com熱心網友回復:
在isUsernameExist方法中加一個synchronized鎖,可以實作100個人方法但是一個一個通過校驗uj5u.com熱心網友回復:
加唯一約束不是正解,只能保證資料庫不錯亂, 但意味著頁面將顯示注冊成功,資料庫卻沒有對應插入那條資料。uj5u.com熱心網友回復:
不是會有回傳的影響的行數嗎
uj5u.com熱心網友回復:
我覺得加個唯一約束就完全解決了嘛uj5u.com熱心網友回復:
如果加唯一約束,那你干脆就把判斷用戶名重復的邏輯去掉,直接用回傳的int值來判斷好了。
uj5u.com熱心網友回復:
加唯一約束不是正解,只能保證資料庫不錯亂, 但意味著頁面將顯示注冊成功,資料庫卻沒有對應插入那條資料。
不是會有回傳的影響的行數嗎
如果加唯一約束,那你干脆就把判斷用戶名重復的邏輯去掉,直接用回傳的int值來判斷好了。
uj5u.com熱心網友回復:
資料庫表設定 username 為 unique 就可以了,重復插入就會插入失敗,只有一個能插入成功
這個說的準確 。 唯一約束。另外,你的代碼也得改下 ,改成如下代碼,沒必要去else了
if(xxxDao.isUsernameExist("love")){
return "你輸入的用戶名已被占用,請嘗試其他用戶名,謝謝!";
}
xxxDao.insertUser(user);
return "用戶注冊成功,請回傳登錄頁面登錄!";
uj5u.com熱心網友回復:
在isUsernameExist方法中加一個synchronized鎖,可以實作100個人方法但是一個一個通過校驗
至于為什么有資料庫約束還要之前用戶名的判斷的邏輯,個人覺得,主要還是用戶體驗和性能的問題吧,我們在輸入用戶名的時候一般這個用戶名會通過ajax傳送到后臺校驗,而不至于等用戶資訊表單填完提交之后再告訴用戶說用戶名已經存在,表單得重新填。。再者,在第一層面過濾了不合法(用戶名重復)的資訊的insert,不至于insert之后才發現unique了,在一定的程度上減輕了資料庫的負擔吧
uj5u.com熱心網友回復:
欄位加唯一約束完全可以防重,能說之前的系統就這么做過么, tps 300 峰值,外圍也沒做什么防重機制。。。uj5u.com熱心網友回復:
控制層和執行緒里判斷或鎖肯定不行 如果是分布式的 話 執行緒就沒用了 我之前用過是 建一個表 這個標用 O來稱呼吧 然后在服務層里先把該表鎖了 然后再去查有沒有該用戶 有就不給添加 沒有就給 其他人進來的時候 會發現 O的表被鎖了 就會在那里等待 然后等它解鎖了 再進行添加的時候 就會發現該用戶已經被注冊了uj5u.com熱心網友回復:
控制層和執行緒里判斷或鎖肯定不行 如果是分布式的 話 執行緒就沒用了 我之前用過是 建一個表 這個標用 O來稱呼吧 然后在服務層里先把該表鎖了 然后再去查有沒有該用戶 有就不給添加 沒有就給 其他人進來的時候 會發現 O的表被鎖了 就會在那里等待 然后等它解鎖了 再進行添加的時候 就會發現該用戶已經被注冊了
代價有點大~~~
uj5u.com熱心網友回復:
并發的時候,可以設定主鍵自增,或者佇列的方式插入。uj5u.com熱心網友回復:
我想請教一下各位大神,謝謝拜托了uj5u.com熱心網友回復:
資料庫表設定 username 為 unique 就可以了,重復插入就會插入失敗,只有一個能插入成功根據回傳的例外型別來處理就可以啦
uj5u.com熱心網友回復:
+1
加唯一約束不是正解,只能保證資料庫不錯亂, 但意味著頁面將顯示注冊成功,資料庫卻沒有對應插入那條資料。
不是會有回傳的影響的行數嗎
如果加唯一約束,那你干脆就把判斷用戶名重復的邏輯去掉,直接用回傳的int值來判斷好了。
uj5u.com熱心網友回復:
加唯一性約束是個很簡便的方法,但還是要看具體的情況,如果在不改動表的情況下,一般的處理就是加鎖uj5u.com熱心網友回復:
都是高手,但我感徑訓是用唯一標識方便uj5u.com熱心網友回復:
你們沒考慮過資料庫唯一約束是雜實作的么,你在邏輯代碼中用執行緒鎖都會使并發100的執行緒阻塞,資料庫就不會么。你建一個唯一約束當插入資料時一樣會鎖表。不是跟應用中邏輯一樣了么。還降了操作本表更新洗掉的效率uj5u.com熱心網友回復:
可以加索引 也可以鎖表uj5u.com熱心網友回復:
加唯一約束去解決是會鎖表的,性能太低了uj5u.com熱心網友回復:
在資料庫建唯一約束是簡便(lanren)的做法,既然考慮到業務是高并發,為何不妨試試在你的業務邏輯代碼里增加一個快取比如ConcurrentHashMap或者Redis諸如此類 ,獲取請求的傳參跟快取里的value值作比較。 不存在就添加進去 存在就直接回傳重復(每次連接資料庫是要開銷的), 然后在驗證在資料庫中是否重復,不重復插入資料庫 并且移除快取里對應的值。 這樣不會鎖表也不會影響并發吞吐量。 高并發編程肯定要會考慮性能的優化。uj5u.com熱心網友回復:
在資料庫建唯一約束是簡便(lanren)的做法,既然考慮到業務是高并發,為何不妨試試在你的業務邏輯代碼里增加一個快取比如ConcurrentHashMap或者Redis諸如此類 ,獲取請求的傳參跟快取里的value值作比較。 不存在就添加進去 存在就直接回傳重復(每次連接資料庫是要開銷的), 然后在驗證在資料庫中是否重復,不重復插入資料庫 并且移除快取里對應的值。 這樣不會鎖表也不會影響并發吞吐量。 高并發編程肯定要會考慮性能的優化。
這種方式只適用于單服務器的情況,分布式服務器不適用,https://blog.csdn.net/bajianxiaofendui/article/details/104575350
uj5u.com熱心網友回復:
首先,最根本的解決問題的辦法,肯定是在資料庫建唯一索引,可以保證資料的有效性,這個是必須做的;同時,代碼上也可以做優化,比如不要用ORM方法插入資料,用如下陳述句插入,沒有唯一索引也可以保障資料唯一 :
insert into tb1(f1, username)
select 1,'love' from dual
where not exists(select 1 from tb1 where f2='love')
這個語法,SqlServer、MySql、Oracle都支持。
如果一定要用ORM方法,那么唯一索引是最有效的,除非使用分布式鎖,
synchronized鎖只支持單機,多機部署就沒用 了。
uj5u.com熱心網友回復:
uj5u.com熱心網友回復:
樓上都是大神級別。我提個建議:為什么不在注冊的時候用戶輸完用戶名或者修改用戶名的時候直接做判斷,并且直接直觀的給予用戶資訊,該用戶名已經存在
然后也可以同時加唯一,再加上sql校驗。
前端處理掉一些,代碼中邏輯處理一些,sql處理一些,最后又有唯一性保證。客戶體驗感增加10086,程式并發性也會減少10086
uj5u.com熱心網友回復:
三中方案一起加。前段注冊請求之后按鈕置灰。表欄位加唯一索引。后端加分布式鎖,鎖住是否存在服務uj5u.com熱心網友回復:
我推薦直接在注冊的時候,用第三方快取(redis),直接鎖用戶名,然后按你原代碼的邏輯uj5u.com熱心網友回復:
應該把你的鎖放在事務的外面,分布式就用分布式鎖,鎖的時候只鎖對應的用戶名uj5u.com熱心網友回復:
你不用事務管理機制么?轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/123483.html
標籤:Web 開發
上一篇:LintCode刷題
下一篇:求Java題:
