本文轉載自 linkedkeeper.com

本文內容參考網路，侵刪

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到我的倉庫裡檢視
> https://github.com/h2pl/Java-Tutorial

喜歡的話麻煩點下Star哈

文章首發於我的個人部落格：
> www.how2playlife.com

該系列博文會告訴你什麼是分散式系統，這對後端工程師來說是很重要的一門學問，我們會逐步瞭解常見的分散式技術、以及一些較為常見的分散式系統概念，同時也需要進一步瞭解zookeeper、分散式事務、分散式鎖、負載均衡等技術，以便讓你更完整地瞭解分散式技術的具體實戰方法，為真正應用分散式技術做好準備。

如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公眾號【Java技術江湖】聯絡作者，歡迎你參與本系列博文的創作和修訂。

眾所周知，資料庫能實現本地事務，也就是在同一個資料庫中，你可以允許一組操作要麼全都正確執行，要麼全都不執行。這裡特別強調了本地事務，也就是目前的資料庫只能支援同一個資料庫中的事務。但現在的系統往往採用微服務架構，業務系統擁有獨立的資料庫，因此就出現了跨多個資料庫的事務需求，這種事務即為“分散式事務”。那麼在目前資料庫不支援跨庫事務的情況下，我們應該如何實現分散式事務呢？本文首先會為大家梳理分散式事務的基本概念和理論基礎，然後介紹幾種目前常用的分散式事務解決方案。廢話不多說，那就開始吧～

什麼是事務？
事務由一組操作構成，我們希望這組操作能夠全部正確執行，如果這一組操作中的任意一個步驟發生錯誤，那麼就需要回滾之前已經完成的操作。也就是同一個事務中的所有操作，要麼全都正確執行，要麼全都不要執行。

事務的四大特性 ACID
說到事務，就不得不提一下事務著名的四大特性。

原子性原子性要求，事務是一個不可分割的執行單元，事務中的所有操作要麼全都執行，要麼全都不執行。

一致性一致性要求，事務在開始前和結束後，資料庫的完整性約束沒有被破壞。

隔離性事務的執行是相互獨立的，它們不會相互干擾，一個事務不會看到另一個正在執行過程中的事務的資料。

永續性永續性要求，一個事務完成之後，事務的執行結果必須是持久化儲存的。即使資料庫發生崩潰，在資料庫恢復後事務提交的結果仍然不會丟失。

注意：事務只能保證資料庫的高可靠性，即資料庫本身發生問題後，事務提交後的資料仍然能恢復；而如果不是資料庫本身的故障，如硬碟損壞了，那麼事務提交的資料可能就丟失了。這屬於『高可用性』的範疇。因此，事務只能保證資料庫的『高可靠性』，而『高可用性』需要整個系統共同配合實現。

事務的隔離級別
這裡擴充套件一下，對事務的隔離性做一個詳細的解釋。

在事務的四大特性ACID中，要求的隔離性是一種嚴格意義上的隔離，也就是多個事務是序列執行的，彼此之間不會受到任何干擾。這確實能夠完全保證資料的安全性，但在實際業務系統中，這種方式效能不高。因此，資料庫定義了四種隔離級別，隔離級別和資料庫的效能是呈反比的，隔離級別越低，資料庫效能越高，而隔離級別越高，資料庫效能越差。

事務併發執行會出現的問題
我們先來看一下在不同的隔離級別下，資料庫可能會出現的問題：

更新丟失當有兩個併發執行的事務，更新同一行資料，那麼有可能一個事務會把另一個事務的更新覆蓋掉。當資料庫沒有加任何鎖操作的情況下會發生。

髒讀一個事務讀到另一個尚未提交的事務中的資料。該資料可能會被回滾從而失效。如果第一個事務拿著失效的資料去處理那就發生錯誤了。

不可重複讀不可重複度的含義：一個事務對同一行資料讀了兩次，卻得到了不同的結果。它具體分為如下兩種情況：

虛讀：在事務1兩次讀取同一記錄的過程中，事務2對該記錄進行了修改，從而事務1第二次讀到了不一樣的記錄。
幻讀：事務1在兩次查詢的過程中，事務2對該表進行了插入、刪除操作，從而事務1第二次查詢的結果發生了變化。
不可重複讀 與 髒讀 的區別？髒讀讀到的是尚未提交的資料，而不可重複讀讀到的是已經提交的資料，只不過在兩次讀的過程中資料被另一個事務改過了。

資料庫的四種隔離級別
資料庫一共有如下四種隔離級別：

