介紹事務與分佈式事務原理與實踐、事務在Java程序中的應用

1、事務

一、事務的簡介

事務的本質核心就是鎖和併發。 事務只是讓傳統意義上難以理解的事情用一種更容易讓你們理解的方式來表述的方法。事務比傳統意義的鎖和併發更容易讓你們理解。

二、單個事務單元

• Bob給Smith100塊的一個事務案例會進行一下操做（圖1）：

（圖1）

1. 鎖定Bob帳戶
2. 鎖定smith帳戶
3. 查看Bob是否有100
4. 從Bob帳戶中減小100塊
5. 給Smith帳戶中增長100塊

當鎖定Bob帳戶和鎖定Smith帳戶以後，只有一個請求（一個線程）能夠進入到裏面去操做帳戶。線程2和線程3發現有鎖，只能在外面等待。上面的三、四、5均可以用線程1來完成。只有線程1能夠看到他們的中間狀態（三、四、5）。線程2和線程3都看不到中間狀態。在一個事務單元結束以前，其餘的線程只能等待在鎖外的。因此線程2和線程3只能看到要麼Bob帳戶中有錢，要麼Smith帳戶中有錢。

假設在從Bob帳戶中減小100塊的步驟結束後，就解除鎖的狀態，當線程2和線程3訪問Bob的帳戶和Smith的帳戶，就會發現Bob和Smith的帳戶都爲0，就會出現數據不一致的狀況（圖2）。

（圖2）

 

因此事務要保證的事情就是一致性，要麼Bom有100塊，要麼Smith有100塊（一致性）。Bob有100塊或者Smith有100塊的時候只要被線程2或線程3訪問到，就必須是持久的，不能在回退到以前的狀態（持久性）。這個過程就是一個事務單元。這個過程就能夠保證A（一致性）I（原子性）D（持久性）。

三、其餘的事務單元

1. 商品要創建一個基於GMT_Modified的索引。索引列建立的過程也是一個事務單元。
2. 從數據庫中讀取一行記錄。也是一個事務單元。
3. 向數據庫中寫入一行記錄，同時更新這行記錄的全部索引。也是一個事務單元。
4. 刪除整張表。
5. 針對於數據庫的每個操做能夠認爲都是一個事務。

四、一組事務單元（事務單元和事務單元的關係）

4.一、假設有三個帳戶（Bob帳戶、Smith帳戶、Joe帳戶）（圖3）：

1. 第一個事務單元：Bob給Smith100塊。在這個事務單元內要鎖住Bob的帳戶和鎖住Smith的帳戶，才能完成操做。在這個事務單元沒有完成的時候，第二個事務單元進入。
2. 第二個事務單元：Smith100給Joe100塊。這個事務單元會嘗試鎖住Smith和Joe的帳戶。由於Smith的帳戶被第一個事務單元鎖定，這個事務單元只能等待在外面直到第一個事務單元完成之後，第二個事務單元才能進行。
3. 第三個事務單元：Smith給Bob100塊。這個單元也會等在Bob和Smith的鎖上。

（圖3）

整個系統內會有三個事務單元，只有一個事務單元完成之後纔可讓其餘的事務單元進入到裏面拿到這把鎖。每個事務單元在運行的過程當中的時候，看到的數據不會出現中間狀態（Bob給Smith100塊，Bob減小了錢，而Smith沒有加上）。若是以這種方式考慮事務單元的關係，系統沒有辦法作到很清晰。事務單元的關係自己很是複雜。一些前輩就抽象了事務單元之間的關係（4.2章節）。

4.二、事務單元之間的Happy-before關係（抽象化的事務單元的關係）（圖4）：

1. 讀讀
2. 寫讀
3. 讀讀
4. 寫寫

（圖4）

把這四種狀態映射到全部的事務單元之間的關係，都是這四種狀態的重複（引自：事務處理）。  

4.三、如何最快速度完成多個事務單元

• 在知足的各類各樣事務單元之間的關係後，仍然可讓系統以很是快的速度運行。
• 在處理多個事務單元關係的時候，不會出現數據不一致的狀況。

4.3.一、排隊法：序列化讀寫 （把全部的請求放入隊列裏）SERIALIZABLE（圖5）：

（圖5）

優勢：不須要衝突控制。

缺點：慢速設備。若是一旦一個隊列裏的某一個請求很是慢，由於全部請求都不能並行，會致使系統性能很是低。

4.3.二、排他鎖：針對同一個單元的訪問進行控制（把一個隊列分散到不少隊列裏）（圖6）：

• 咱們能夠把一個隊列分散到許多隊列裏（用鎖來實現的）。

（圖6）

