十年網(wǎng)站開發(fā)經(jīng)驗 + 多家企業(yè)客戶 + 靠譜的建站團(tuán)隊
量身定制 + 運(yùn)營維護(hù)+專業(yè)推廣+無憂售后,網(wǎng)站問題一站解決
術(shù)式之后皆為邏輯,一切皆為需求和實現(xiàn)。希望此文能從需求、現(xiàn)狀和解決方式的角度幫大家理解隔離級別。
創(chuàng)新互聯(lián)主打移動網(wǎng)站、成都網(wǎng)站設(shè)計、成都做網(wǎng)站、網(wǎng)站改版、網(wǎng)絡(luò)推廣、網(wǎng)站維護(hù)、域名注冊、等互聯(lián)網(wǎng)信息服務(wù),為各行業(yè)提供服務(wù)。在技術(shù)實力的保障下,我們?yōu)榭蛻舫兄Z穩(wěn)定,放心的服務(wù),根據(jù)網(wǎng)站的內(nèi)容與功能再決定采用什么樣的設(shè)計。最后,要實現(xiàn)符合網(wǎng)站需求的內(nèi)容、功能與設(shè)計,我們還會規(guī)劃穩(wěn)定安全的技術(shù)方案做保障。
隔離級別的產(chǎn)生
在串型執(zhí)行的條件下,數(shù)據(jù)修改的順序是固定的、可預(yù)期的結(jié)果,但是并發(fā)執(zhí)行的情況下,數(shù)據(jù)的修改是不可預(yù)期的,也不固定,為了實現(xiàn)數(shù)據(jù)修改在并發(fā)執(zhí)行的情況下得到一個固定、可預(yù)期的結(jié)果,由此產(chǎn)生了隔離級別。
所以隔離級別的作用是用來平衡數(shù)據(jù)庫并發(fā)訪問與數(shù)據(jù)一致性的方法。
事務(wù)的4種隔離級別
READ UNCOMMITTED ? ? ? 未提交讀,可以讀取未提交的數(shù)據(jù)。READ COMMITTED ? ? ? ? 已提交讀,對于鎖定讀(select with for update 或者 for share)、update 和 delete 語句, ? ? ? ? ? ? ? ? ? ? ? InnoDB 僅鎖定索引記錄,而不鎖定它們之間的間隙,因此允許在鎖定的記錄旁邊自由插入新記錄。 ? ? ? ? ? ? ? ? ? ? ? Gap locking 僅用于外鍵約束檢查和重復(fù)鍵檢查。REPEATABLE READ ? ? ? ?可重復(fù)讀,事務(wù)中的一致性讀取讀取的是事務(wù)第一次讀取所建立的快照。SERIALIZABLE ? ? ? ? ? 序列化
在了解了 4 種隔離級別的需求后,在采用鎖控制隔離級別的基礎(chǔ)上,我們需要了解加鎖的對象(數(shù)據(jù)本身間隙),以及了解整個數(shù)據(jù)范圍的全集組成。
數(shù)據(jù)范圍全集組成
SQL 語句根據(jù)條件判斷不需要掃描的數(shù)據(jù)范圍(不加鎖);
SQL 語句根據(jù)條件掃描到的可能需要加鎖的數(shù)據(jù)范圍;
以單個數(shù)據(jù)范圍為例,數(shù)據(jù)范圍全集包含:(數(shù)據(jù)范圍不一定是連續(xù)的值,也可能是間隔的值組成)
1. 數(shù)據(jù)已經(jīng)填充了整個數(shù)據(jù)范圍:(被完全填充的數(shù)據(jù)范圍,不存在數(shù)據(jù)間隙)
整形,對值具有唯一約束條件的數(shù)據(jù)范圍 1~5 ,
已有數(shù)據(jù)1、2、3、4、5,此時數(shù)據(jù)范圍已被完全填充;
整形,對值具有唯一約束條件的數(shù)據(jù)范圍 1 和 5 ,
已有數(shù)據(jù)1、5,此時數(shù)據(jù)范圍已被完全填充;
2. 數(shù)據(jù)填充了部分?jǐn)?shù)據(jù)范圍:(未被完全填充的數(shù)據(jù)范圍,是存在數(shù)據(jù)間隙)
整形的數(shù)據(jù)范圍 1~5 ,
已有數(shù)據(jù) 1、2、3、4、5,但是因為沒有唯一約束,
所以數(shù)據(jù)范圍可以繼續(xù)被 1~5 的數(shù)據(jù)重復(fù)填充;
整形,具有唯一約束條件的數(shù)據(jù)范圍 1~5 ,
已有數(shù)據(jù) 2,5,此時數(shù)據(jù)范圍未被完全填充,還可以填充 1、3、4 ;
3. 數(shù)據(jù)范圍內(nèi)沒有任何數(shù)據(jù)(存在間隙)
如下:
整形的數(shù)據(jù)范圍 1~5 ,數(shù)據(jù)范圍內(nèi)當(dāng)前沒有任何數(shù)據(jù)。
在了解了數(shù)據(jù)全集的組成后,我們再來看看事務(wù)并發(fā)時,會帶來的問題。
無控制的并發(fā)所帶來的問題
并發(fā)事務(wù)如果不加以控制的話會帶來一些問題,主要包括以下幾種情況。
1. 范圍內(nèi)已有數(shù)據(jù)更改導(dǎo)致的:
更新丟失:當(dāng)多個事務(wù)選擇了同一行,然后基于最初選定的值更新該行時,
由于每個事物不知道其他事務(wù)的存在,最后的更新就會覆蓋其他事務(wù)所做的更新;
臟讀: 一個事務(wù)正在對一條記錄做修改,這個事務(wù)完成并提交前,這條記錄就處于不一致狀態(tài)。
這時,另外一個事務(wù)也來讀取同一條記錄,如果不加控制,
第二個事務(wù)讀取了這些“臟”數(shù)據(jù),并據(jù)此做了進(jìn)一步的處理,就會產(chǎn)生提交的數(shù)據(jù)依賴關(guān)系。
這種現(xiàn)象就叫“臟讀”。
2. 范圍內(nèi)數(shù)據(jù)量發(fā)生了變化導(dǎo)致:
不可重復(fù)讀:一個事務(wù)在讀取某些數(shù)據(jù)后的某個時間,再次讀取以前讀過的數(shù)據(jù),
卻發(fā)現(xiàn)其讀出的數(shù)據(jù)已經(jīng)發(fā)生了改變,或者某些記錄已經(jīng)被刪除了。
這種現(xiàn)象就叫“不可重復(fù)讀”。
幻讀:一個事務(wù)按相同的查詢條件重新讀取以前檢索過的數(shù)據(jù),
卻發(fā)現(xiàn)其他事務(wù)插入了滿足其查詢條件的新數(shù)據(jù),這種現(xiàn)象稱為“幻讀”。
可以簡單的認(rèn)為滿足條件的數(shù)據(jù)量變化了。
因為無控制的并發(fā)會帶來一系列的問題,這些問題會導(dǎo)致無法滿足我們所需要的結(jié)果。因此我們需要控制并發(fā),以實現(xiàn)我們所期望的結(jié)果(隔離級別)。
MySQL 隔離級別的實現(xiàn)
InnoDB 通過加鎖的策略來支持這些隔離級別。
行鎖包含:
Record Locks
索引記錄鎖,索引記錄鎖始終鎖定索引記錄,即使表中未定義索引,
這種情況下,InnoDB 創(chuàng)建一個隱藏的聚簇索引,并使用該索引進(jìn)行記錄鎖定。
Gap Locks
間隙鎖是索引記錄之間的間隙上的鎖,或者對第一條記錄之前或者最后一條記錄之后的鎖。
間隙鎖是性能和并發(fā)之間權(quán)衡的一部分。
對于無間隙的數(shù)據(jù)范圍不需要間隙鎖,因為沒有間隙。
Next-Key Locks
索引記錄上的記錄鎖和索引記錄之前的 gap lock 的組合。
假設(shè)索引包含 10、11、13 和 20。
可能的next-key locks包括以下間隔,其中圓括號表示不包含間隔端點,方括號表示包含端點:
(負(fù)無窮大, 10] ? ?(10, 11] ? ?(11, 13] ? ?(13, 20] ? ?(20, 正無窮大) ? ? ? ?對于最后一個間隔,next-key將會鎖定索引中最大值的上方,
左右滑動進(jìn)行查看
"上確界"偽記錄的值高于索引中任何實際值。
上確界不是一個真正的索引記錄,因此,實際上,這個 next-key 只鎖定最大索引值之后的間隙。
基于此,當(dāng)獲取的數(shù)據(jù)范圍中,數(shù)據(jù)已填充了所有的數(shù)據(jù)范圍,那么此時是不存在間隙的,也就不需要 gap lock。
對于數(shù)據(jù)范圍內(nèi)存在間隙的,需要根據(jù)隔離級別確認(rèn)是否對間隙加鎖。
默認(rèn)的 REPEATABLE READ 隔離級別,為了保證可重復(fù)讀,除了對數(shù)據(jù)本身加鎖以外,還需要對數(shù)據(jù)間隙加鎖。
READ COMMITTED 已提交讀,不匹配行的記錄鎖在 MySQL 評估了 where 條件后釋放。
對于 update 語句,InnoDB 執(zhí)行 "semi-consistent" 讀取,這樣它會將最新提交的版本返回到 MySQL,
以便 MySQL 可以確定該行是否與 update 的 where 條件相匹配。
總結(jié)延展:
唯一索引存在唯一約束,所以變更后的數(shù)據(jù)若違反了唯一約束的原則,則會失敗。
當(dāng) where 條件使用二級索引篩選數(shù)據(jù)時,會對二級索引命中的條目和對應(yīng)的聚簇索引都加鎖;所以其他事務(wù)變更命中加鎖的聚簇索引時,都會等待鎖。
行鎖的增加是一行一行增加的,所以可能導(dǎo)致并發(fā)情況下死鎖的發(fā)生。
例如,
在 session A 對符合條件的某聚簇索引加鎖時,可能 session B 已持有該聚簇索引的 Record Locks,而 session B 正在等待 session A 已持有的某聚簇索引的 Record Locks。
session A 和 session B 是通過兩個不相干的二級索引定位到的聚簇索引。
session A 通過索引 idA,session B通過索引 idB 。
當(dāng) where 條件獲取的數(shù)據(jù)無間隙時,無論隔離級別為 rc 或 rr,都不會存在間隙鎖。
比如通過唯一索引獲取到了已完全填充的數(shù)據(jù)范圍,此時不需要間隙鎖。
間隙鎖的目的在于阻止數(shù)據(jù)插入間隙,所以無論是通過 insert 或 update 變更導(dǎo)致的間隙內(nèi)數(shù)據(jù)的存在,都會被阻止。
rc 隔離級別模式下,查詢和索引掃描將禁用 gap locking,此時 gap locking 僅用于外鍵約束檢查和重復(fù)鍵檢查(主要是唯一性檢查)。
rr 模式下,為了防止幻讀,會加上 Gap Locks。
事務(wù)中,SQL 開始則加鎖,事務(wù)結(jié)束才釋放鎖。
就鎖類型而言,應(yīng)該有優(yōu)化鎖,鎖升級等,例如rr模式未使用索引查詢的情況下,是否可以直接升級為表鎖。
就鎖的應(yīng)用場景而言,在回放場景中,如果確定事務(wù)可并發(fā),則可以考慮不加鎖,加快回放速度。
鎖只是并發(fā)控制的一種粒度,只是一個很小的部分:
從不同場景下是否需要控制并發(fā),(已知無交集且有序的數(shù)據(jù)的變更,MySQL 的 MTS 相同前置事務(wù)的多事務(wù)并發(fā)回放)
并發(fā)控制的粒度,(鎖是一種邏輯粒度,可能還存在物理層和其他邏輯粒度或方式)
相同粒度下的優(yōu)化,(鎖本身存在優(yōu)化,如IX、IS類型的優(yōu)化鎖)
粒度加載的安全性能(如獲取行鎖前,先獲取頁鎖,頁鎖在執(zhí)行獲取行鎖操作后即釋放,無論是否獲取成功)等多個層次去思考并發(fā)這玩意。
關(guān)于mysql中的樂觀鎖和悲觀鎖面試的時候被問到的概率還是比較大的。
mysql的悲觀鎖:
其實理解起來非常簡單,當(dāng)數(shù)據(jù)被外界修改持保守態(tài)度,包括自身系統(tǒng)當(dāng)前的其他事務(wù),以及來自外部系統(tǒng)的事務(wù)處理,因此,在整個數(shù)據(jù)處理過程中,將數(shù)據(jù)處于鎖定狀態(tài)。悲觀鎖的實現(xiàn),往往依靠數(shù)據(jù)庫提供的鎖機(jī)制,但是也只有數(shù)據(jù)庫層提供的鎖機(jī)制才能真正保證數(shù)據(jù)訪問的排他性,否則,即使在自身系統(tǒng)中實現(xiàn)了加鎖機(jī)制,也無法保證外部系統(tǒng)不會修改數(shù)據(jù)。
來點實際的,當(dāng)我們使用悲觀鎖的時候我們首先必須關(guān)閉mysql數(shù)據(jù)庫的自動提交屬性,因為MySQL默認(rèn)使用autocommit模式,也就是說,當(dāng)你執(zhí)行一個更新操作后,MySQL會立刻將結(jié)果進(jìn)行提交。
關(guān)閉命令為:set autocommit=0;
悲觀鎖可以使用select…for update實現(xiàn),在執(zhí)行的時候會鎖定數(shù)據(jù),雖然會鎖定數(shù)據(jù),但是不影響其他事務(wù)的普通查詢使用。此處說普通查詢就是平時我們用的:select * from table 語句。在我們使用悲觀鎖的時候事務(wù)中的語句例如:
//開始事務(wù)
begin;/begin work;/start transaction; (三選一)
//查詢信息
select * from order where id=1 for update;
//修改信息
update order set name='names';
//提交事務(wù)
commit;/commit work;(二選一)
此處的查詢語句for update關(guān)鍵字,在事務(wù)中只有SELECT ... FOR UPDATE 或LOCK IN SHARE MODE 同一條數(shù)據(jù)時會等待其它事務(wù)結(jié)束后才執(zhí)行,一般的SELECT查詢則不受影響。
執(zhí)行事務(wù)時關(guān)鍵字select…for update會鎖定數(shù)據(jù),防止其他事務(wù)更改數(shù)據(jù)。但是鎖定數(shù)據(jù)也是有規(guī)則的。
查詢條件與鎖定范圍:
1、具體的主鍵值為查詢條件
比如查詢條件為主鍵ID=1等等,如果此條數(shù)據(jù)存在,則鎖定當(dāng)前行數(shù)據(jù),如果不存在,則不鎖定。
2、不具體的主鍵值為查詢條件
比如查詢條件為主鍵ID1等等,此時會鎖定整張數(shù)據(jù)表。
3、查詢條件中無主鍵
會鎖定整張數(shù)據(jù)表。
4、如果查詢條件中使用了索引為查詢條件
明確指定索引并且查到,則鎖定整條數(shù)據(jù)。如果找不到指定索引數(shù)據(jù),則不加鎖。
悲觀鎖的確保了數(shù)據(jù)的安全性,在數(shù)據(jù)被操作的時候鎖定數(shù)據(jù)不被訪問,但是這樣會帶來很大的性能問題。因此悲觀鎖在實際開發(fā)中使用是相對比較少的。
mysql的樂觀鎖:
相對悲觀鎖而言,樂觀鎖假設(shè)數(shù)據(jù)一般情況下不會造成沖突,所以在數(shù)據(jù)進(jìn)行提交更新的時候,才會對數(shù)據(jù)的沖突與否進(jìn)行檢測,如果發(fā)現(xiàn)沖突,則讓返回用戶錯誤的信息,讓用戶決定如何去做。
一般來說,實現(xiàn)樂觀鎖的方法是在數(shù)據(jù)表中增加一個version字段,每當(dāng)數(shù)據(jù)更新的時候這個字段執(zhí)行加1操作。這樣當(dāng)數(shù)據(jù)更改的時候,另外一個事務(wù)訪問此條數(shù)據(jù)進(jìn)行更改的話就會操作失敗,從而避免了并發(fā)操作錯誤。當(dāng)然,還可以將version字段改為時間戳,不過原理都是一樣的。
例如有表student,字段:
id,name,version
1 a 1
當(dāng)事務(wù)一進(jìn)行更新操作:update student set name='ygz' where id = #{id} and version = #{version};
此時操作完后數(shù)據(jù)會變?yōu)閕d = 1,name = ygz,version = 2,當(dāng)另外一個事務(wù)二同樣執(zhí)行更新操作的時候,卻發(fā)現(xiàn)version != 1,此時事務(wù)二就會操作失敗,從而保證了數(shù)據(jù)的正確性。
悲觀鎖和樂觀鎖都是要根據(jù)具體業(yè)務(wù)來選擇使用,本文僅作簡單介紹。
你說的這個version是mysql底層的鎖機(jī)制提供的,并不是java提供的。
使用數(shù)據(jù)版本(Version)記錄機(jī)制實現(xiàn),這是mysql樂觀鎖最常用的一種實現(xiàn)方式。所謂的數(shù)據(jù)版本就是給數(shù)據(jù)增加一個版本標(biāo)識,一般是通過為數(shù)據(jù)庫表增加一個數(shù)字類型的 “version” 字段來實現(xiàn)。當(dāng)讀取數(shù)據(jù)時,將version字段的值一同讀出,數(shù)據(jù)每更新一次,對此version值加1。當(dāng)我們提交更新的時候,判斷數(shù)據(jù)庫表對應(yīng)記錄的當(dāng)前版本信息與第一次取出來的version值進(jìn)行比對,如果數(shù)據(jù)庫表當(dāng)前版本號與第一次取出來的version值相等,則予以更新,否則認(rèn)為是過期數(shù)據(jù),版本號重新讀取再做更新。
以上不是重點,重點是 對事務(wù)控制語句不熟悉。
SAVEPOINT identifier : 在事務(wù)中 創(chuàng)建保存點。一個事務(wù)中 允許有多個保存點。
RELEASE SAVEPOINT identifier : 刪除保存點。當(dāng)事務(wù)中 沒有指定的 保存點,執(zhí)行該語句 會拋異常。
ROLLBACK TO identifier : 把事務(wù)回滾到 保存點。
Say you have a table T with a column C with one row in it, say it has the value '1'. And consider you have a simple task like following:
That is a simple task that issue two reads from table T, with a delay of 1 minute between them.
If you follow the logic above you can quickly realize that SERIALIZABLE transactions, while they may make life easy for you, are always completely blocking every possible concurrent operation, since they require that nobody can modify, delete nor insert any row. The default transaction isolation level of the .Net System.Transactions scope is serializable, and this usually explains the abysmal performance that results.
在Repeatable Read隔離級別下,一個事務(wù)可能會遇到幻讀(Phantom Read)的問題。
幻讀是指,在一個事務(wù)中,第一次查詢某條記錄,發(fā)現(xiàn)沒有,但是,當(dāng)試圖更新這條不存在的記錄時,竟然能成功,并且,再次讀取同一條記錄,它就神奇地出現(xiàn)了。
我們?nèi)匀幌葴?zhǔn)備好students表的數(shù)據(jù):
然后,分別開啟兩個MySQL客戶端連接,按順序依次執(zhí)行事務(wù)A和事務(wù)B:
事務(wù)B在第3步第一次讀取id=99的記錄時,讀到的記錄為空,說明不存在id=99的記錄。隨后,事務(wù)A在第4步插入了一條id=99的記錄并提交。事務(wù)B在第6步再次讀取id=99的記錄時,讀到的記錄仍然為空,但是,事務(wù)B在第7步試圖更新這條不存在的記錄時,竟然成功了,并且,事務(wù)B在第8步再次讀取id=99的記錄時,記錄出現(xiàn)了。
可見,幻讀就是沒有讀到的記錄,以為不存在,但其實是可以更新成功的,并且,更新成功后,再次讀取,就出現(xiàn)了。
在沖突較少的情況下,使用樂觀鎖。樂觀鎖 因為沒有 加鎖 釋放鎖,也減少了 加鎖 釋放鎖的開銷。
沖突較多時,如果使用樂觀鎖 需要不停地嘗試,所以 使用悲觀鎖。
如果樂觀鎖 進(jìn)行嘗試時 的花銷較大,也是使用悲觀鎖。
樂觀鎖就是認(rèn)為不會產(chǎn)生數(shù)據(jù)訪問沖突。比如update
修改商品status為2
update t_goods
set status=2,version=version+1
where id=#{id} and version=#{version};