Read uncommitted 讀未提交在該級別下，一個事務對一行資料修改的過程中，不允許另一個事務對該行資料進行修改，但允許另一個事務對該行資料讀。因此本級別下，不會出現更新丟失，但會出現髒讀、不可重複讀。

Read committed 讀提交在該級別下，未提交的寫事務不允許其他事務訪問該行，因此不會出現髒讀；但是讀取資料的事務允許其他事務的訪問該行資料，因此會出現不可重複讀的情況。

Repeatable read 重複讀在該級別下，讀事務禁止寫事務，但允許讀事務，因此不會出現同一事務兩次讀到不同的資料的情況（不可重複讀），且寫事務禁止其他一切事務。

Serializable 序列化該級別要求所有事務都必須序列執行，因此能避免一切因併發引起的問題，但效率很低。

隔離級別越高，越能保證資料的完整性和一致性，但是對併發效能的影響也越大。對於多數應用程式，可以優先考慮把資料庫系統的隔離級別設為Read Committed。它能夠避免髒讀取，而且具有較好的併發效能。儘管它會導致不可重複讀、幻讀和第二類丟失更新這些併發問題，在可能出現這類問題的個別場合，可以由應用程式採用悲觀鎖或樂觀鎖來控制。

什麼是分散式事務？
到此為止，所介紹的事務都是基於單資料庫的本地事務，目前的資料庫僅支援單庫事務，並不支援跨庫事務。而隨著微服務架構的普及，一個大型業務系統往往由若干個子系統構成，這些子系統又擁有各自獨立的資料庫。往往一個業務流程需要由多個子系統共同完成，而且這些操作可能需要在一個事務中完成。在微服務系統中，這些業務場景是普遍存在的。此時，我們就需要在資料庫之上透過某種手段，實現支援跨資料庫的事務支援，這也就是大家常說的“分散式事務”。

這裡舉一個分散式事務的典型例子——使用者下單過程。當我們的系統採用了微服務架構後，一個電商系統往往被拆分成如下幾個子系統：商品系統、訂單系統、支付系統、積分系統等。整個下單的過程如下：

使用者透過商品系統瀏覽商品，他看中了某一項商品，便點選下單
此時訂單系統會生成一條訂單
訂單建立成功後，支付系統提供支付功能
當支付完成後，由積分系統為該使用者增加積分
上述步驟2、3、4需要在一個事務中完成。對於傳統單體應用而言，實現事務非常簡單，只需將這三個步驟放在一個方法A中，再用Spring的@Transactional註解標識該方法即可。Spring透過資料庫的事務支援，保證這些步驟要麼全都執行完成，要麼全都不執行。但在這個微服務架構中，這三個步驟涉及三個系統，涉及三個資料庫，此時我們必須在資料庫和應用系統之間，透過某項黑科技，實現分散式事務的支援。

CAP理論
CAP理論說的是：在一個分散式系統中，最多隻能滿足C、A、P中的兩個需求。

CAP的含義：

C：Consistency 一致性同一資料的多個副本是否實時相同。
A：Availability 可用性可用性：一定時間內 & 系統返回一個明確的結果 則稱為該系統可用。
P：Partition tolerance 分割槽容錯性將同一服務分佈在多個系統中，從而保證某一個系統當機，仍然有其他系統提供相同的服務。
CAP理論告訴我們，在分散式系統中，C、A、P三個條件中我們最多隻能選擇兩個。那麼問題來了，究竟選擇哪兩個條件較為合適呢？

對於一個業務系統來說，可用性和分割槽容錯性是必須要滿足的兩個條件，並且這兩者是相輔相成的。業務系統之所以使用分散式系統，主要原因有兩個：

提升整體效能當業務量猛增，單個伺服器已經無法滿足我們的業務需求的時候，就需要使用分散式系統，使用多個節點提供相同的功能，從而整體上提升系統的效能，這就是使用分散式系統的第一個原因。

實現分割槽容錯性單一節點 或 多個節點處於相同的網路環境下，那麼會存在一定的風險，萬一該機房斷電、該地區發生自然災害，那麼業務系統就全面癱瘓了。為了防止這一問題，採用分散式系統，將多個子系統分佈在不同的地域、不同的機房中，從而保證系統高可用性。

這說明分割槽容錯性是分散式系統的根本，如果分割槽容錯性不能滿足，那使用分散式系統將失去意義。

