大家好,我是冰河~~
相信大部分小伙伴在面試程序中,只會針對面試官提出的表面問題來進行回答,其實不然,面試官問的每一個問題都是經過深思熟慮的,面試的時間相對來說也是短暫的,面試官不可能在很短的時間內就對你非常了解,他想通過幾個問題來考察你所掌握的知識的深度和廣度,如果你只是回答面試官表面問你的問題,向擠牙膏一樣,問一點,答一點,結果不用說,肯定是涼涼了,
面試問題
說說什么是事務?并發事務會帶來哪些問題呢?
分析問題
表面上看,面試官是問了兩個問題,一個是:什么是事務,也就是讓你說說事務的基本概念;另一個是:并發事務會帶來哪些問題,
實則不然,聽到面試官這樣問,你不要隨意回答,要用極短的時間思考一下,面試官究竟想要得到什么答案,
對于第一個問題:說說什么是事務?就只是讓你簡單的說說事務的基本概念嗎?基本概念相信是個學過資料庫的小學生都會,面試官為什么會問你這個問題呢?此時,你需要揣測面試官的心理,此時的面試官其實想問你的不久是事務的基本概念,而且他也想讓你說出事務的特性,也就是四大屬性,這才是這個問題的核心所在!
對于第二個問題:并發事務會帶來哪些問題呢?就只是想問一下會帶來哪些問題嗎?知道問題,不知道如何解決問題,這樣的面試者面試官能要嗎?究其本質,面試官是想問你并發事務會帶來哪些問題,有哪些解決方案能夠解決這些問題!這才是面試官想要的答案!
綜上,面試官本質上問的問題是:什么是事務?事務的四大特性是什么?并發事務會帶來哪些問題?有哪些解決方案?你只有深刻理解了面試官提問的本質,才能更好的回答面試官所提出的問題,不然,你應付面試官,面試官也會應付你,
什么是事務?
事務的概念理解起來還比較簡單的:事務是指作為單個邏輯作業單元執行的一系列操作,要么完全地執行,要么完全地不執行, 事務處理可以確保除非事務性單元內的所有操作都成功完成,否則不會永久更新面向資料的資源,通過將一組相關操作組合為一個要么全部成功要么全部失敗的單元,可以簡化錯誤恢復并使應用程式更加可靠,一個邏輯作業單元要成為事務,必須滿足所謂的ACID(原子性、一致性、隔離性和持久性)屬性,事務是資料庫運行中的邏輯作業單位,由DBMS中的事務管理子系統負責事務的處理,
事務的四大特性
原子性(Atomicity)
事務必須是原子作業單元;對于其資料修改,要么全都執行,要么全都不執行,比如轉賬,要么轉賬成功,賬戶余額增加(減少);要么轉賬失敗,賬戶余額不變,
一致性(Consistency)
事務在完成時,必須使所有的資料都保持一致狀態,在相關資料庫中,所有規則都必須應用于事務的修改,以保持所有資料的完整性,事務結束時,所有的內部資料結構(如 B 樹索引或雙向鏈表)都必須是正確的,某些維護一致性的責任由應用程式開發人員承擔,他們必須確保應用程式已強制所有已知的完整性約束,例如,當開發用于轉帳的應用程式時,應避免在轉帳程序中任意移動小數點,
隔離性(Isolation)
由并發事務所作的修改必須與任何其它并發事務所作的修改隔離,事務查看資料時資料所處的狀態,要么是另一并發事務修改它之前的狀態,要么是另一事務修改它之后的狀態,事務不會查看中間狀態的資料,這稱為隔離性,因為它能夠重新裝載起始資料,并且重播一系列事務,以使資料結束時的狀態與原始事務執行的狀態相同,當事務可序列化時將獲得最高的隔離級別,在此級別上,從一組可并行執行的事務獲得的結果與通過連續運行每個事務所獲得的結果相同,由于高度隔離會限制可并行執行的事務數,所以一些應用程式降低隔離級別以換取更大的吞吐量,
持久性(Durability)
事務完成之后,它對于系統的影響是永久性的,該修改即使出現致命的系統故障也將一直保持,
例如我們在使用JDBC操作資料庫時,在提交事務方法后,提示用戶事務操作完成,當我們程式執行完成直到看到提示后,就可以認定事務以及正確提交,即使這時候資料庫出現了問題,也必須要將我們的事務完全執行完成,否則就會造成我們看到提示事務處理完畢,但是資料庫因為故障而沒有執行事務的重大錯誤,
并發事務帶來的問題
臟寫問題
當兩個或多個事務選擇同一行,然后基于最初選定的值更新該行時,會發生丟失更新問題,每個事務都不知道其它事務的存在,最后的更新將重寫由其它事務所做的更新,這將導致資料丟失,
例如,T1和T2同時修改一條資料,T2的修改覆寫了T1的修改;如果在T1之后T2才能進行更改,則可以避免該問題,
我們來看一個經典的轉賬問題,開始小明和小剛都有1000元錢,在事務T1中,小明為小剛轉賬100元,在事務T2中,小剛為小明轉賬200元,則正常情況下,結果為:小明有1100元,小剛為900元,如果發生了臟寫的問題,則結果可能為:小明1200元,小剛800元,如下圖所示,