假設有3個事務單元。事務單元1鎖住了兩行記錄。事務單元2和3共享了一個事務記錄。只要保證事務單元數據沒有出現衝突，事務之間就不該該出現衝突。（好比：Bob給了Simth100塊，李雷給了韓梅梅100塊）。Bob給了Simth100塊，李雷給了韓梅梅100塊這兩個事務單元徹底沒有衝突。若是在徹底沒有衝突的狀況下，事務單元徹底能夠並行起來。所以

• 事務單元能夠出現並行的場景（Bob給了Simth100塊，李雷給了韓梅梅100塊。他們互不影響）（圖7）：

（圖7）

• 事務單元不能夠出現並行的場景（李雷給了韓梅梅100塊，韓梅梅給了李雷100塊。這兩個事務單元會共享數據）（圖8）：

（圖8）

結論：若是事務單元之間有可能發生衝突，就讓它們串行。若是不發生衝突，徹底能夠並行。實現這種方式只要在一個事務單元加鎖就能夠實現。只容許一個線程訪問。這種加鎖的方式，其它事務單元天然而然不會在上一個事務單元尚未結束前就能夠訪問。系統就能夠經過加鎖的方式來實現併發。同時又能夠實現讀讀、寫讀、讀寫、讀讀。在保證數據一致的狀況下，有沒有更好的辦法實現更高的速度呢？

4.3.三、讀寫鎖

事務單元之間的關係有四種場景：讀寫、寫讀、讀讀、寫寫。若是能夠把它們分離開，就可讓讀徹底並行。讀和讀的場景徹底並行，而寫讀、讀寫、寫寫仍然串行。對於讀多寫少的狀況下，能夠更近一步的提高系統性能。傳統數據庫主流的作法就是寫和讀之間徹底分開（圖9）。

（圖9）

由於、讀和讀的場景徹底並行，而寫讀、讀寫、寫寫仍然串行的狀況下，纔會出現隔離性的不一樣的隔離級別。

• 可序列化：讀寫放入隊列裏串行。
• 可重複讀：若是讀鎖後面有一個寫鎖，寫鎖就只能等待讀鎖釋放後才能進入本行記錄。若是第一次讀成功了之後，事務沒有釋放的狀況，在發生一次讀的事務，由於鎖沒有釋放，因此它仍然能夠讀到數據以前的狀態。由於後面的寫( W )尚未發生，它在外面等待。因此整個系統就能夠保證讀到的數據是上一次讀到的數據。可是可重複讀沒法作到讀寫並行，只能作到讀和讀之間的並行。若是是先讀後寫的場景是沒有辦法並行的。先寫後讀的場景也沒有辦法並行。（圖10）。

（圖10）

• 讀已提交：讀寫並行

把讀的鎖完全的去掉。讀的時候若是不加鎖，只有寫的時候加鎖（讀的時候若是有個新的鎖進來，就讓它進入）。系統的並行讀能夠進一步提高。代價就是第一次讀的時候，多是一條數據。第二次讀的是另外的數據。這個場景下能夠解決讀寫、讀讀的並行，但不能夠解決寫讀、寫寫的並行，寫寫、寫讀、仍然是串行的。由於每次寫的事務單元都是加鎖的。

總結：隔離性（I） 自己就是對於傳統數據庫的一致性的一種破壞。最強的一致性必定是讀寫放入隊列裏串行的。

4.3.四、MVCC（多版本併發控制）Copy on Write 寫不阻塞讀

當加了寫的操做的時候，系統徹底能夠併發讀。如今主流的數據庫都在使用這種方式。這種方式能夠作到寫讀不衝突、讀讀不衝突、讀寫不衝突。惟一衝突的就是寫和寫。這種方式併發度更高，實現起來更復雜。這個場景下能夠解決讀寫、讀讀寫讀、的並行，但不能夠寫寫的並行，寫寫仍然是串行的。（圖11）。

（圖11）

4.四、事務處理的常見問題

4.4.一、多個事務，誰先誰後？（圖12）

（圖12）

當發生寫的時候，數據庫就會記錄一個版本號。當讀的時候也會記錄一個版本號，當讀的版本號大於寫的版本號才能夠。

邏輯時間戳（只是保證前後順序）：Oracle ：SCN 。Innerdb ： Trx_id 。

內存裏面維持一個自增號，每一次寫的時候就把自增號+1。這樣就能夠讀到數據自己的最新值。若是讀的時候在一個事務內讀的話，內存裏自增號也會+1。經過自增的ID號就能夠保證事務自己的前後順序。

4.4.二、如何故障恢復？

   4.2.一、業務屬性不匹配（圖13）

（圖13）

當Bob的帳戶裏沒有100塊的時候，事務就須要回滾。須要記錄當前事務以前在作的全部操做的反向操做。這樣的狀況下。若是業務屬性出現問題，就能夠調用回滾的方式，來恢復到以前數據沒有發生到任何更改的狀態。