此外，可用性對業務系統也尤為重要。在大談使用者體驗的今天，如果業務系統時常出現“系統異常”、響應時間過長等情況，這使得使用者對系統的好感度大打折扣，在網際網路行業競爭激烈的今天，相同領域的競爭者不甚列舉，系統的間歇性不可用會立馬導致使用者流向競爭對手。因此，我們只能透過犧牲一致性來換取系統的可用性和分割槽容錯性。這也就是下面要介紹的BASE理論。

BASE理論
CAP理論告訴我們一個悲慘但不得不接受的事實——我們只能在C、A、P中選擇兩個條件。而對於業務系統而言，我們往往選擇犧牲一致性來換取系統的可用性和分割槽容錯性。不過這裡要指出的是，所謂的“犧牲一致性”並不是完全放棄資料一致性，而是犧牲強一致性換取弱一致性。下面來介紹下BASE理論。

BA：Basic Available 基本可用
整個系統在某些不可抗力的情況下，仍然能夠保證“可用性”，即一定時間內仍然能夠返回一個明確的結果。只不過“基本可用”和“高可用”的區別是：
“一定時間”可以適當延長當舉行大促時，響應時間可以適當延長
給部分使用者返回一個降級頁面給部分使用者直接返回一個降級頁面，從而緩解伺服器壓力。但要注意，返回降級頁面仍然是返回明確結果。
S：Soft State：柔性狀態同一資料的不同副本的狀態，可以不需要實時一致。
E：Eventual Consisstency：最終一致性同一資料的不同副本的狀態，可以不需要實時一致，但一定要保證經過一定時間後仍然是一致的。
酸鹼平衡
ACID能夠保證事務的強一致性，即資料是實時一致的。這在本地事務中是沒有問題的，在分散式事務中，強一致性會極大影響分散式系統的效能，因此分散式系統中遵循BASE理論即可。但分散式系統的不同業務場景對一致性的要求也不同。如交易場景下，就要求強一致性，此時就需要遵循ACID理論，而在註冊成功後傳送簡訊驗證碼等場景下，並不需要實時一致，因此遵循BASE理論即可。因此要根據具體業務場景，在ACID和BASE之間尋求平衡。

分散式事務協議
下面介紹幾種實現分散式事務的協議。

理解2PC和3PC協議

為了解決分散式一致性問題，前人在效能和資料一致性的反反覆覆權衡過程中總結了許多典型的協議和演算法。其中比較著名的有二階提交協議（2 Phase Commitment Protocol），三階提交協議（3 Phase Commitment Protocol）。

2PC

分散式事務最常用的解決方案就是二階段提交。在分散式系統中，每個節點雖然可以知曉自己的操作時成功或者失敗，卻無法知道其他節點的操作的成功或失敗。當一個事務跨越多個節點時，為了保持事務的ACID特性，需要引入一個作為協調者的元件來統一掌控所有參與者節點的操作結果並最終指示這些節點是否要把操作結果進行真正的提交。

因此，二階段提交的演算法思路可以概括為：參與者將操作成敗通知協調者，再由協調者根據所有參與者的反饋情報決定各參與者是否要提交操作還是中止操作。

所謂的兩個階段是指：第一階段：準備階段（投票階段）和第二階段：提交階段（執行階段）。

第一階段：投票階段

該階段的主要目的在於打探資料庫叢集中的各個參與者是否能夠正常的執行事務，具體步驟如下：

1. 協調者向所有的參與者傳送事務執行請求，並等待參與者反饋事務執行結果。

2. 事務參與者收到請求之後，執行事務，但不提交，並記錄事務日誌。

3. 參與者將自己事務執行情況反饋給協調者，同時阻塞等待協調者的後續指令。

第二階段：事務提交階段

在第一階段協調者的詢盤之後，各個參與者會回覆自己事務的執行情況，這時候存在三種可能：

1. 所有的參與者回覆能夠正常執行事務。

2. 一個或多個參與者回覆事務執行失敗。

3. 協調者等待超時。

對於第一種情況，協調者將向所有的參與者發出提交事務的通知，具體步驟如下：

1. 協調者向各個參與者傳送commit通知，請求提交事務。

2. 參與者收到事務提交通知之後，執行commit操作，然後釋放佔有的資源。

3. 參與者向協調者返回事務commit結果資訊。

對於第二、三種情況，協調者均認為參與者無法正常成功執行事務，為了整個叢集資料的一致性，所以要向各個參與者傳送事務回滾通知，具體步驟如下：

1. 協調者向各個參與者傳送事務rollback通知，請求回滾事務。

2. 參與者收到事務回滾通知之後，執行rollback操作，然後釋放佔有的資源。

