事務面試題

一  什麼是事務？有什麼用？

事務的特性ACID

事務提供了一種機制，可用來將一系列數據庫更改納入一個邏輯操做。更改數據庫後，所作的更改能夠做爲一個單元進行提交或取消。事務可確保遵循原子性、一致性、隔離性和持續性（ACID）這幾種屬性，以使數據可以正確地提交到數據庫中。

        1）原子性（Atomicity）原子性是指事務是一個不可分割的工做單位，事務中的操做 要麼都發生，要麼都不發生。

        2）一致性（Consistency）一個事務中，事務先後數據的完整性必須保持一致。

        3）隔離性（Isolation）多個事務，事務的隔離性是指多個用戶併發訪問數據庫時， 一個用戶的 事務不能被其它用戶的事務所幹擾，多個併發事務之間數據要相互隔離。

       4）持久性（Durability）持久性是指一個事務一旦被提交，它對數據庫中數據的改變 就是永久性的，接下來即便數據庫發生故障也不該該對其有任何影響。

 

二   事務的併發會產生的問題有哪些  

1.髒讀

一個事務正在對數據進行更新操做，可是更新還未提交，另外一個事務這時也來操做這組數據，而且讀取了前一個事務還未提交的數據，而前一個事務若是操做失敗進行了回滾，後一個事務讀取的就是錯誤的數據，這樣就形成了髒讀

2.不可重複讀

     一個事務屢次讀取同一個數據，在該事務還未結束時，另外一個事務也對該數據進行 了操做，並且在第一個事務兩次讀取之間，第二個事務對數據進行了更新，那麼第一個 事務先後兩個讀取到的數據是不一樣的，這樣就形成了不可重複讀

3.幻讀

第一個數據正在查詢某一條數據，這時，另外一個事務又插入了一條符合條件的數據，第一個事務在第二次查詢符合同一條件的數據時，發現多了一條前一次查詢時沒有的數據，彷彿幻覺同樣，這就是幻讀

 

三  不可重複讀和幻讀的區別

不可重複讀是指在同一查詢事務中屢次進行，因爲其餘提交事務所作的修改和刪除，每次返回不一樣的結果集，此時發生不可重複讀

幻讀是指在同一查詢事務中屢次進行，因爲其餘提交的事務所作的插入操做，每次返回不一樣的結果集，此時發生幻讀表面上看，區別就在於不可重複讀能看見其餘事務提交的修改和刪除，而幻讀能看見其餘事務提交的插入

 

四  spring 事務隔離級別

1.default：(默認)

默認隔離級別，使用數據庫默認的事務隔離級別

2.read_uncommitted:(讀未提交)

這是事務最低的隔離級別,他容許另一個事務能夠看到這個事務未提交的數據,這種隔離級別會產生髒讀,不可重複讀和幻讀

3.read_committed(讀已提交)

保證一個事務修改的數據提交後才能被另一個事務讀取,另一個事務不能讀取該事務未提交的數據.這種事務隔離級別能夠避免髒讀,可是可能會出現不可重複讀和幻讀

4.repeatable_read(可重複讀)

這種事務級別能夠防止髒讀,不可重複讀.可是可能出現幻讀.他除了保證一個事務不能讀取另外一個事務未提交的數據外,還保證了不可重複讀

5.Serializable 串行化

這是花費最高代價可是最可靠的事務隔離級別。事務被處理爲順序執行。防止了髒讀、不可重複讀、幻讀

 

總結：

髒讀     不可重複讀     幻讀

讀未提交      會             會          會

讀已提交     不會         會          會

可重複讀     不會       不會          會

串行化         不會       不會           不會

 

五   spring事務的傳播行爲

1.requierd

若是有事務那麼加入事務，沒有的話新建一個

2.not_supported

不開啓事務

3.requires_new

不論是否存在事務,都建立一個新的事務,原來的掛起,新的執行完,繼續執行老事務

4.mandatory

必須在一個已有的事務中執行，不然拋出異常

5.never

必須在一個沒有的事務中執行，不然拋出異常

6.supports

若是其餘bean調用這個方法，在其餘bean中聲明事務，那就用事務.若是其餘bean沒有聲明事務那就不用事務

 7.PROPAGATION_NESTED
若是當前存在事務，則在嵌套事務內執行。若是當前沒有事務，則按REQUIRED屬性執行。

 

六  Spring聲明式事務的回滾機制

在Spring 的事務框架中推薦的事務回滾方法是，在當前執行的事務上下文中拋出一個異常。若是異常未被處理，當拋出異常調用堆棧的時候，Spring 的事務框架代碼將捕獲任何未處理的異常，而後並決定是否將此事務標記爲回滾。

在默認配置中，Spring 的事務框架代碼只會將出現runtime, unchecked 異常的事務標記爲回滾；也就是說事務中拋出的異常時RuntimeException或者是其子類，這樣事務纔會回滾（默認狀況下Error也會致使事務回滾）。在默認配置的狀況下，全部的 checked 異常都不會引發事務回滾。若是有須要，能夠經過rollback-for 和no-rollback-for進行指定。

 