臟讀問題
一個事務正在對一條記錄做修改,在這個事務完成并提交前,這條記錄的資料就處于不一致狀態;這時,另一個事務也來讀取同一條記錄,如果不加控制,第二個事務讀取了這些“臟”資料,并據此做進一步的處理,就會產生未提交的資料依賴關系,這種現象被形象地叫做”臟讀”,
例如:在事務T1中,小明為小剛轉賬100元,在轉賬的程序中,事務未提交或者未回滾時,此時事務T2讀取到了事務T1未提交的內容,也就是說在事務T2中讀取到了小明900元,小剛1100元的記錄,可以用下圖表示,

不可重復讀問題
一個事務在讀取某些資料后的某個時間,再次讀取以前讀過的資料,卻發現其讀出的資料已經發生了改變!這種現象就叫做“不可重復讀”,
指事務T2讀取資料后,事務T1執行更新操作,使T2無法讀取前一次結果,
例如,在事務T1中執行小明為小剛轉賬100元的操作,在事務未提交之前,在事務T2中讀取的資料還是小明為1000元,小剛為1000元,待事務T1提交后,事務T2中讀取的資料為小明900元,小剛1100元,如下圖所示,

幻讀問題
一個事務按相同的查詢條件重新讀取以前檢索過的資料,卻發現其他事務插入了滿足其查詢條件的新資料,這種現象就稱為“幻讀”,
事務t2讀取到了事務t1體提交的新增、洗掉資料,不符合隔離性,
幻讀和不可重復讀都是讀取了另一條已經提交的事務(這點就臟讀不同),所不同的是不可重復讀查詢的都是同一個資料項,而幻讀針對的是一批資料整體(比如資料的個數),
例如,在事務T1中插入兩條分別為小明和小剛的資料,在事務提交之前,事務T2中讀取的資料記錄為10,隨后事務T1提交,則在事務T2中讀取的記錄為12,如下所示,