4.2.二、系統的崩潰（圖14）

（圖14）

當一個事務單元作完第四步（從Bob的帳戶中減小100元）第5步（給Smith的帳戶中增長100元）尚未來得及作的時候，整個系統崩潰了。必須須要再恢復回來。在進行數據恢復的時候尚未從故障中徹底恢復回來的時候，系統不可以被外部的其餘應用訪問的。 數據庫系統自己對外暴露一個監聽，爲了防止數據庫出現故障。

4.3.三、碰到死鎖了怎麼辦？

4.3.3.一、死鎖產生的緣由（圖15）

• 兩個線程
• 不一樣方向
• 相同資源

（圖15）

相互等待，相互又維持了一個鎖。

4.3.3.二、解決方案

一、儘量不死鎖（下降隔離級別：好比說讀不加鎖）。

二、碰撞檢測（終止一邊）（圖16）

（圖16）

三、等鎖超時

5、深刻單機事務

5.一、怎麼才能作到事務的ACID

• 原子性

仍是這個圖（Bom給Smith100塊的事務單元）。假設Bob帳戶有100塊，Smith帳戶有沒有錢，這樣就能夠把一個事務單元分紅多個步驟：

1. version 1 ：Bob有100元 Smith有0元
2. version 2 ：Bob有0元 Smith有0元
3. version 3 ：Bob有0塊 Smith有100元

第一個操做先檢查Bob帳戶有沒有100元，發現Bob有100塊，就會進入第二個操做（將Bob的錢取出100塊）。Bob的錢就爲0元。Smith的錢也是0。接着進入第三個步驟（將Bob的100塊加到Smith的帳戶中去）。Bob的錢就爲0元，Smith的錢爲100元。

任何系統內出現的故障，都有可能致使系統回滾。好比說在第二個版本會出現的問題是：若是Smith帳戶不存在的話，必須到回滾到第一個版本的狀態（Bob有100元，Smith有0元）。

若是在最後提交事務的時候超時了，事務就要回滾到第二步的狀態（Bob有0元，Smith有0元）

前面兩種回滾狀態都須要面對同一個問題，都須要知道回滾到哪裏去。數據庫就會加入回滾段，數據庫把這些回滾段記錄到單獨的地方去（如：日誌表）。在版本2的時候記錄一個回滾端（Bob有100元，Smith有0元）。若是第二個狀態須要回滾，只須要把undo的信息（Bob有100元，Smith有0元）直接回溯到這個帳戶上。

這就是原來事務處理自動化操做的一個逆向操做。

若是在第三個版本中，發現Commit沒有成功，就會先回滾到上一個版本（先把Smith的錢減掉）。接着再回滾到上一個版本（Bob有100元，Smith有0元）。這種操做就是原子性的保證（要麼所有成功，要麼所有失敗）。原子性操做不涉及到一致性相關問題的。原子性的語義只保證一個回滾段，這個回滾段能回滾到以前的版本。

若是有另外的一個事務進入到版本2的時候，把Smith的帳戶進行了修改（假設把Smith的錢加了300塊錢）。同時事務一出現了故障，進行回滾，回將Smth的錢改成0。這種狀況（在一致性不保證的狀況下）就會出現300塊錢丟失的問題。可是從原子性的定義來講，原子性不關心（care）這件事。

原子性只記錄了一個undo日誌回滾到以前的版本而已。

 

• 一致性

    一致性的核心就是Can(happen before)：

 

若是事務之間按照並列的關係來排列整個系統沒有任何一致性問題。

假如兩個事務同時發生的時候，就會有一致性問題（視點3）。：若是事務2出現問題以後進行回滾，兩個事務就會出現衝突的狀況（如：更新丟失、數據不一致問題）。

整個系統問題核心就是如何處理視點3（有讀的請求，也有寫的請求）（事務4）也就是如何處理不一樣事務以前的讀寫並行，就是處理一致性的部分。

一個事務單元要保證一個事務單元所有成功之後纔可見，這就是一致性的保證。若是說一個事務單元所有處理成功之後，下個事務才能進來，整個系統必定是一致性的。

可是這樣作的話系統的併發度明顯耗時。所以系統不的不選擇另一個概念，就是隔離性。

• 隔離性（隔離性就是以性能爲理由，對一致性的破壞。）

若是全部的事務都是（happy-before）的關係的時候絕對可以保證事務單元的強一致性。

若是利用這種方式進行操做的時候，全部的事務單元理論上說都是串行的（序列化）。序列化讀寫（排他鎖）串行就會很是嚴重的影響系統的性能。單位時間內只有一個事務單元可以進入。

性能差必定是認爲是不可取的。

有沒有更好的方式呢？：讀寫鎖：

一、可重複讀（Repeatable read）：