七  分佈式環境下如何處理事務

分佈式事務處理是很難保證acid的。通常作法是犧牲一致性，知足可用性和分區容錯。採用的方式能夠是二階段提交，因爲二階段提交存在着諸如同步阻塞、單點問題、數據不一致、宕機等缺陷，因此還能夠採用TCC(補償事務)的方式實現，TCC核心思想是：針對每一個操做，都要註冊一個與其對應的確認和補償（撤銷）操做。它分爲三個階段，本質也是2階段提交，缺點也比較明顯的，在確認和補償時都有可能失敗，一些業務流程可能用TCC不太好定義及處理。分佈式事務還能夠基於 mq（消息隊列）/rpc（遠程方法調用）實現最終一致性。還有Mycat能夠經過用戶會話Session中設置autocommit=false啓動事務，經過設置ServerConnection中變量txInterrupted=true來控制是否事務異常須要回滾。在Mycat中的事務是一種二階段提交事務方式，可是從實際應用場景出發這種出現故障的機率仍是比較小的，所以這種實現方式能夠知足不少應用需求，但若是出現問題，會很麻煩。但在分庫分表，當即可見的應用上是不能知足業務需求的，因此分佈式事務須要根據具體業務的須要權衡取捨的。

 

分享文章：

微服務架構下處理分佈式事務，你必須知道的事兒

根據微服務架構的鼻祖 Martin Fowler 的忠告，微服務架構中應當儘可能避免分佈式事務。然而，在某些領域，分佈式事務如同宿命中的對手沒法避免。

根據微服務架構的鼻祖 Martin Fowler 的忠告，微服務架構中應當儘可能避免分佈式事務。然而，在某些領域，分佈式事務如同宿命中的對手沒法避免。

在工程領域，分佈式事務的討論主要聚焦於強一致性和最終一致性的解決方案。

典型方案包括：

• 兩階段提交(2PC, Two-phase Commit)方案。
• eBay 事件隊列方案。
• TCC 補償模式。
• 緩存數據最終一致性。

一致性理論

分佈式事務的目的是保障分庫數據一致性，而跨庫事務會遇到各類不可控制的問題，如個別節點永久性宕機，像單機事務同樣的 ACID 是沒法奢望的。

另外，業界著名的 CAP 理論也告訴咱們，對分佈式系統，須要將數據一致性和系統可用性、分區容忍性放在天平上一塊兒考慮。

兩階段提交協議(簡稱2PC)是實現分佈式事務較爲經典的方案，但 2PC 的可擴展性不好，在分佈式架構下應用代價較大，eBay 架構師 Dan Pritchett 提出了 BASE 理論，用於解決大規模分佈式系統下的數據一致性問題。

BASE 理論告訴咱們：能夠經過放棄系統在每一個時刻的強一致性來換取系統的可擴展性。

01.CAP 理論

在分佈式系統中，一致性(Consistency)、可用性(Availability)和分區容忍性(Partition Tolerance)3 個要素最多隻能同時知足兩個，不可兼得。其中，分區容忍性又是不可或缺的。

 

 

 

 

• 一致性：分佈式環境下，多個節點的數據是否強一致。
• 可用性：分佈式服務能一直保證可用狀態。當用戶發出一個請求後，服務能在有限時間內返回結果。
• 分區容忍性：特指對網絡分區的容忍性。

舉例：Cassandra、Dynamo 等，默認優先選擇 AP，弱化 C;HBase、MongoDB 等，默認優先選擇 CP，弱化 A。

02.BASE 理論

核心思想：

• 基本可用(Basically Available)：指分佈式系統在出現故障時，容許損失部分的可用性來保證核心可用。
• 軟狀態(Soft State)：指容許分佈式系統存在中間狀態，該中間狀態不會影響到系統的總體可用性。
• 最終一致性(Eventual Consistency)：指分佈式系統中的全部副本數據通過必定時間後，最終可以達到一致的狀態。

一致性模型

數據的一致性模型能夠分紅如下三類：

• 強一致性：數據更新成功後，任意時刻全部副本中的數據都是一致的，通常採用同步的方式實現。
• 弱一致性：數據更新成功後，系統不承諾當即能夠讀到最新寫入的值，也不承諾具體多久以後能夠讀到。
• 最終一致性：弱一致性的一種形式，數據更新成功後，系統不承諾當即能夠返回最新寫入的值，可是保證最終會返回上一次更新操做的值。

分佈式系統數據的強一致性、弱一致性和最終一致性能夠經過 Quorum NRW 算法分析。

分佈式事務解決方案

01.2PC 方案——強一致性

2PC 的核心原理是經過提交分階段和記日誌的方式，記錄下事務提交所處的階段狀態，在組件宕機重啓後，可經過日誌恢復事務提交的階段狀態，並在這個狀態節點重試。

