對于我們開發(fā)的網(wǎng)站僻造,如果網(wǎng)站的訪問量非常大的話,那么我們就需要考慮相關(guān)的并發(fā)訪問問題了孩饼。而并發(fā)問題是絕大部分的程序員頭疼的問題髓削,
但話又說回來了,既然逃避不掉镀娶,那我們就坦然面對吧~今天就讓我們一起來研究一下常見的并發(fā)和同步吧立膛。
為了更好的理解并發(fā)和同步,我們需要先明白兩個重要的概念:同步和異步
1梯码、同步和異步的區(qū)別和聯(lián)系
所謂同步宝泵,可以理解為在執(zhí)行完一個函數(shù)或方法之后,一直等待系統(tǒng)返回值或消息轩娶,這時程序是出于阻塞的儿奶,只有接收到
返回的值或消息后才往下執(zhí)行其它的命令。
異步鳄抒,執(zhí)行完函數(shù)或方法后廓握,不必阻塞性地等待返回值或消息,只需要向系統(tǒng)委托一個異步過程嘁酿,那么當(dāng)系統(tǒng)接收到返回
值或消息時隙券,系統(tǒng)會自動觸發(fā)委托的異步過程,從而完成一個完整的流程闹司。
同步在一定程度上可以看做是單線程娱仔,這個線程請求一個方法后就待這個方法給他回復(fù),否則他不往下執(zhí)行(死心眼)游桩。
異步在一定程度上可以看做是多線程的(廢話牲迫,一個線程怎么叫異步)耐朴,請求一個方法后,就不管了盹憎,繼續(xù)執(zhí)行其他的方法筛峭。
同步就是一件事,一件事情一件事的做陪每。
異步就是影晓,做一件事情,不引響做其他事情檩禾。
例如:吃飯和說話挂签,只能一件事一件事的來,因?yàn)橹挥幸粡堊臁?/p>
但吃飯和聽音樂是異步的盼产,因?yàn)槎牛犚魳凡⒉灰懳覀兂燥垺?/p>
對于Java程序員而言,我們會經(jīng)常聽到同步關(guān)鍵字synchronized戏售,假如這個同步的監(jiān)視對象是類的話侨核,那么如果當(dāng)一個對象
訪問類里面的同步方法的話,那么其它的對象如果想要繼續(xù)訪問類里面的這個同步方法的話灌灾,就會進(jìn)入阻塞芹关,只有等前一個對象
執(zhí)行完該同步方法后當(dāng)前對象才能夠繼續(xù)執(zhí)行該方法。這就是同步紧卒。相反侥衬,如果方法前沒有同步關(guān)鍵字修飾的話,那么不同的對象
可以在同一時間訪問同一個方法跑芳,這就是異步轴总。
在補(bǔ)充一下(臟數(shù)據(jù)和不可重復(fù)讀的相關(guān)概念):
臟數(shù)據(jù)
臟讀就是指當(dāng)一個事務(wù)正在訪問數(shù)據(jù),并且對數(shù)據(jù)進(jìn)行了修改博个,而這種修改還沒有提交到數(shù)據(jù)庫中怀樟,這時,另外一個事務(wù)也訪問這個數(shù)據(jù)盆佣,然后使用了這
個數(shù)據(jù)往堡。因?yàn)檫@個數(shù)據(jù)是還沒有提交的數(shù)據(jù),那么另外一個事務(wù)讀到的這個數(shù)據(jù)是臟數(shù)據(jù)(Dirty Data),依據(jù)臟數(shù)據(jù)所做的操作可能是不正確的。
不可重復(fù)讀
不可重復(fù)讀是指在一個事務(wù)內(nèi)跛十,多次讀同一數(shù)據(jù)扶平。在這個事務(wù)還沒有結(jié)束時奔害,另外一個事務(wù)也訪問該同一數(shù)據(jù)。那么,在第一個事務(wù)中的兩次讀數(shù)據(jù)之間然想,由于第二個事務(wù)的修改对湃,那么第一個事務(wù)兩次讀到的數(shù)據(jù)可能是不一樣的崖叫。這樣就發(fā)生了在一個事務(wù)內(nèi)兩次讀到的數(shù)據(jù)是不一樣的,因此稱為是不可重復(fù)讀
2拍柒、如何處理并發(fā)和同步
今天講的如何處理并發(fā)和同同步問題主要是通過鎖機(jī)制心傀。
我們需要明白,鎖機(jī)制有兩個層面拆讯。
一種是代碼層次上的脂男,如java中的同步鎖,典型的就是同步關(guān)鍵字synchronized往果,這里我不在做過多的講解疆液,
感興趣的可以參考:http://www.cnblogs.com/xiohao/p/4151408.html
另外一種是數(shù)據(jù)庫層次上的一铅,比較典型的就是悲觀鎖和樂觀鎖陕贮。這里我們重點(diǎn)講解的就是悲觀鎖(傳統(tǒng)的物理鎖)和樂觀鎖。
悲觀鎖(Pessimistic Locking):
悲觀鎖潘飘,正如其名肮之,它指的是對數(shù)據(jù)被外界(包括本系統(tǒng)當(dāng)前的其他事務(wù),以及來自?外部系統(tǒng)的事務(wù)處理)修改持保守態(tài)度卜录,因此戈擒,
在整個數(shù)據(jù)處理過程中,將數(shù)據(jù)處于鎖定狀態(tài)艰毒。
悲觀鎖的實(shí)現(xiàn)筐高,往往依靠數(shù)據(jù)庫提供的鎖機(jī)制(也只有數(shù)據(jù)庫層提供的鎖機(jī)制才能?真正保證數(shù)據(jù)訪問的排他性,否則丑瞧,即使在本系統(tǒng)
中實(shí)現(xiàn)了加鎖機(jī)制柑土,也無法保證外部系?統(tǒng)不會修改數(shù)據(jù))。
一個典型的倚賴數(shù)據(jù)庫的悲觀鎖調(diào)用:
select * from account where name=”Erica” for update
這條 sql 語句鎖定了 account 表中所有符合檢索條件( name=”Erica” )的記錄绊汹。
本次事務(wù)提交之前(事務(wù)提交時會釋放事務(wù)過程中的鎖)稽屏,外界無法修改這些記錄。
Hibernate 的悲觀鎖西乖,也是基于數(shù)據(jù)庫的鎖機(jī)制實(shí)現(xiàn)狐榔。
下面的代碼實(shí)現(xiàn)了對查詢記錄的加鎖:
String hqlStr ="from TUser as user where user.name='Erica'";
Query query = session.createQuery(hqlStr);
query.setLockMode("user",LockMode.UPGRADE); // 加鎖
List userList = query.list();// 執(zhí)行查詢,獲取數(shù)據(jù)
query.setLockMode對查詢語句中获雕,特定別名所對應(yīng)的記錄進(jìn)行加鎖(我們?yōu)?TUser 類指定了一個別名 “user” )薄腻,這里也就是對
返回的所有 user 記錄進(jìn)行加鎖。
觀察運(yùn)行期 Hibernate 生成的 SQL 語句:
select tuser0_.id as id, tuser0_.name as name, tuser0_.group_id
as group_id, tuser0_.user_type as user_type, tuser0_.sex as sex
from t_user tuser0_ where (tuser0_.name='Erica' ) for update
這里 Hibernate 通過使用數(shù)據(jù)庫的 for update 子句實(shí)現(xiàn)了悲觀鎖機(jī)制届案。
Hibernate 的加鎖模式有:
? LockMode.NONE : 無鎖機(jī)制被廓。
? LockMode.WRITE : Hibernate 在 Insert 和 Update 記錄的時候會自動獲取
? LockMode.READ : Hibernate 在讀取記錄的時候會自動獲取。
以上這三種鎖機(jī)制一般由 Hibernate 內(nèi)部使用萝玷,如 Hibernate 為了保證 Update
過程中對象不會被外界修改嫁乘,會在 save 方法實(shí)現(xiàn)中自動為目標(biāo)對象加上 WRITE 鎖昆婿。
? LockMode.UPGRADE :利用數(shù)據(jù)庫的 for update 子句加鎖。
? LockMode. UPGRADE_NOWAIT : Oracle 的特定實(shí)現(xiàn)蜓斧,利用 Oracle 的 for
update nowait 子句實(shí)現(xiàn)加鎖仓蛆。
上面這兩種鎖機(jī)制是我們在應(yīng)用層較為常用的,加鎖一般通過以下方法實(shí)現(xiàn):
Criteria.setLockMode
Query.setLockMode
Session.lock
注意挎春,只有在查詢開始之前(也就是 Hiberate 生成 SQL 之前)設(shè)定加鎖看疙,才會
真正通過數(shù)據(jù)庫的鎖機(jī)制進(jìn)行加鎖處理,否則直奋,數(shù)據(jù)已經(jīng)通過不包含 for update
子句的 Select SQL 加載進(jìn)來能庆,所謂數(shù)據(jù)庫加鎖也就無從談起。
為了更好的理解select... for update的鎖表的過程脚线,本人將要以mysql為例搁胆,進(jìn)行相應(yīng)的講解
1、要測試鎖定的狀況邮绿,可以利用MySQL的Command Mode 渠旁,開二個視窗來做測試。
表的基本結(jié)構(gòu)如下:
表中內(nèi)容如下:
開啟兩個測試窗口船逮,在其中一個窗口執(zhí)行select * from ta for update0
然后在另外一個窗口執(zhí)行update操作如下圖:
等到一個窗口commit后的圖片如下:
到這里顾腊,悲觀鎖機(jī)制你應(yīng)該了解一些了吧~
需要注意的是for update要放到mysql的事務(wù)中,即begin和commit中挖胃,否者不起作用杂靶。
至于是鎖住整個表還是鎖住選中的行,請參考:
http://www.cnblogs.com/xiohao/p/4385768.html
至于hibernate中的悲觀鎖使用起來比較簡單酱鸭,這里就不寫demo了~感興趣的自己查一下就ok了~
樂觀鎖(Optimistic Locking):
相對悲觀鎖而言吗垮,樂觀鎖機(jī)制采取了更加寬松的加鎖機(jī)制。悲觀鎖大多數(shù)情況下依?靠數(shù)據(jù)庫的鎖機(jī)制實(shí)現(xiàn)凛辣,以保證操作最大程度的獨(dú)占性抱既。但隨之
而來的就是數(shù)據(jù)庫?性能的大量開銷,特別是對長事務(wù)而言扁誓,這樣的開銷往往無法承受防泵。?如一個金融系統(tǒng),當(dāng)某個操作員讀取用戶的數(shù)據(jù)蝗敢,并在讀出的用戶數(shù)
據(jù)的基礎(chǔ)上進(jìn)?行修改時(如更改用戶帳戶余額)捷泞,如果采用悲觀鎖機(jī)制,也就意味著整個操作過?程中(從操作員讀出數(shù)據(jù)寿谴、開始修改直至提交修改結(jié)果的全
過程锁右,甚至還包括操作?員中途去煮咖啡的時間),數(shù)據(jù)庫記錄始終處于加鎖狀態(tài),可以想見咏瑟,如果面對幾?百上千個并發(fā)拂到,這樣的情況將導(dǎo)致怎樣的后果。?樂
觀鎖機(jī)制在一定程度上解決了這個問題码泞。
樂觀鎖兄旬,大多是基于數(shù)據(jù)版本?? Version )記錄機(jī)制實(shí)現(xiàn)。何謂數(shù)據(jù)版本余寥?即為數(shù)據(jù)增加一個版本標(biāo)識领铐,在基于數(shù)據(jù)庫表的版本解決方案中,一般是通
過為數(shù)據(jù)庫表增加一個 “version” 字段來?實(shí)現(xiàn)宋舷。?讀取出數(shù)據(jù)時绪撵,將此版本號一同讀出,之后更新時祝蝠,對此版本號加一音诈。此時,將提?交數(shù)據(jù)的版本數(shù)據(jù)與數(shù)據(jù)
庫表對應(yīng)記錄的當(dāng)前版本信息進(jìn)行比對续膳,如果提交的數(shù)據(jù)?版本號大于數(shù)據(jù)庫表當(dāng)前版本號改艇,則予以更新收班,否則認(rèn)為是過期數(shù)據(jù)坟岔。對于上面修改用戶帳戶信息
的例子而言,假設(shè)數(shù)據(jù)庫中帳戶信息表中有一個?version 字段摔桦,當(dāng)前值為 1 社付;而當(dāng)前帳戶余額字段( balance )為 $100 。操作員 A 此時將其讀出
( version=1 )邻耕,并從其帳戶余額中扣除 $50( $100-$50 )鸥咖。?2 在操作員 A 操作的過程中,操作員 B 也讀入此用戶信息( version=1 )兄世,并?從其帳
戶余額中扣除 $20 ( $100-$20 )啼辣。?3 操作員 A 完成了修改工作,將數(shù)據(jù)版本號加一( version=2 )御滩,連同帳戶扣?除后余額( balance=$50 )鸥拧,提交
至數(shù)據(jù)庫更新,此時由于提交數(shù)據(jù)版本大?于數(shù)據(jù)庫記錄當(dāng)前版本削解,數(shù)據(jù)被更新富弦,數(shù)據(jù)庫記錄 version 更新為 2 。?4 操作員 B 完成了操作氛驮,也將版本號加一
( version=2 )試圖向數(shù)據(jù)庫提交數(shù)?據(jù)( balance=$80 )腕柜,但此時比對數(shù)據(jù)庫記錄版本時發(fā)現(xiàn),操作員 B 提交的?數(shù)據(jù)版本號為 2 ,數(shù)據(jù)庫記錄當(dāng)前版
本也為 2 盏缤,不滿足 “ 提交版本必須大于記?錄當(dāng)前版本才能執(zhí)行更新 “ 的樂觀鎖策略砰蠢,因此,操作員 B 的提交被駁回唉铜。?這樣娩脾,就避免了操作員 B 用基于
version=1 的舊數(shù)據(jù)修改的結(jié)果覆蓋操作?員 A 的操作結(jié)果的可能。?從上面的例子可以看出打毛,樂觀鎖機(jī)制避免了長事務(wù)中的數(shù)據(jù)庫加鎖開銷(操作員 A
和操作員 B 操作過程中柿赊,都沒有對數(shù)據(jù)庫數(shù)據(jù)加鎖),大大提升了大并發(fā)量下的系?統(tǒng)整體性能表現(xiàn)幻枉。?需要注意的是碰声,樂觀鎖機(jī)制往往基于系統(tǒng)中的數(shù)據(jù)存儲
邏輯,因此也具備一定的局?限性熬甫,如在上例中胰挑,由于樂觀鎖機(jī)制是在我們的系統(tǒng)中實(shí)現(xiàn),來自外部系統(tǒng)的用戶?余額更新操作不受我們系統(tǒng)的控制椿肩,因此可能
會造成臟數(shù)據(jù)被更新到數(shù)據(jù)庫中瞻颂。在?系統(tǒng)設(shè)計階段,我們應(yīng)該充分考慮到這些情況出現(xiàn)的可能性郑象,并進(jìn)行相應(yīng)調(diào)整(如?將樂觀鎖策略在數(shù)據(jù)庫存儲過程中實(shí)
現(xiàn)贡这,對外只開放基于此存儲過程的數(shù)據(jù)更新途?徑,而不是將數(shù)據(jù)庫表直接對外公開)厂榛。?Hibernate 在其數(shù)據(jù)訪問引擎中內(nèi)置了樂觀鎖實(shí)現(xiàn)盖矫。如果不用考慮外
部系統(tǒng)對數(shù)?據(jù)庫的更新操作,利用 Hibernate 提供的透明化樂觀鎖實(shí)現(xiàn)击奶,將大大提升我們的?生產(chǎn)力辈双。
User.hbm.xml
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
注意 version 節(jié)點(diǎn)必須出現(xiàn)在 ID 節(jié)點(diǎn)之后。
這里我們聲明了一個 version 屬性柜砾,用于存放用戶的版本信息湃望,保存在 User 表的version中
optimistic-lock 屬性有如下可選取值:
? none
無樂觀鎖
? version
通過版本機(jī)制實(shí)現(xiàn)樂觀鎖
? dirty
通過檢查發(fā)生變動過的屬性實(shí)現(xiàn)樂觀鎖
? all
通過檢查所有屬性實(shí)現(xiàn)樂觀鎖
其中通過 version 實(shí)現(xiàn)的樂觀鎖機(jī)制是 Hibernate 官方推薦的樂觀鎖實(shí)現(xiàn),同時也
是 Hibernate 中痰驱,目前唯一在數(shù)據(jù)對象脫離 Session 發(fā)生修改的情況下依然有效的鎖機(jī)
制证芭。因此,一般情況下萄唇,我們都選擇 version 方式作為 Hibernate 樂觀鎖實(shí)現(xiàn)機(jī)制檩帐。
2 . 配置文件hibernate.cfg.xml和UserTest測試類
hibernate.cfg.xml
"-//Hibernate/Hibernate Configuration DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">org.hibernate.dialect.MySQL5InnoDBDialectupdatetruefalsethreadjdbc:mysql:///userroot123456com.mysql.jdbc.Driver
UserTest.java
packagecom.xiaohao.test;importorg.hibernate.Session;importorg.hibernate.SessionFactory;importorg.hibernate.Transaction;importorg.hibernate.cfg.Configuration;publicclassUserTest {publicstaticvoidmain(String[] args) {
Configuration conf=newConfiguration().configure();
SessionFactory sf=conf.buildSessionFactory();
Session session=sf.getCurrentSession();
Transaction tx=session.beginTransaction();//User user=new User("小浩","英雄");//session.save(user);//session.createSQLQuery("insert into user(userName,password) value('張英雄16','123')")//.executeUpdate();User user=(User) session.get(User.class, 1);
user.setUserName("221");//session.save(user);System.out.println("恭喜您,用戶的數(shù)據(jù)插入成功了哦~~");
tx.commit();
}
}
每次對 TUser 進(jìn)行更新的時候另萤,我們可以發(fā)現(xiàn)湃密,數(shù)據(jù)庫中的 version 都在遞增诅挑。
下面我們將要通過樂觀鎖來實(shí)現(xiàn)一下并發(fā)和同步的測試用例:
這里需要使用兩個測試類,分別運(yùn)行在不同的虛擬機(jī)上面泛源,以此來模擬多個用戶同時操作一張表,同時其中一個測試類需要模擬長事務(wù)
UserTest.java
packagecom.xiaohao.test;importorg.hibernate.Session;importorg.hibernate.SessionFactory;importorg.hibernate.Transaction;importorg.hibernate.cfg.Configuration;publicclassUserTest {publicstaticvoidmain(String[] args) {
Configuration conf=newConfiguration().configure();
SessionFactory sf=conf.buildSessionFactory();
Session session=sf.openSession();//Session session2=sf.openSession();User user=(User) session.createQuery(" from User user where user=5").uniqueResult();//User user2=(User) session.createQuery(" from User user where user=5").uniqueResult();System.out.println(user.getVersion());//System.out.println(user2.getVersion());Transaction tx=session.beginTransaction();
user.setUserName("101");
tx.commit();
System.out.println(user.getVersion());//System.out.println(user2.getVersion());//System.out.println(user.getVersion()==user2.getVersion());//Transaction tx2=session2.beginTransaction();//user2.setUserName("4468");//tx2.commit();}
}
UserTest2.java
packagecom.xiaohao.test;importorg.hibernate.Session;importorg.hibernate.SessionFactory;importorg.hibernate.Transaction;importorg.hibernate.cfg.Configuration;publicclassUserTest2 {publicstaticvoidmain(String[] args)throwsInterruptedException {
Configuration conf=newConfiguration().configure();
SessionFactory sf=conf.buildSessionFactory();
Session session=sf.openSession();//Session session2=sf.openSession();User user=(User) session.createQuery(" from User user where user=5").uniqueResult();
Thread.sleep(10000);//User user2=(User) session.createQuery(" from User user where user=5").uniqueResult();System.out.println(user.getVersion());//System.out.println(user2.getVersion());Transaction tx=session.beginTransaction();
user.setUserName("100");
tx.commit();
System.out.println(user.getVersion());//System.out.println(user2.getVersion());//System.out.println(user.getVersion()==user2.getVersion());//Transaction tx2=session2.beginTransaction();//user2.setUserName("4468");//tx2.commit();}
}
操作流程及簡單講解: 首先啟動UserTest2.java測試類拔妥,在執(zhí)行到Thread.sleep(10000);這條語句的時候,當(dāng)前線程會進(jìn)入睡眠狀態(tài)达箍。在10秒鐘之內(nèi)
啟動UserTest這個類没龙,在到達(dá)10秒的時候,我們將會在UserTest.java中拋出下面的異常:
Exception in thread "main" org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.xiaohao.test.User#5]
at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1932)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2576)
at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2476)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2803)
at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:113)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:273)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:265)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:185)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1216)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:383)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:133)
at com.xiaohao.test.UserTest2.main(UserTest2.java:21)
UserTest2代碼將在 tx.commit() 處拋出 StaleObjectStateException 異?常缎玫,并指出版本檢查失敗硬纤,當(dāng)前事務(wù)正在試圖提交一個過期數(shù)據(jù)。通過捕捉這個異常赃磨,我?們就可以在樂觀鎖校驗(yàn)失敗時進(jìn)行相應(yīng)處理
3筝家、常見并發(fā)同步案例分析
案例一:訂票系統(tǒng)案例,某航班只有一張機(jī)票邻辉,假定有1w個人打開你的網(wǎng)站來訂票溪王,問你如何解決并發(fā)問題(可擴(kuò)展到任何高并發(fā)網(wǎng)站要考慮
的并發(fā)讀寫問題)
問題,1w個人來訪問值骇,票沒出去前要保證大家都能看到有票莹菱,不可能一個人在看到票的時候別人就不能看了。到底誰能搶到吱瘩,那得看這個人的“運(yùn)氣”(網(wǎng)
絡(luò)快慢等)
其次考慮的問題道伟,并發(fā),1w個人同時點(diǎn)擊購買搅裙,到底誰能成交皱卓?總共只有一張票裹芝。
首先我們?nèi)菀紫氲胶筒l(fā)相關(guān)的幾個方案 :
鎖同步同步更多指的是應(yīng)用程序的層面部逮,多個線程進(jìn)來,只能一個一個的訪問嫂易,java中指的是syncrinized關(guān)鍵字兄朋。鎖也有2個層面,一個是java中談到的對
象鎖怜械,用于線程同步颅和;另外一個層面是數(shù)據(jù)庫的鎖;如果是分布式的系統(tǒng)缕允,顯然只能利用數(shù)據(jù)庫端的鎖來實(shí)現(xiàn)峡扩。
假定我們采用了同步機(jī)制或者數(shù)據(jù)庫物理鎖機(jī)制,如何保證1w個人還能同時看到有票障本,顯然會犧牲性能教届,在高并發(fā)網(wǎng)站中是不可取的响鹃。使用hibernate后我們
提出了另外一個概念:樂觀鎖、悲觀鎖(即傳統(tǒng)的物理鎖)案训;
采用樂觀鎖即可解決此問題买置。樂觀鎖意思是不鎖定表的情況下,利用業(yè)務(wù)的控制來解決并發(fā)問題强霎,這樣即保證數(shù)據(jù)的并發(fā)可讀性又保證保存數(shù)據(jù)的排他性忿项,保
證性能的同時解決了并發(fā)帶來的臟數(shù)據(jù)問題。
hibernate中如何實(shí)現(xiàn)樂觀鎖:
前提:在現(xiàn)有表當(dāng)中增加一個冗余字段城舞,version版本號, long類型
原理:
1)只有當(dāng)前版本號》=數(shù)據(jù)庫表版本號轩触,才能提交
2)提交成功后,版本號version ++
實(shí)現(xiàn)很簡單:在ormapping增加一屬性optimistic-lock="version"即可家夺,以下是樣例片段
optimistic-lock="version"table="T_Stock" schema="STOCK">
案例二怕膛、股票交易系統(tǒng)、銀行系統(tǒng)秦踪,大數(shù)據(jù)量你是如何考慮的
首先褐捻,股票交易系統(tǒng)的行情表,每幾秒鐘就有一個行情記錄產(chǎn)生椅邓,一天下來就有(假定行情3秒一個) 股票數(shù)量×20×60*6 條記錄柠逞,一月下來這個表記錄數(shù)
量多大? oracle中一張表的記錄數(shù)超過100w后 查詢性能就很差了景馁,如何保證系統(tǒng)性能板壮?
再比如,中國移動有上億的用戶量合住,表如何設(shè)計绰精?把所有用于存在于一個表么?
所以透葛,大數(shù)量的系統(tǒng)笨使,必須考慮表拆分-(表名字不一樣,但是結(jié)構(gòu)完全一樣)僚害,通用的幾種方式:(視情況而定)
1)按業(yè)務(wù)分硫椰,比如 手機(jī)號的表,我們可以考慮 130開頭的作為一個表萨蚕,131開頭的另外一張表 以此類推
2)利用oracle的表拆分機(jī)制做分表
3)如果是交易系統(tǒng)靶草,我們可以考慮按時間軸拆分,當(dāng)日數(shù)據(jù)一個表岳遥,歷史數(shù)據(jù)弄到其它表奕翔。這里歷史數(shù)據(jù)的報表和查詢不會影響當(dāng)日交易。
當(dāng)然浩蓉,表拆分后我們的應(yīng)用得做相應(yīng)的適配派继。單純的or-mapping也許就得改動了帮坚。比如部分業(yè)務(wù)得通過存儲過程等
此外,我們還得考慮緩存
這里的緩存互艾,指的不僅僅是hibernate试和,hibernate本身提供了一級二級緩存。這里的緩存獨(dú)立于應(yīng)用纫普,依然是內(nèi)存的讀取阅悍,假如我們能減少數(shù)據(jù)庫頻繁的訪
問,那對系統(tǒng)肯定大大有利的昨稼。比如一個電子商務(wù)系統(tǒng)的商品搜索节视,如果某個關(guān)鍵字的商品經(jīng)常被搜,那就可以考慮這部分商品列表存放到緩存(內(nèi)存中
去)假栓,這樣不用每次訪問數(shù)據(jù)庫寻行,性能大大增加。
簡單的緩存大家可以理解為自己做一個hashmap匾荆,把常訪問的數(shù)據(jù)做一個key拌蜘,value是第一次從數(shù)據(jù)庫搜索出來的值,下次訪問就可以從map里讀取牙丽,而不
讀數(shù)據(jù)庫简卧;專業(yè)些的目前有獨(dú)立的緩存框架比如memcached 等,可獨(dú)立部署成一個緩存服務(wù)器烤芦。
4举娩、常見的提高高并發(fā)下訪問的效率的手段
首先要了解高并發(fā)的的瓶頸在哪里?
1构罗、可能是服務(wù)器網(wǎng)絡(luò)帶寬不夠
2.可能web線程連接數(shù)不夠
3.可能數(shù)據(jù)庫連接查詢上不去铜涉。
根據(jù)不同的情況,解決思路也不同遂唧。
像第一種情況可以增加網(wǎng)絡(luò)帶寬芙代,DNS域名解析分發(fā)多臺服務(wù)器。
負(fù)載均衡蠢箩,前置代理服務(wù)器nginx链蕊、apache等等
數(shù)據(jù)庫查詢優(yōu)化,讀寫分離谬泌,分表等等
最后復(fù)制一些在高并發(fā)下面需要常常需要處理的內(nèi)容:
盡量使用緩存,包括用戶緩存逻谦,信息緩存等掌实,多花點(diǎn)內(nèi)存來做緩存,可以大量減少與數(shù)據(jù)庫的交互邦马,提高性能贱鼻。
用jprofiler等工具找出性能瓶頸宴卖,減少額外的開銷。
優(yōu)化數(shù)據(jù)庫查詢語句邻悬,減少直接使用hibernate等工具的直接生成語句(僅耗時較長的查詢做優(yōu)化)症昏。
優(yōu)化數(shù)據(jù)庫結(jié)構(gòu),多做索引父丰,提高查詢效率肝谭。
統(tǒng)計的功能盡量做緩存,或按每天一統(tǒng)計或定時統(tǒng)計相關(guān)報表蛾扇,避免需要時進(jìn)行統(tǒng)計的功能攘烛。
能使用靜態(tài)頁面的地方盡量使用,減少容器的解析(盡量將動態(tài)內(nèi)容生成靜態(tài)html來顯示)镀首。
解決以上問題后坟漱,使用服務(wù)器集群來解決單臺的瓶頸問題。
java高并發(fā)更哄,如何解決芋齿,什么方式解決
之前我將高并發(fā)的解決方法誤認(rèn)為是線程或者是隊(duì)列可以解決,因?yàn)楦卟l(fā)的時候是有很多用戶在訪問成翩,導(dǎo)致出現(xiàn)系統(tǒng)數(shù)據(jù)不正確沟突、丟失數(shù)據(jù)現(xiàn)象,所以想到 的是用隊(duì)列解決捕传,其實(shí)隊(duì)列解決的方式也可以處理惠拭,比如我們在競拍商品、轉(zhuǎn)發(fā)評論微博或者是秒殺商品等庸论,同一時間訪問量特別大职辅,隊(duì)列在此起到特別的作用,將 所有請求放入隊(duì)列聂示,以毫秒計時單位域携,有序的進(jìn)行,從而不會出現(xiàn)數(shù)據(jù)丟失系統(tǒng)數(shù)據(jù)不正確的情況鱼喉。
今天我經(jīng)過查資料秀鞭,高并發(fā)的解決方法有倆種:
一種是使用緩存、另一種是使用生成靜態(tài)頁面扛禽;還有就是從最基礎(chǔ)的地方優(yōu)化我們寫代碼減少不必要的資源浪費(fèi):(
1.不要頻繁的new對象,對于在整個應(yīng)用中只需要存在一個實(shí)例的類使用單例模式.對于String的連接操作,使用StringBuffer或者StringBuilder.對于utility類型的類通過靜態(tài)方法來訪問锋边。
2. 避免使用錯誤的方式,如Exception可以控制方法推出,但是Exception要保留stacktrace消耗性能,除非必要不要使用 instanceof做條件判斷,盡量使用比的條件判斷方式.使用JAVA中效率高的類,比如ArrayList比Vector性能好。)
首先緩存技術(shù)我一直沒有使用過编曼,我覺得應(yīng)該是在用戶請求時將數(shù)據(jù)保存在緩存中豆巨,下次請求時會檢測緩存中是否有數(shù)據(jù)存在,防止多次請求服務(wù)器掐场,導(dǎo)致服務(wù)器性能降低往扔,嚴(yán)重導(dǎo)致服務(wù)器崩潰贩猎,這只是我自己的理解,詳細(xì)的資料還是需要在網(wǎng)上收集萍膛;
使用生成靜態(tài)頁面我想大家應(yīng)該不模式吭服,我們見過很多網(wǎng)站當(dāng)在請求的時候頁面的后最已經(jīng)變了,如“http://developer.51cto.com/art/201207/348766.htm”該頁面其實(shí)是一個服務(wù)器請求地址蝗罗,在轉(zhuǎn)換成htm后艇棕,訪問速度將提升,因?yàn)殪o態(tài)頁面不帶有服務(wù)器組件绿饵;在這里我就多多介紹一下:
一欠肾、什么是頁面靜態(tài)化:
簡 單的說,我們?nèi)绻L問一個鏈接 ,服務(wù)器對應(yīng)的模塊會處理這個請求拟赊,轉(zhuǎn)到對應(yīng)的jsp界面刺桃,最后生成我們想要看到的數(shù)據(jù)。這其中的缺點(diǎn)是顯而易見的:因?yàn)槊看握埱蠓?wù)器都會進(jìn)行處理吸祟,如 果有太多的高并發(fā)請求瑟慈,那么就會加重應(yīng)用服務(wù)器的壓力,弄不好就把服務(wù)器 搞down 掉了屋匕。那么如何去避免呢葛碧?如果我們把對 test.do 請求后的結(jié)果保存成一個 html 文件,然后每次用戶都去訪問 ,這樣應(yīng)用服務(wù)器的壓力不就減少了过吻?
那么靜態(tài)頁面從哪里來呢进泼?總不能讓我們每個頁面都手動處理吧?這里就牽涉到我們要講解的內(nèi)容了纤虽,靜態(tài)頁面生成方案… 我們需要的是自動的生成靜態(tài)頁面乳绕,當(dāng)用戶訪問 ,會自動生成 test.html ,然后顯示給用戶。
二逼纸、下面我們在簡單介紹一下要想掌握頁面靜態(tài)化方案應(yīng)該掌握的知識點(diǎn):
1洋措、基礎(chǔ)- URL Rewrite
什么是 URL Rewrite 呢 ? URL 重寫。用一個簡單的例子來說明問題:輸入網(wǎng)址 ,但是實(shí)際上訪問的卻是 abc.com/test.action,那我們就可以說 URL 被重寫了杰刽。這項(xiàng)技術(shù)應(yīng)用廣泛菠发,有許多開源的工具可以實(shí)現(xiàn)這個功能。
2贺嫂、基礎(chǔ)- Servlet web.xml
如果你還不知道 web.xml 中一個請求和一個 servlet 是如何匹配到一起的滓鸠,那么請搜索一下 servlet 的文檔。這可不是亂說呀涝婉,有很多人就認(rèn)為 /xyz/*.do 這樣的匹配方式能有效哥力。
如果你還不知道怎么編寫一個 servlet ,那么請搜索一下如何編寫 servlet.這可不是說笑呀,在各種集成工具漫天飛舞的今天墩弯,很多人都不會去從零編寫一個 servlet了吩跋。
三、基本的方案介紹
其中渔工,對于 URL Rewriter的部分锌钮,可以使用收費(fèi)或者開源的工具來實(shí)現(xiàn),如果 url不是特別的復(fù)雜引矩,可以考慮在 servlet 中實(shí)現(xiàn)梁丘,那么就是下面這個樣子:
總 結(jié):其實(shí)我們在開發(fā)中都很少考慮這種問題,直接都是先將功能實(shí)現(xiàn)旺韭,當(dāng)一個程序員在干到1到2年氛谜,就會感覺光實(shí)現(xiàn)功能不是最主要的,安全性能区端、質(zhì)量等等才是 一個開發(fā)人員最該關(guān)心的值漫。今天我所說的是高并發(fā)。
我的解決思路是:
1织盼、采用分布式應(yīng)用設(shè)計
2杨何、分布式緩存數(shù)據(jù)庫
3、代碼優(yōu)化
Java高并發(fā)的例子:
??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
具體情況是這樣:?通過java和數(shù)據(jù)庫沥邻,自己實(shí)現(xiàn)序列自動增長危虱。
實(shí)現(xiàn)代碼大致如下:
id_table表結(jié)構(gòu),?主要字段:
id_namevarchar2(16);
id_valnumber(16,0);
id_prefixvarchar2(4);
//操作DBpublicsynchronizedString nextStringValue(String id){
SqlSession sqlSess=SqlSessionUtil.getSqlSession();
sqlSess.update("update id_table set id_val = id_val + 1 where id_name="+id);
Map map= sqlSess.getOne("select id_name, id_prefix, id_val from id_table where id_name="+id);
BigDecimal val= (BigDecimal) map.get("id_val");//id_val是具體數(shù)字,rePack主要是統(tǒng)一返回固定長度的字符串唐全;如:Y0000001, F0000001, T0000001等String idValue =rePack(val, map);returnidValue;
}//公共方法publicclassIdHelpTool{publicstaticString getNextStringValue(String idName){returngetXX().nextStringValue(idName);
}
}
具體使用者埃跷,都是通過類似這種方式:IdHelpTool.getNextStringValue("PAY_LOG");來調(diào)用。
問題:
(1)?當(dāng)出現(xiàn)并發(fā)時邮利,?有時會獲取重復(fù)的ID弥雹;
(2)?由于服務(wù)器做了相關(guān)一些設(shè)置,有時調(diào)用這個方法近弟,好像還會導(dǎo)致超時缅糟。
為了解決問題(1),?考慮過在方法getNextStringValue上,也加上synchronized?祷愉,?同步關(guān)鍵字過多窗宦,會不會更導(dǎo)致超時?
跪求大俠提供個解決問題的大概思路68昂!
??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
解決思路一:
1订讼、推薦?https://github.com/adyliu/idcenter
2髓窜、可以通過第三方redis來實(shí)現(xiàn)。
解決思路一:
1、出現(xiàn)重復(fù)ID寄纵,是因?yàn)榕K讀了鳖敷,并發(fā)的時候不加?synchronized??比如會出現(xiàn)問題
2、但是加了?synchronized??程拭,性能急劇下降了定踱,本身?java?就是多線程的,你把它單線程使用恃鞋,不是明智的選擇崖媚,同時,如果分布式部署的時候恤浪,加了?synchronized??也無法控制并發(fā)
3畅哑、調(diào)用這個方法,出現(xiàn)超時的情況水由,說明你的并發(fā)已經(jīng)超過了數(shù)據(jù)庫所能處理的極限荠呐,數(shù)據(jù)庫無限等待導(dǎo)致超時
基于上面的分析,建議采用線程池的方案绷杜,支付寶的單號就是用的線程池的方案進(jìn)行的直秆。
數(shù)據(jù)庫?update?不是一次加1,而是一次加幾百甚至上千鞭盟,然后取到的這?1000個序號圾结,放在線程池里慢慢分配即可,能應(yīng)付任意大的并發(fā)齿诉,同時保證數(shù)據(jù)庫沒任何壓力筝野。
??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
來源于:http://www.cnblogs.com/lr393993507/p/5909804.html