java高并發(fā)寫入用戶信息到數(shù)據(jù)庫(kù)的幾種方法
假定存在這樣一種情況
多個(gè)用戶對(duì)數(shù)據(jù)庫(kù)進(jìn)行寫,我們的業(yè)務(wù)邏輯規(guī)定,每個(gè)用戶只能寫一次,大部分用戶也只發(fā)一次請(qǐng)求。
public void write(Uers u){
// do something
}
但是有一種情況(1%的情況下吧)的就是有的用戶會(huì)發(fā)兩次甚至更多次寫請(qǐng)求(因?yàn)閿?shù)據(jù)庫(kù)限制,我們不方便在主鍵上做文章)。
如果這個(gè)特殊的用戶發(fā)送的兩次請(qǐng)求時(shí)間間隔比較大,那就簡(jiǎn)單了,再每次寫入的時(shí)候,寫去數(shù)據(jù)庫(kù)里看看,這個(gè)人有沒有寫過,如果已經(jīng)寫過了,就直接拋棄這個(gè)請(qǐng)求。
public void write(Uers u){
if(!checkIfExistUser(u)){
// do something
}
}
不過最大的問題就是,如果用戶幾乎在瞬時(shí),發(fā)送了兩個(gè)寫操作。
而且假定我們的do something比較耗時(shí),那么上面的策略就有可能失敗。
為啥失敗?我不用解釋了吧。
那咋辦?
方法一
萬(wàn)年不變的synchronized。
public synchronized void write(Uers u){
if(!checkIfExistUser(u)){
// do something
}
}
當(dāng)然,我們得承認(rèn),有了上面的方法,就不會(huì)出現(xiàn),數(shù)據(jù)庫(kù)里有兩條張三的記錄了
但上面的鎖的粒度太大了,張三寫的時(shí)候,李四也不能寫了。
其實(shí)我們想要的只是:張三自己本人,不能同時(shí)多次寫入。
方法二
類 String 維護(hù)一個(gè)字符串池。 當(dāng)調(diào)用 intern 方法時(shí),如果池已經(jīng)包含一個(gè)等于此 String 對(duì)象的字符串(該對(duì)象由 equals(Object) 方法確定),則返回池中的字符串??梢姡?dāng)String相同時(shí),String.intern()總是返回同一個(gè)對(duì)象,因此就實(shí)現(xiàn)了對(duì)同一用戶加鎖。由于鎖的粒度局限于具體用戶,使系統(tǒng)獲得了最大程度的并發(fā)。
public synchronized void write(Uers u){
synchronized(u.getUserId.intern()) {
// do something
}
}
上面的思路就保證了張三寫的時(shí)候,李四可以寫,但是不能兩個(gè)張三一塊寫。
方法三
其實(shí)我個(gè)人覺得,方法二已經(jīng)很好了,如果非要說方法二還有什么問題的話,只能說:
String.inter()的缺陷是類 String 維護(hù)一個(gè)字符串池是放在JVM perm區(qū)的,如果用戶數(shù)特別多,導(dǎo)致放入字符串池的String不可控,有可能導(dǎo)致OOM錯(cuò)誤或者過多的Full GC。
那咋辦?
public synchronized void write(Uers u){
String userSuffix=getSuffix(u);
synchronized(userSuffix.intern()) {
// do something
}
}
至于那個(gè)獲得后綴的策略,大家自己想。
有了這個(gè)策略,我就能保證1億個(gè)用戶,可能只有10000個(gè)不同的后綴。
有可能張三李四的后綴一樣,但是張三李四同時(shí)發(fā)請(qǐng)求的概率,應(yīng)該也不會(huì)太大。就算真的同時(shí)發(fā)了,那你等一下不行么?
方法四
Map locks = new Map();
List lockKeys = new List();
for(int number : 1 - 10000) {
Object lockKey = new Object();
lockKeys.add(lockKey);
locks.put(lockKey, new Object());
}
public void doSomeThing(String uid) {
Object lockKey = lockKeys.get(uid.hash() % lockKeys.size());
Object lock = locks.get(lockKey);
synchronized(lock) {
// do something
}
}
個(gè)人感覺和方法三的核心差不多。
方法五
如果是集群情況下,兩個(gè)張三幾乎瞬時(shí)進(jìn)入兩臺(tái)服務(wù)器,那java語(yǔ)言級(jí)別的鎖都得報(bào)廢。
可以使用redis的分布式鎖
方法六
使用zookeeper
只是聽說有這么一個(gè)思路,但是本人沒用過zookeeper,這個(gè)方法就不多說了。
以上就是本文的全部?jī)?nèi)容,希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作能帶來一定的幫助,同時(shí)也希望多多支持腳本之家!
- 深入了解java NIO之Selector(選擇器)
- Java NIO Selector用法詳解【含多人聊天室實(shí)例】
- JAVA代碼設(shè)置selector不同狀態(tài)下的背景顏色
- java的多線程高并發(fā)詳解
- 詳解java解決分布式環(huán)境中高并發(fā)環(huán)境下數(shù)據(jù)插入重復(fù)問題
- java web在高并發(fā)和分布式下實(shí)現(xiàn)訂單號(hào)生成唯一的解決方案
- java高并發(fā)鎖的3種實(shí)現(xiàn)示例代碼
- java web如何解決瞬間高并發(fā)
- Java 高并發(fā)九:鎖的優(yōu)化和注意事項(xiàng)詳解
- Java進(jìn)階之高并發(fā)核心Selector詳解
相關(guān)文章
JavaWeb開發(fā)之Spring+SpringMVC+MyBatis+SpringSecurity+EhCache+JC
這篇文章主要介紹了JavaWeb開發(fā)之Spring+SpringMVC+MyBatis+SpringSecurity+EhCache+JCaptcha 完整Web基礎(chǔ)框架的相關(guān)資料,需要的朋友可以參考下2016-12-12
搜索一文入門ElasticSearch(節(jié)點(diǎn) 分片 CRUD 倒排索引 分詞)
這篇文章主要為大家介紹了搜索一文入門ElasticSearch(節(jié)點(diǎn) 分片 CRUD 倒排索引 分詞)的基礎(chǔ)詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-03-03
@PathVariable、@RequestParam和@RequestBody的區(qū)別
本文主要介紹了@PathVariable、@RequestParam和@RequestBody的區(qū)別和使用,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-05-05
解決Feign切換client到okhttp無法生效的坑(出現(xiàn)原因說明)
這篇文章主要介紹了解決Feign切換client到okhttp無法生效的坑(出現(xiàn)原因說明),具有很好的參考價(jià)值,希望對(duì)大家有所幫助。一起跟隨小編過來看看吧2021-02-02
Spring Security角色繼承實(shí)現(xiàn)過程解析
這篇文章主要介紹了Spring Security角色繼承實(shí)現(xiàn)過程解析,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2020-08-08
Java實(shí)用工具之使用oshi獲取主機(jī)信息的方法
這篇文章主要介紹了Java實(shí)用工具之使用oshi獲取主機(jī)信息的方法,本文給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2021-02-02