它的核心是讀寫鎖：一個很重要的概念是：讀鎖能不能被寫鎖升級。假如說對一個事務單元加一個讀鎖的狀況下，若是有一個寫寫進來，以前的讀鎖要不要放開，讓這個寫進去。假如讀鎖不打開，不讓寫進去。只能作到讀讀並行。這種狀況只能作到讀讀並行，不能完美的提高系統性能的。

二、讀以提交(Read Committed）：

就會出現幻讀和不可重複讀爲何會產生。讀已提交也是一個讀寫鎖，不同的是

讀鎖能夠被寫鎖升級。若是一個新寫鎖進來的時候，就能夠將原來的讀鎖升級爲寫鎖。    就會有一種新的模式：讀寫也能夠並行。這樣不少請求就能夠往前提了。每一次將請求往前提的過程就能夠認爲都是增長的並行的狀況。

在讀已提交的時候爲何會出現不可重複讀。？

讀寫並行的話會出現下面的場景：第一次讀取完成之後，讀到一條數據（版本號爲1），由於第二次寫是並行的，因此第二次寫會更新到這個數據。因而下個事務的讀在進來的時候 就會發現原來事務新的數據已經被更改過了。第一次讀數據和第二次讀的數據以前數據讀的版本是不一樣的。因而就會出現不可重複讀。由於讀鎖能夠升級爲寫鎖，就會出現同一個事務內的兩次讀可能會讀到不一樣版本的問題。

三、讀未提交：只加寫鎖，讀不加鎖。

讀讀並行、讀寫並行、寫讀也能夠並行。

所有的寫是串行的，全部的讀均可以並行。這種方式帶來的問題。

可能讀到寫過程當中的數據。可能會讀到內部沒有提交完成的數據。由於讀沒有加鎖。會讀到中間狀態的數據。

總結：

就是由於有讀寫鎖，而後這些讀寫鎖各類各樣的組合就會出現不一樣的隔離級別。由於有讀寫鎖，讀能不能升級，又被分出來兩個隔離級別：讀以提交，讀未提交。

隔離性小結：

四個不一樣的隔離級別是SQL92定義的標準的隔離性。

除了那四種標準的隔離級別以外，還有一種新的隔離級別出現：快照隔離級別（MVCC）。核心思路：無鎖編程。Copy on Write.

快照讀的核心方法（剛剛都是用鎖來實現的）：

事務開始以前的版本讓你先讀到。

• 持久性

每一次的寫都要落到磁盤上，保證數據的持久性。事務完成以後，該事務對數據庫的所作的更改便持久的保存在數據庫之中。

可是，如何保證數據不丟？：RAID特性：若是將數據只寫到1塊A磁盤，若是A磁盤壞了，數據仍然不會丟失呢？就在Copy一份數據到另一個磁盤上。

一、磁盤的物理損壞

二、

 

事務：多個不一樣的命令組裝到一塊兒的過程。

5.二、單機事務典型異常應對策略（實現事務過程當中會常常碰到的一些問題）

任何看起來相對簡單的東西，背後其實要考慮的因素，遠遠超過你如今所想象的。

一、業務屬性不匹配，須要回滾

二、系統的DOWN機：計算機就是個打字機。

若是走到第一步，當Lock的時候DOWN機了。

 

事務原子性操做只有一個標記：commit。若是commit以前全部的請求都要回滾。當commit完成的時候，以後的請求必須正常的提交完成而且必須可見。

數據庫重啓後進入recovery模式。會將提交後的事務單元繼續完成提交。未提交事務單元回滾。在這期間，整個系統是不能被訪問的。只有當全部recovery結束之後，將沒有提交的返回回去。將提交後的繼續完成。在這操做結束之後纔會真正開始提供外部訪問。（recovery過程也相似於原子操做，也必須保證ACID，只是實現方法不同）

若是recovery（恢復）的時候又掛了，在重啓須要繼續recovery。所以在recovery的時候也要記錄日誌，保證數據不會丟失。

 

5.三、事務的調優原則

一、減小鎖的覆蓋範圍。（Myisam表鎖 -->Innodb行鎖）。將一個大鎖變爲多個小鎖。

 

二、增長鎖上可並行的線程數。

三、選擇正確的鎖類型：

 

單機事務小結

一、讀寫比例比較高的狀況  MVCC

二、

三、

四、調優

 

2、單機事務拾遺

• 事務單元擴展

 

• 死鎖擴展 - U鎖

讀鎖。寫鎖分離

• MVCC拾遺

3、分佈式事務

一、分佈式事務的目標

像傳統單機事務同樣的操做方式。可按需無限擴展

二、分佈式事務與單機事務的相同點和不一樣點

 

三、傳統數據庫的分佈式事務

四、分佈式事務面臨的問題

二、分佈式事務流行的解決方案 (Google Spanner、DRDS/TDDL)

4、參考連接：