面試官一口氣問了MySQL事務、鎖和MVCC,我

Java3y發表於2021-10-09

面試官你是怎麼理解InnoDB引擎中的事務的?

候選者:在我的理解下,事務可以使「一組操作」要麼全部成功,要麼全部失敗

候選者:事務其目的是為了「保證資料最終的一致性」。

候選者:舉個例子,我給你發支付寶轉了888塊紅包。那自然我的支付寶餘額會扣減888塊,你的支付寶餘額會增加888塊。

候選者:而事務就是保證我的餘額扣減跟你的餘額增添是同時成功或者同時失敗的,這樣這次轉賬就正常了

面試官嗯,那你瞭解事務的幾大特性嗎?

候選者:嗯,就是ACID嘛,分別是原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)、永續性(Durability)。

候選者:原子性指的是:當前事務的操作要麼同時成功,要麼同時失敗。原子性由undo log日誌來保證,因為undo log記載著資料修改前的資訊。

候選者:比如我們要 insert 一條資料了,那undo log 會記錄的一條對應的 delete 日誌。我們要 update 一條記錄時,那undo log會記錄之前的「舊值」的update記錄。

候選者:如果執行事務過程中出現異常的情況,那執行「回滾」。InnoDB引擎就是利用undo log記錄下的資料,來將資料「恢復」到事務開始之前

候選者:一致性我稍稍往後講,我先來說下隔離性

面試官:嗯…

候選者:隔離性指的是:在事務「併發」執行時,他們內部的操作不能互相干擾。如果多個事務可以同時操作一個資料,那麼就會產生髒讀、重複讀、幻讀的問題。

候選者:於是,事務與事務之間需要存在「一定」的隔離。在InnoDB引擎中,定義了四種隔離級別供我們使用:

候選者:分別是:read uncommit(讀未提交)、read commit (讀已提交)、repeatable read (可重複復讀)、serializable (序列)

候選者:不同的隔離級別對事務之間的隔離性是不一樣的(級別越高事務隔離性越好,但效能就越低),而隔離性是由MySQL的各種鎖來實現的,只是它遮蔽了加鎖的細節。

候選者:永續性指的就是:一旦提交了事務,它對資料庫的改變就應該是永久性的。說白了就是,會將資料持久化在硬碟上。

候選者:而永續性由redo log 日誌來保證,當我們要修改資料時,MySQL是先把這條記錄所在的「頁」找到,然後把該頁載入到記憶體中,將對應記錄進行修改。

候選者:為了防止記憶體修改完了,MySQL就掛掉了(如果記憶體改完,直接掛掉,那這次的修改相當於就丟失了)。

候選者:MySQL引入了redo log,記憶體寫完了,然後會寫一份redo log,這份redo log記載著這次在某個頁上做了什麼修改。

候選者:即便MySQL在中途掛了,我們還可以根據redo log來對資料進行恢復。

候選者:redo log 是順序寫的,寫入速度很快。並且它記錄的是物理修改(xxxx頁做了xxx修改),檔案的體積很小,恢復速度也很快。

候選者:回頭再來講一致性,「一致性」可以理解為我們使用事務的「目的」,而「隔離性」「原子性」「永續性」均是為了保障「一致性」的手段,保證一致性需要由應用程式程式碼來保證

候選者:比如,如果事務在發生的過程中,出現了異常情況,此時你就得回滾事務,而不是強行提交事務來導致資料不一致。

面試官:嗯,挺好的,講了蠻多的

面試官:剛才你也提到了隔離性嘛,然後你說在MySQL中有四種隔離級別,能分別來介紹下嗎?

候選者:嗯,為了講清楚隔離級別,我順帶來說下MySQL鎖相關的知識吧。

候選者:在InnoDB引擎下,按鎖的粒度分類,可以簡單分為行鎖和表鎖。

候選者:行鎖實際上是作用在索引之上的(索引上次已經說過了,這裡就不贅述了)。當我們的SQL命中了索引,那鎖住的就是命中條件內的索引節點(這種就是行鎖),如果沒有命中索引,那我們鎖的就是整個索引樹(表鎖)。

候選者:簡單來說就是:鎖住的是整棵樹還是某幾個節點,完全取決於SQL條件是否有命中到對應的索引節點。

候選者:而行鎖又可以簡單分為讀鎖(共享鎖、S鎖)和寫鎖(排它鎖、X鎖)。

候選者:讀鎖是共享的,多個事務可以同時讀取同一個資源,但不允許其他事務修改。寫鎖是排他的,寫鎖會阻塞其他的寫鎖和讀鎖。

候選者:我現在就再回到隔離級別上吧,就直接以例子來說明啦。

面試官:嗯…

候選者:首先來說下read uncommit(讀未提交)。比如說:A向B轉賬,A執行了轉賬語句,但A還沒有提交事務,B讀取資料,發現自己賬戶錢變多了!B跟A說,我已經收到錢了。A回滾事務【rollback】,等B再檢視賬戶的錢時,發現錢並沒有多。

候選者:簡單的定義就是:事務B讀取到了事務A還沒提交的資料,這種用專業術語來說叫做「髒讀」。

候選者:對於鎖的維度而言,其實就是在read uncommit隔離級別下,讀不會加任何鎖,而寫會加排他鎖。讀什麼鎖都不加,這就讓排他鎖無法排它了。

候選者:而我們又知道,對於更新操作而言,InnoDB是肯定會加寫鎖的(資料庫是不可能允許在同一時間,更新同一條記錄的)。而讀操作,如果不加任何鎖,那就會造成上面的髒讀。

