悲觀鎖(pessimistic lock), 顧名思義,就是很悲觀,每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人會(huì)修改,所以每次在拿數(shù)據(jù)的時(shí)候都會(huì)上鎖,這樣別人想拿這個(gè)數(shù)據(jù)就會(huì)block直到它拿到鎖。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫里邊就用到了很多這種鎖機(jī)制,比如行鎖,表鎖等,讀鎖,寫鎖等,都是在做操作之前先上鎖。
最常用的就是 select … for update,它是一種行鎖,會(huì)把select出來的結(jié)果行鎖住,在本事務(wù)提交或者回滾之前,不允許其他事務(wù)對這些行做update、delete、for update操作。
樂觀鎖(Optimistic Lock), 顧名思義,就是很樂觀,每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人不會(huì)修改,所以不會(huì)上鎖,期間該數(shù)據(jù)可以隨便被其他人讀取,但是在更新的時(shí)候會(huì)判斷一下在此期間別人有沒有去更新這個(gè)數(shù)據(jù),可以使用版本號(hào)等機(jī)制。
版本號(hào)機(jī)制是樂觀鎖最常用的方式,就是在表中增加一個(gè)版本號(hào)的字段,更新前先查一遍獲取版本號(hào),再作為更新語句的where條件進(jìn)行更新,如果數(shù)據(jù)在獲取版本號(hào)之后,在更新之前已經(jīng)改變了,那就會(huì)更新失敗,因?yàn)樽詈蟾铝?條數(shù)據(jù),Java后臺(tái)拿到更新數(shù)如果為0,則說明更新失敗,出現(xiàn)了并發(fā)問題,然后做具體的處理。
例如有兩個(gè)人同時(shí)對某條數(shù)據(jù)做修改,過程如下:
操作員A操作如下:
select?id,?balance,?version?from?table?where?id=“1”;
查詢結(jié)果:id=1, balance=1000, version=1
update?table?set?balance=balance+100,?version=version+1?where?id=“1”?and?version=1;
執(zhí)行后,返回的更新結(jié)果是1,說明更新了一條,數(shù)據(jù)庫里的結(jié)果是:id=1, balance=1100, version=2
操作員B操作如下:
select?id,?balance,?version?from?table?where?id=“1”;
查詢結(jié)果:id=1, balance=1000, version=1, 說明操作員A還沒修改。
update?table?set?balance=balance-50,?version=version+1?where?id=“1”?and?version=1?;
查的時(shí)候,操作員A還沒修改,當(dāng)要更新時(shí),操作員A已經(jīng)先修改成功,所以數(shù)據(jù)庫里實(shí)際值是id=1, balance=1100, version=2,
操作員B也將版本號(hào)加一(version=2)試圖向數(shù)據(jù)庫提交數(shù)據(jù)(balance=950),但此時(shí)查不到where id=“1” and version=1 的數(shù)據(jù),
所以update就失敗了,執(zhí)行結(jié)果是0,說明沒有對任何數(shù)據(jù)更新成功。
現(xiàn)在再去查一下,結(jié)果還是操作員A操作完成之后的結(jié)果
select id, balance, version from table where id=“1”;
查詢結(jié)果:id=1, balance=1100, version=2
以上是自己實(shí)現(xiàn)版本號(hào)機(jī)制的原理,真正使用的版本號(hào)機(jī)制是數(shù)據(jù)庫本身帶有的機(jī)制,一旦發(fā)現(xiàn)更新的版本號(hào)不是最新的就會(huì)被駁回。