3. 參與者向協調者返回事務rollback結果資訊。

兩階段提交協議解決的是分散式資料庫資料強一致性問題，其原理簡單，易於實現，但是缺點也是顯而易見的，主要缺點如下：

單點問題：協調者在整個兩階段提交過程中扮演著舉足輕重的作用，一旦協調者所在伺服器當機，那麼就會影響整個資料庫叢集的正常執行，比如在第二階段中，如果協調者因為故障不能正常傳送事務提交或回滾通知，那麼參與者們將一直處於阻塞狀態，整個資料庫叢集將無法提供服務。

同步阻塞：兩階段提交執行過程中，所有的參與者都需要聽從協調者的統一排程，期間處於阻塞狀態而不能從事其他操作，這樣效率及其低下。

資料不一致性：兩階段提交協議雖然為分散式資料強一致性所設計，但仍然存在資料不一致性的可能，比如在第二階段中，假設協調者發出了事務commit的通知，但是因為網路問題該通知僅被一部分參與者所收到並執行了commit操作，其餘的參與者則因為沒有收到通知一直處於阻塞狀態，這時候就產生了資料的不一致性。

3PC

針對兩階段提交存在的問題，三階段提交協議透過引入一個“預詢盤”階段，以及超時策略來減少整個叢集的阻塞時間，提升系統效能。三階段提交的三個階段分別為：can_commit，pre_commit，do_commit。

第一階段：can_commit

該階段協調者會去詢問各個參與者是否能夠正常執行事務，參與者根據自身情況回覆一個預估值，相對於真正的執行事務，這個過程是輕量的，具體步驟如下：

1. 協調者向各個參與者傳送事務詢問通知，詢問是否可以執行事務操作，並等待回覆。

2. 各個參與者依據自身狀況回覆一個預估值，如果預估自己能夠正常執行事務就返回確定資訊，並進入預備狀態，否則返回否定資訊。

第二階段：pre_commit

本階段協調者會根據第一階段的詢盤結果採取相應操作，詢盤結果主要有三種：

1. 所有的參與者都返回確定資訊。

2. 一個或多個參與者返回否定資訊。

3. 協調者等待超時。

針對第一種情況，協調者會向所有參與者傳送事務執行請求，具體步驟如下：

1. 協調者向所有的事務參與者傳送事務執行通知。

2. 參與者收到通知後，執行事務，但不提交。

3. 參與者將事務執行情況返回給客戶端。

在上面的步驟中，如果參與者等待超時，則會中斷事務。 針對第二、三種情況，協調者認為事務無法正常執行，於是向各個參與者發出abort通知，請求退出預備狀態，具體步驟如下：

1. 協調者向所有事務參與者傳送abort通知

2. 參與者收到通知後，中斷事務

第三階段：do_commit

如果第二階段事務未中斷，那麼本階段協調者將會依據事務執行返回的結果來決定提交或回滾事務，分為三種情況：

1. 所有的參與者都能正常執行事務。

2. 一個或多個參與者執行事務失敗。

3. 協調者等待超時。

針對第一種情況，協調者向各個參與者發起事務提交請求，具體步驟如下：

1. 協調者向所有參與者傳送事務commit通知。

2. 所有參與者在收到通知之後執行commit操作，並釋放佔有的資源。

3. 參與者向協調者反饋事務提交結果。

針對第二、三種情況，協調者認為事務無法正常執行，於是向各個參與者傳送事務回滾請求，具體步驟如下：

1. 協調者向所有參與者傳送事務rollback通知。

2. 所有參與者在收到通知之後執行rollback操作，並釋放佔有的資源。

3. 參與者向協調者反饋事務提交結果。

在本階段如果因為協調者或網路問題，導致參與者遲遲不能收到來自協調者的commit或rollback請求，那麼參與者將不會如兩階段提交中那樣陷入阻塞，而是等待超時後繼續commit。相對於兩階段提交雖然降低了同步阻塞，但仍然無法避免資料的不一致性。

Reference

https://zhuanlan.zhihu.com/p/25933039

http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistency

http://blog.csdn.net/jasonsungblog/article/details/49017955

http://blog.csdn.net/suifeng3051/article/details/52691210

https://my.oschina.net/wangzhenchao/blog/736909

轉載請並標註: “本文轉載自 linkedkeeper.com ”
————————————————
版權宣告：本文為CSDN博主「黃小斜」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連結及本宣告。
原文連結：https://blog.csdn.net/a724888/article/details/80790138

搞懂分散式技術17：淺析分散式事務

相關文章