JPA使用樂觀鎖應(yīng)對高并發(fā)

高并發(fā)系統(tǒng)的挑戰(zhàn)

在部署分布式系統(tǒng)時(shí)，我們通常把多個(gè)微服務(wù)部署在內(nèi)網(wǎng)集群中，再用API網(wǎng)關(guān)聚合起來對外提供。為了做負(fù)載均衡，通常會對每個(gè)微服務(wù)都啟動多個(gè)運(yùn)行實(shí)例，通過注冊中心去調(diào)用。

那么問題來了，因?yàn)橛卸鄠€(gè)實(shí)例運(yùn)行都是同一個(gè)應(yīng)用，雖然微服務(wù)網(wǎng)關(guān)會把每一個(gè)請求只轉(zhuǎn)發(fā)給一個(gè)實(shí)例，但當(dāng)面對高并發(fā)時(shí)，但它們?nèi)匀豢赡芡瑫r(shí)操作同一個(gè)數(shù)據(jù)庫表，這會不會引發(fā)什么問題呢？

悲觀鎖的問題

比如電商中常見的商品秒殺系統(tǒng)，在用戶搶購商品過程中，會有大量并發(fā)請求，很可能同時(shí)讀寫一個(gè)包含商品剩余數(shù)量的表，這種一般要給數(shù)據(jù)庫加鎖，否則很容易出現(xiàn)商品超賣錯(cuò)賣的情況。

如果使用數(shù)據(jù)庫自帶的鎖機(jī)制，也就是悲觀鎖，在寫入的時(shí)候鎖定數(shù)據(jù)庫，其他修改請求到來時(shí)就必須等待鎖釋放，但這就使效率降下來了，而且高并發(fā)場景下可能有的請求一直搶不到鎖，就會長時(shí)間卡在那導(dǎo)致請求失敗，然后有大量重試，系統(tǒng)可能會發(fā)生連接數(shù)耗盡等異常。

樂觀鎖是個(gè)好東西

查閱資料發(fā)現(xiàn)樂觀鎖是個(gè)好東西，它是為數(shù)據(jù)庫表增加一個(gè)標(biāo)識數(shù)據(jù)版本的version字段來實(shí)現(xiàn)的，讀取數(shù)據(jù)時(shí)把version字段一同讀出，寫入數(shù)據(jù)庫時(shí)比對version字段就知道數(shù)據(jù)是否被更改過，如果version不相等就說明持有的是過期數(shù)據(jù)，不能寫入，如果相等就可以寫入，并把version加一。

樂觀鎖在寫入數(shù)據(jù)庫的時(shí)候，才會檢查數(shù)據(jù)是否沖突，如果發(fā)現(xiàn)沖突了，就放棄寫入，返回寫入失敗的信息，相比于悲觀鎖，這是一種輕量級的對數(shù)據(jù)的鎖定方式，能夠應(yīng)對高并發(fā)需求。

給數(shù)據(jù)庫添加樂觀鎖

說樂觀鎖是個(gè)好東西，首先得說 JPA 是個(gè)好東西，因?yàn)镾pring Data JPA已經(jīng)內(nèi)置了樂觀鎖的實(shí)現(xiàn)，給數(shù)據(jù)庫表添加樂觀鎖很簡單，添加一個(gè)整型字段，并加入@Version注解就可以了，每次提交數(shù)據(jù)時(shí)JPA會自動檢查版本。

    @Entity  
    @Table(name = "m_order")  
    public class Order {  
    ...  
        @Version  
        private int version;  
    ...  
    }  

樂觀鎖 -業(yè)務(wù)判斷 解決高并發(fā)

在解決高并發(fā)問題時(shí)，如果是分布式系統(tǒng)顯然我們只能夠使用數(shù)據(jù)庫端加鎖機(jī)制來解決這個(gè)問題，但是這種同步機(jī)制或者數(shù)據(jù)庫物理鎖機(jī)制會犧牲一部分的性能，所以常常以另外一種方式來解決這個(gè)問題 就是樂觀鎖模式