如 Coordinator 重啓後，經過日誌能夠肯定提交處於 Prepare 仍是 Prepare All 狀態。如果前者，說明有節點可能沒有 Prepare 成功，或全部節點 Prepare 成功但尚未下發 Commit，狀態恢復後給全部節點下發 RollBack。

如果 Prepare All 狀態，須要給全部節點下發 Commit，數據庫節點須要保證 Commit 冪等。

 

 

 

 

2PC 方案的三個問題：

• 同步阻塞。
• 數據不一致。
• 單點問題。

升級的 3PC 方案旨在解決這些問題，主要有兩個改進：

• 增長超時機制。
• 兩階段之間插入準備階段。

但三階段提交也存在一些缺陷，要完全從協議層面避免數據不一致，能夠採用 Paxos 或者 Raft 算法。

02.eBay 事件隊列方案——最終一致性

eBay 的架構師 Dan Pritchett，曾在一篇解釋 BASE 原理的論文《Base：An Acid Alternative》中提到一個 eBay 分佈式系統一致性問題的解決方案。

它的核心思想是將須要分佈式處理的任務經過消息或者日誌的方式來異步執行，消息或日誌能夠存到本地文件、數據庫或消息隊列，再經過業務規則進行失敗重試，它要求各服務的接口是冪等的。

描述的場景爲，有用戶表 user 和交易表 transaction，用戶表存儲用戶信息、總銷售額和總購買額。交易表存儲每一筆交易的流水號、買家信息、賣家信息和交易金額。若是產生了一筆交易，須要在交易表增長記錄，同時還要修改用戶表的金額。

 

 

 

 

論文中提出的解決方法是將更新交易表記錄和用戶表更新消息放在一個本地事務來完成，爲了不重複消費用戶表更新消息帶來的問題，增長一個操做記錄表 updates_applied 來記錄已經完成的交易相關的信息。

 

 

 

這個方案的核心在於第二階段的重試和冪等執行。失敗後重試，這是一種補償機制，它是能保證系統最終一致的關鍵流程。

03.TCC (Try-Confirm-Cancel)補償模式——最終一致性

某業務模型如圖，由服務 A、服務 B、服務 C、服務 D 共同組成的一個微服務架構系統。服務 A 須要依次調用服務 B、服務 C 和服務 D 共同完成一個操做。

當服務 A 調用服務 D 失敗時，若要保證整個系統數據的一致性，就要對服務 B 和服務 C 的 invoke 操做進行回滾，執行反向的 revert 操做。回滾成功後，整個微服務系統是數據一致的。

 

 

 

 

 

 

 

實現的三個關鍵要素：

• 服務調用鏈必須被記錄下來。
• 每一個服務提供者都須要提供一組業務邏輯相反的操做，互爲補償，同時回滾操做要保證冪等。
• 必須按失敗緣由執行不一樣的回滾策略。

實現的兩個難點：

• 補償模式的特色是實現簡單，可是想造成必定程度的通用方案比較困難，特別是服務鏈的記錄，由於大部分時候，業務參數或者業務邏輯千差萬別。
• 不少業務特徵使得該服務沒法提供一個安全的回滾操做。

04.緩存數據最終一致性

在咱們的業務系統中，緩存(Redis 或者 Memcached)一般被用在數據庫前面，做爲數據讀取的緩衝，使得 I/O 操做不至於直接落在數據庫上。

以商品詳情頁爲例，假如賣家修改了商品信息，並寫回到數據庫，可是這時候用戶從商品詳情頁看到的信息仍是從緩存中拿到的過期數據，這就出現了緩存系統和數據庫系統中的數據不一致的現象。

要解決該場景下緩存和數據庫數據不一致的問題，咱們有如下兩種解決方案：

• 爲緩存數據設置過時時間。當緩存中數據過時後，業務系統會從數據庫中獲取數據，並將新值放入緩存。這個過時時間就是系統能夠達到最終一致的容忍時間。
• 更新數據庫數據後，同時清除緩存數據。數據庫數據更新後，同步刪除緩存中數據，使得下次對商品詳情的獲取直接從數據庫中獲取，並同步到緩存。

選擇建議

在面臨數據一致性問題的時候，首先要從業務需求的角度出發，肯定咱們對於三種一致性模型的接受程度，再經過具體場景來決定解決方案。

從應用角度看，分佈式事務的現實場景經常沒法規避，在有能力給出其餘解決方案前，2PC 也是一個不錯的選擇。

對購物轉帳等電商和金融業務，中間件層的 2PC 最大問題在於業務不可見，一旦出現不可抗力或意想不到的一致性破壞。

如數據節點永久性宕機，業務難以根據 2PC 的日誌進行補償。金融場景下，數據一致性是命根，業務須要對數據有百分之百的掌控力。

建議使用 TCC 這類分佈式事務模型，或基於消息隊列的柔性事務框架，這兩種方案都在業務層實現，業務開發者具備足夠掌控力，能夠結合 SOA 框架來架構，包括 Dubbo、Spring Cloud 等。