候選者:髒讀在生產環境下肯定是無法接受的,那如果讀加鎖的話,那意味著:當更新資料的時,就沒辦法讀取了,這會極大地降低資料庫效能。

候選者:在MySQL InnoDB引擎層面,又有新的解決方案(解決加鎖後讀寫效能問題),叫做MVCC(Multi-Version Concurrency Control)多版本併發控制

候選者:在MVCC下,就可以做到讀寫不阻塞,且避免了類似髒讀這樣的問題。那MVCC是怎麼做的呢?

候選者:MVCC通過生成資料快照(Snapshot),並用這個快照來提供一定級別(語句級或事務級)的一致性讀取

候選者:回到事務隔離級別下,針對於 read commit (讀已提交) 隔離級別,它生成的就是語句級快照,而針對於repeatable read (可重複讀),它生成的就是事務級的快照。

候選者:前面提到過read uncommit隔離級別下會產生髒讀,而read commit (讀已提交) 隔離級別解決了髒讀。思想其實很簡單:在讀取的時候生成一個”版本號”,等到其他事務commit了之後,才會讀取最新已commit的”版本號”資料。

候選者:比如說:事務A讀取了記錄(生成版本號),事務B修改了記錄(此時加了寫鎖),事務A再讀取的時候,是依據最新的版本號來讀取的(當事務B執行commit了之後,會生成一個新的版本號),如果事務B還沒有commit,那事務A讀取的還是之前版本號的資料。

候選者:通過「版本」的概念,這樣就解決了髒讀的問題,而「版本」其實就是對應快照的資料。

候選者:read commit (讀已提交) 解決了髒讀,但也會有其他併發的問題。「不可重複讀」:一個事務讀取到另外一個事務已經提交的資料,也就是說一個事務可以看到其他事務所做的修改。

候選者:不可重複讀的例子:A查詢資料庫得到資料,B去修改資料庫的資料,導致A多次查詢資料庫的結果都不一樣【危害:A每次查詢的結果都是受B的影響的】

候選者:瞭解MVCC基礎之後,就很容易想到repeatable read (可重複復讀)隔離級別是怎麼避免不可重複讀的問題了(前面也提到了)。

候選者:repeatable read (可重複復讀)隔離級別是「事務級別」的快照!每次讀取的都是「當前事務的版本」,即使當前資料被其他事務修改了(commit),也只會讀取當前事務版本的資料。

候選者:而repeatable read (可重複復讀)隔離級別會存在幻讀的問題,「幻讀」指的是指在一個事務內讀取到了別的事務插入的資料,導致前後讀取不一致。

候選者:在InnoDB引擎下的的repeatable read (可重複復讀)隔離級別下,快照讀MVCC影響下,已經解決了幻讀的問題(因為它是讀歷史版本的資料)

候選者:而如果是當前讀(指的是 select * from table for update),則需要配合間隙鎖來解決幻讀的問題。

候選者:剩下的就是serializable (序列)隔離級別了,它的最高的隔離級別,相當於不允許事務的併發,事務與事務之間執行是序列的,它的效率最低,但同時也是最安全的。

面試官:嗯,可以的。我看你提到了MVCC了,不妨來說下他的原理?

候選者:MVCC的主要是通過read view和undo log來實現的

候選者:undo log前面也提到了,它會記錄修改資料之前的資訊,事務中的原子性就是通過undo log來實現的。所以,有undo log可以幫我們找到「版本」的資料

候選者:而read view 實際上就是在查詢時,InnoDB會生成一個read view,read view 有幾個重要的欄位,分別是:trx_ids(尚未提交commit的事務版本號集合),low_limit_id(下一次要生成的事務ID值),low_limit_id(尚未提交版本號的事務ID最小值)以及creator_trx_id(當前的事務版本號)

候選者:在每行資料有兩列隱藏的欄位,分別是DB_TRX_ID(記錄著當前ID)以及DB_ROLL_PTR(指向上一個版本資料在undo log 裡的位置指標)

候選者:鋪墊到這了,很容易就發現,MVCC其實就是靠「比對版本」來實現讀寫不阻塞,而版本的資料存在於undo log中。

候選者:而針對於不同的隔離級別(read commit和repeatable read),無非就是read commit隔離級別下,每次都獲取一個新的read view,repeatable read隔離級別則每次事務只獲取一個read view

面試官:嗯,OK的。細節就不考究了,今天就到這裡吧。

本文總結

  • 事務為了保證資料的最終一致性
  • 事務有四大特性,分別是原子性、一致性、隔離性、永續性

    • 原子性由undo log保證
    • 永續性由redo log 保證
    • 隔離性由資料庫隔離級別供我們選擇,分別有read uncommit,read commit,repeatable read,serializable
    • 一致性是事務的目的,一致性由應用程式來保證
  • 事務併發會存在各種問題,分別有髒讀、重複讀、幻讀問題。上面的不同隔離級別可以解決掉由於併發事務所造成的問題,而隔離級別實際上就是由MySQL鎖來實現的
  • 頻繁加鎖會導致資料庫效能低下,引入了MVCC多版本控制來實現讀寫不阻塞,提高資料庫效能
  • MVCC原理即通過read view 以及undo log來實現

歡迎關注我的微信公眾號【Java3y】來聊聊Java面試

【對線面試官-移動端】系列 一週兩篇持續更新中!
【對線面試官-電腦端】系列 一週兩篇持續更新中!

原創不易!!求三連!!

相關文章