銀行兩操作員同時(shí)操作同一賬戶就是典型的樂觀鎖模式。

比如A、B操作員同時(shí)讀取一余額為1000元的賬戶，A操作員為該賬戶增加100元，B操作員同時(shí)為該賬戶扣除50元，A先提交，B后提交。最后實(shí)際賬戶余額為1000-50=950元，但本該為1000+100-50=1050。這就是典型的并發(fā)問題。

樂觀鎖機(jī)制在一定程度上解決了這個(gè)問題。樂觀鎖，大多是基于數(shù)據(jù)版本(Version)記錄機(jī)制實(shí)現(xiàn)。何謂數(shù)據(jù)版本？即為數(shù)據(jù)增加一個(gè)版本標(biāo)識，在基于數(shù)據(jù)庫表的版本解決方案中，一般是通過為數(shù)據(jù)庫表增加一個(gè) “version” 字段來實(shí)現(xiàn)。

讀取出數(shù)據(jù)時(shí)，將此版本號一同讀出，之后更新時(shí)，對此版本號加一。此時(shí)，將提交數(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ù)庫中帳戶信息表中有一個(gè)version字段，當(dāng)前值為1；而當(dāng)前帳戶余額字段(balance)為1000元。假設(shè)操作員A先更新完，操作員B后更新。

• a、操作員A此時(shí)將其讀出(version=1)，并從其帳戶余額中增加100(1000+100=1100)。
• b、在操作員A操作的過程中，操作員B也讀入此用戶信息(version=1)，并從其帳戶余額中扣除50(1000-50=950)。
• c、操作員A完成了修改工作，將數(shù)據(jù)版本號加一(version=2)，連同帳戶增加后余額(balance=1100)，提交至數(shù)據(jù)庫更新，此時(shí)由于提交數(shù)據(jù)版本大于數(shù)據(jù)庫記錄當(dāng)前版本，數(shù)據(jù)被更新，數(shù)據(jù)庫記錄version更新為2。
• d、操作員B完成了操作，也將版本號加一(version=2)試圖向數(shù)據(jù)庫提交數(shù)據(jù)(balance=950)，但此時(shí)比對數(shù)據(jù)庫記錄版本時(shí)發(fā)現(xiàn)，操作員B提交的數(shù)據(jù)版本號為2，數(shù)據(jù)庫記錄當(dāng)前版本也為2，不滿足 “提交版本必須大于記錄當(dāng)前版本才能執(zhí)行更新 “的樂觀鎖策略，因此，操作員B的提交被駁回。
• 這樣，就避免了操作員B用基于version=1的舊數(shù)據(jù)修改的結(jié)果覆蓋操作員A的操作結(jié)果的可能。

操作員A操作如下：

select id, balance, version from account where id="1"; 
查詢結(jié)果：id=1, balance=1000, version=1
update account 
set balance=balance+100, version=version+1 
where id="1" and version=1
select id, balance, version from account where id="1"; 
查詢結(jié)果：id=1, balance=1100, version=2

操作員B操作如下：

select id, balance, version from account where id="1"; 
查詢結(jié)果：id=1, balance=1000, version=1
#操作員A已修改成功，實(shí)際account.balance=1100、account.version=2，操作員B也將版本號加一(version=2)試圖向數(shù)據(jù)庫提交數(shù)據(jù)(balance=950)，但此時(shí)比對數(shù)據(jù)庫記錄版本時(shí)發(fā)現(xiàn)，操作員B提交的數(shù)據(jù)版本號為2，數(shù)據(jù)庫記錄當(dāng)前版本也為2，不滿足 “提交版本必須大于記錄當(dāng)前版本才能執(zhí)行更新 “的樂觀鎖策略，因此，操作員B的提交被駁回。
update account 
set balance=balance-50, version=version+1 
where id="1" and version=1 
select id, balance, version from account where id="1"; 
查詢結(jié)果：id=1, balance=1100, version=2

Hibernate、JPA等ORM框架或者實(shí)現(xiàn)，是使用版本號，再判斷UPDATE后返回的數(shù)值

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評論