并發事務問題的解決方案
為了避免上面出現的幾種情況,在標準SQL規范中,定義了4個事務隔離級別,不同的隔離級別對事務的處理不同,以下四種不同的隔離級別限制由低到高,性能從高到底,
讀未提交
讀未提交(Read Uncommitted):允許臟讀取,但不允許更新丟失,如果一個事務已經開始寫資料,則另外一個事務則不允許同時進行寫操作,但允許其他事務讀此行資料,該隔離級別可以通過“排他寫鎖”實作,
不可避免 臟讀、不可重復讀、虛讀,
讀已提交
讀已提交(Read Committed):允許不可重復讀取,但不允許臟讀取,這可以通過“瞬間共享讀鎖”和“排他寫鎖”實作,讀取資料的事務允許其他事務繼續訪問該行資料,但是未提交的寫事務將會禁止其他事務訪問該行,
可避免 臟讀,不可避免 不可重復讀、虛讀,Oracle采用讀已提交,
可重復度
可重復讀取(Repeatable Read):禁止不可重復讀取和臟讀取,但是有時可能出現幻讀資料,這可以通過“共享讀鎖”和“排他寫鎖”實作,讀取資料的事務將會禁止寫事務(但允許讀事務),寫事務則禁止任何其他事務,
可避免 臟讀、不可重復讀, 不可避免 虛讀,MySQL采用可重復讀,
序列化
序列化(Serializable):提供嚴格的事務隔離,它要求事務序列化執行,事務只能一個接著一個地執行,不能并發執行,僅僅通過“行級鎖”是無法實作事務序列化的,必須通過其他機制保證新插入的資料不會被剛執行查詢操作的事務訪問到,
可避免 臟讀、不可重復讀、幻讀情況的發生,
事務的四種隔離級別總結起來如下圖所示,

常看當前資料庫的事務隔離級別: show variables like ‘tx_isolation’;
設定事務隔離級別:set tx_isolation=‘REPEATABLE-READ’;
Mysql默認的事務隔離級別是可重復讀,用Spring開發程式時,如果不設定隔離級別默認用Mysql設定的隔離級別,如果Spring設定了就用已經設定的隔離級別
領取福利
CSDN上私信冰河:
- 回復【并發編程】領取冰河原創全網累計下載 40W+ 的《深入理解高并發編程》電子書,
- 回復【滲透筆記】獲取冰河最新發布的《冰河的滲透實戰筆記》電子書,
寫在最后
如果你想進大廠,想升職加薪,或者對自己現有的作業比較迷茫,都可以私信我交流,希望我的一些經歷能夠幫助到大家~~
推薦閱讀:
-
《高并發場景下一種比讀寫鎖更快的鎖,看完我徹底折服了!!(建議收藏)》
-
《全網最全性能優化總結!!(冰河吐血整理,建議收藏)》
-
《三天擼完了MyBatis,各位隨便問!!(冰河吐血整理,建議收藏)》
-
《奉勸那些剛參加作業的學弟學妹們:要想進大廠,這些核心技能是你必須要掌握的!完整學習路線!!(建議收藏)》
-
《奉勸那些剛參加作業的學弟學妹們:這些計算機與作業系統基礎知識越早知道越好!萬字長文太頂了!!(建議收藏)》
-
《我用三天時間開發了一款老少皆宜的國民級游戲,支持播放音樂,現開放完整源代碼和注釋(建議收藏)!!》
-
《我是全網最硬核的高并發編程作者,CSDN最值得關注的博主,大家同意嗎?(建議收藏)》
-
《畢業五年,從月薪3000到年薪百萬,我掌握了哪些核心技能?(建議收藏)》
-
《我入侵了隔壁妹子的Wifi,發現,,,(全程實戰干貨,建議收藏)》
-
《千萬不要輕易嘗試“熊貓燒香”,這不,我后悔了!》
-
《清明節偷偷訓練“熊貓燒香”,結果我的電腦為熊貓“獻身了”!》
-
《7.3萬字肝爆Java8新特性,我不信你能看完!(建議收藏)》
-
《在業務高峰期拔掉服務器電源是一種怎樣的體驗?》
-
《全網最全Linux命令總結!!(史上最全,建議收藏)》
-
《用Python寫了個工具,完美破解了MySQL!!(建議收藏)》
-
《SimpleDateFormat類到底為啥不是執行緒安全的?(附六種解決方案,建議收藏)》
好了,今天就到這兒吧,小伙伴們點贊、收藏、評論,一鍵三連走起呀,我是冰河,我們下期見~~

轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/290707.html
標籤:其他
