這期內(nèi)容當中小編將會給大家?guī)碛嘘P(guān)怎么進行分布式事務淺析，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

十年的江北網(wǎng)站建設經(jīng)驗，針對設計、前端、開發(fā)、售后、文案、推廣等六對一服務，響應快，48小時及時工作處理。網(wǎng)絡營銷推廣的優(yōu)勢是能夠根據(jù)用戶設備顯示端的尺寸不同，自動調(diào)整江北建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設計，從而大程度地提升瀏覽體驗。成都創(chuàng)新互聯(lián)從事“江北網(wǎng)站設計”,“江北網(wǎng)站推廣”以來，每個客戶項目都認真落實執(zhí)行。

什么是分布式系統(tǒng)，這對后端工程師來說是很重要的一門學問，我們會逐步了解常見的分布式技術(shù)、以及一些較為常見的分布式系統(tǒng)概念，同時也需要進一步了解zookeeper、分布式事務、分布式鎖、負載均衡等技術(shù)，以便讓你更完整地了解分布式技術(shù)的具體實戰(zhàn)方法，為真正應用分布式技術(shù)做好準備。

眾所周知，數(shù)據(jù)庫能實現(xiàn)本地事務，也就是在同一個數(shù)據(jù)庫中，你可以允許一組操作要么全都正確執(zhí)行，要么全都不執(zhí)行。這里特別強調(diào)了本地事務，也就是目前的數(shù)據(jù)庫只能支持同一個數(shù)據(jù)庫中的事務。但現(xiàn)在的系統(tǒng)往往采用微服務架構(gòu)，業(yè)務系統(tǒng)擁有獨立的數(shù)據(jù)庫，因此就出現(xiàn)了跨多個數(shù)據(jù)庫的事務需求，這種事務即為“分布式事務”。那么在目前數(shù)據(jù)庫不支持跨庫事務的情況下，我們應該如何實現(xiàn)分布式事務呢？本文首先會為大家梳理分布式事務的基本概念和理論基礎，然后介紹幾種目前常用的分布式事務解決方案。廢話不多說，那就開始吧～

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

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

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

一致性一致性要求，事務在開始前和結(jié)束后，數(shù)據(jù)庫的完整性約束沒有被破壞。

隔離性事務的執(zhí)行是相互獨立的，它們不會相互干擾，一個事務不會看到另一個正在運行過程中的事務的數(shù)據(jù)。

持久性持久性要求，一個事務完成之后，事務的執(zhí)行結(jié)果必須是持久化保存的。即使數(shù)據(jù)庫發(fā)生崩潰，在數(shù)據(jù)庫恢復后事務提交的結(jié)果仍然不會丟失。

注意：事務只能保證數(shù)據(jù)庫的高可靠性，即數(shù)據(jù)庫本身發(fā)生問題后，事務提交后的數(shù)據(jù)仍然能恢復；而如果不是數(shù)據(jù)庫本身的故障，如硬盤損壞了，那么事務提交的數(shù)據(jù)可能就丟失了。這屬于『高可用性』的范疇。因此，事務只能保證數(shù)據(jù)庫的『高可靠性』，而『高可用性』需要整個系統(tǒng)共同配合實現(xiàn)。

事務的隔離級別
這里擴展一下，對事務的隔離性做一個詳細的解釋。

在事務的四大特性ACID中，要求的隔離性是一種嚴格意義上的隔離，也就是多個事務是串行執(zhí)行的，彼此之間不會受到任何干擾。這確實能夠完全保證數(shù)據(jù)的安全性，但在實際業(yè)務系統(tǒng)中，這種方式性能不高。因此，數(shù)據(jù)庫定義了四種隔離級別，隔離級別和數(shù)據(jù)庫的性能是呈反比的，隔離級別越低，數(shù)據(jù)庫性能越高，而隔離級別越高，數(shù)據(jù)庫性能越差。

事務并發(fā)執(zhí)行會出現(xiàn)的問題
我們先來看一下在不同的隔離級別下，數(shù)據(jù)庫可能會出現(xiàn)的問題：

更新丟失當有兩個并發(fā)執(zhí)行的事務，更新同一行數(shù)據(jù)，那么有可能一個事務會把另一個事務的更新覆蓋掉。當數(shù)據(jù)庫沒有加任何鎖操作的情況下會發(fā)生。

臟讀一個事務讀到另一個尚未提交的事務中的數(shù)據(jù)。該數(shù)據(jù)可能會被回滾從而失效。如果第一個事務拿著失效的數(shù)據(jù)去處理那就發(fā)生錯誤了。

不可重復讀不可重復度的含義：一個事務對同一行數(shù)據(jù)讀了兩次，卻得到了不同的結(jié)果。它具體分為如下兩種情況：

虛讀：在事務1兩次讀取同一記錄的過程中，事務2對該記錄進行了修改，從而事務1第二次讀到了不一樣的記錄。
幻讀：事務1在兩次查詢的過程中，事務2對該表進行了插入、刪除操作，從而事務1第二次查詢的結(jié)果發(fā)生了變化。
不可重復讀 與 臟讀 的區(qū)別？臟讀讀到的是尚未提交的數(shù)據(jù)，而不可重復讀讀到的是已經(jīng)提交的數(shù)據(jù)，只不過在兩次讀的過程中數(shù)據(jù)被另一個事務改過了。

數(shù)據(jù)庫的四種隔離級別
數(shù)據(jù)庫一共有如下四種隔離級別：

Read uncommitted 讀未提交在該級別下，一個事務對一行數(shù)據(jù)修改的過程中，不允許另一個事務對該行數(shù)據(jù)進行修改，但允許另一個事務對該行數(shù)據(jù)讀。因此本級別下，不會出現(xiàn)更新丟失，但會出現(xiàn)臟讀、不可重復讀。

Read committed 讀提交在該級別下，未提交的寫事務不允許其他事務訪問該行，因此不會出現(xiàn)臟讀；但是讀取數(shù)據(jù)的事務允許其他事務的訪問該行數(shù)據(jù)，因此會出現(xiàn)不可重復讀的情況。

Repeatable read 重復讀在該級別下，讀事務禁止寫事務，但允許讀事務，因此不會出現(xiàn)同一事務兩次讀到不同的數(shù)據(jù)的情況（不可重復讀），且寫事務禁止其他一切事務。

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

隔離級別越高，越能保證數(shù)據(jù)的完整性和一致性，但是對并發(fā)性能的影響也越大。對于多數(shù)應用程序，可以優(yōu)先考慮把數(shù)據(jù)庫系統(tǒng)的隔離級別設為Read Committed。它能夠避免臟讀取，而且具有較好的并發(fā)性能。盡管它會導致不可重復讀、幻讀和第二類丟失更新這些并發(fā)問題，在可能出現(xiàn)這類問題的個別場合，可以由應用程序采用悲觀鎖或樂觀鎖來控制。

什么是分布式事務？
到此為止，所介紹的事務都是基于單數(shù)據(jù)庫的本地事務，目前的數(shù)據(jù)庫僅支持單庫事務，并不支持跨庫事務。而隨著微服務架構(gòu)的普及，一個大型業(yè)務系統(tǒng)往往由若干個子系統(tǒng)構(gòu)成，這些子系統(tǒng)又擁有各自獨立的數(shù)據(jù)庫。往往一個業(yè)務流程需要由多個子系統(tǒng)共同完成，而且這些操作可能需要在一個事務中完成。在微服務系統(tǒng)中，這些業(yè)務場景是普遍存在的。此時，我們就需要在數(shù)據(jù)庫之上通過某種手段，實現(xiàn)支持跨數(shù)據(jù)庫的事務支持，這也就是大家常說的“分布式事務”。

這里舉一個分布式事務的典型例子——用戶下單過程。當我們的系統(tǒng)采用了微服務架構(gòu)后，一個電商系統(tǒng)往往被拆分成如下幾個子系統(tǒng)：商品系統(tǒng)、訂單系統(tǒng)、支付系統(tǒng)、積分系統(tǒng)等。整個下單的過程如下：

用戶通過商品系統(tǒng)瀏覽商品，他看中了某一項商品，便點擊下單
此時訂單系統(tǒng)會生成一條訂單
訂單創(chuàng)建成功后，支付系統(tǒng)提供支付功能
當支付完成后，由積分系統(tǒng)為該用戶增加積分
上述步驟2、3、4需要在一個事務中完成。對于傳統(tǒng)單體應用而言，實現(xiàn)事務非常簡單，只需將這三個步驟放在一個方法A中，再用Spring的 @Transactional注解標識該方法即可。Spring通過數(shù)據(jù)庫的事務支持，保證這些步驟要么全都執(zhí)行完成，要么全都不執(zhí)行。但在這個微服務架構(gòu)中，這三個步驟涉及三個系統(tǒng)，涉及三個數(shù)據(jù)庫，此時我們必須在數(shù)據(jù)庫和應用系統(tǒng)之間，通過某項黑科技，實現(xiàn)分布式事務的支持。

CAP理論
CAP理論說的是：在一個分布式系統(tǒng)中，最多只能滿足C、A、P中的兩個需求。

CAP的含義：

C：Consistency 一致性同一數(shù)據(jù)的多個副本是否實時相同。
A：Availability 可用性可用性：一定時間內(nèi) & 系統(tǒng)返回一個明確的結(jié)果 則稱為該系統(tǒng)可用。
P：Partition tolerance 分區(qū)容錯性將同一服務分布在多個系統(tǒng)中，從而保證某一個系統(tǒng)宕機，仍然有其他系統(tǒng)提供相同的服務。
CAP理論告訴我們，在分布式系統(tǒng)中，C、A、P三個條件中我們最多只能選擇兩個。那么問題來了，究竟選擇哪兩個條件較為合適呢？

對于一個業(yè)務系統(tǒng)來說，可用性和分區(qū)容錯性是必須要滿足的兩個條件，并且這兩者是相輔相成的。業(yè)務系統(tǒng)之所以使用分布式系統(tǒng)，主要原因有兩個：

提升整體性能當業(yè)務量猛增，單個服務器已經(jīng)無法滿足我們的業(yè)務需求的時候，就需要使用分布式系統(tǒng)，使用多個節(jié)點提供相同的功能，從而整體上提升系統(tǒng)的性能，這就是使用分布式系統(tǒng)的第一個原因。

實現(xiàn)分區(qū)容錯性單一節(jié)點 或 多個節(jié)點處于相同的網(wǎng)絡環(huán)境下，那么會存在一定的風險，萬一該機房斷電、該地區(qū)發(fā)生自然災害，那么業(yè)務系統(tǒng)就全面癱瘓了。為了防止這一問題，采用分布式系統(tǒng)，將多個子系統(tǒng)分布在不同的地域、不同的機房中，從而保證系統(tǒng)高可用性。

這說明分區(qū)容錯性是分布式系統(tǒng)的根本，如果分區(qū)容錯性不能滿足，那使用分布式系統(tǒng)將失去意義。

此外，可用性對業(yè)務系統(tǒng)也尤為重要。在大談用戶體驗的今天，如果業(yè)務系統(tǒng)時常出現(xiàn)“系統(tǒng)異常”、響應時間過長等情況，這使得用戶對系統(tǒng)的好感度大打折扣，在互聯(lián)網(wǎng)行業(yè)競爭激烈的今天，相同領(lǐng)域的競爭者不甚枚舉，系統(tǒng)的間歇性不可用會立馬導致用戶流向競爭對手。因此，我們只能通過犧牲一致性來換取系統(tǒng)的可用性和分區(qū)容錯性。這也就是下面要介紹的BASE理論。

BASE理論
CAP理論告訴我們一個悲慘但不得不接受的事實——我們只能在C、A、P中選擇兩個條件。而對于業(yè)務系統(tǒng)而言，我們往往選擇犧牲一致性來換取系統(tǒng)的可用性和分區(qū)容錯性。不過這里要指出的是，所謂的“犧牲一致性”并不是完全放棄數(shù)據(jù)一致性，而是犧牲強一致性換取弱一致性。下面來介紹下BASE理論。

BA：Basic Available 基本可用
整個系統(tǒng)在某些不可抗力的情況下，仍然能夠保證“可用性”，即一定時間內(nèi)仍然能夠返回一個明確的結(jié)果。只不過“基本可用”和“高可用”的區(qū)別是：
“一定時間”可以適當延長當舉行大促時，響應時間可以適當延長
給部分用戶返回一個降級頁面給部分用戶直接返回一個降級頁面，從而緩解服務器壓力。但要注意，返回降級頁面仍然是返回明確結(jié)果。
S：Soft State：柔性狀態(tài)同一數(shù)據(jù)的不同副本的狀態(tài)，可以不需要實時一致。
E：Eventual Consisstency：最終一致性同一數(shù)據(jù)的不同副本的狀態(tài)，可以不需要實時一致，但一定要保證經(jīng)過一定時間后仍然是一致的。
酸堿平衡
ACID能夠保證事務的強一致性，即數(shù)據(jù)是實時一致的。這在本地事務中是沒有問題的，在分布式事務中，強一致性會極大影響分布式系統(tǒng)的性能，因此分布式系統(tǒng)中遵循BASE理論即可。但分布式系統(tǒng)的不同業(yè)務場景對一致性的要求也不同。如交易場景下，就要求強一致性，此時就需要遵循ACID理論，而在注冊成功后發(fā)送短信驗證碼等場景下，并不需要實時一致，因此遵循BASE理論即可。因此要根據(jù)具體業(yè)務場景，在ACID和BASE之間尋求平衡。

分布式事務協(xié)議
下面介紹幾種實現(xiàn)分布式事務的協(xié)議。

理解2PC和3PC協(xié)議

為了解決分布式一致性問題，前人在性能和數(shù)據(jù)一致性的反反復復權(quán)衡過程中總結(jié)了許多典型的協(xié)議和算法。其中比較著名的有二階提交協(xié)議（2 Phase Commitment Protocol），三階提交協(xié)議（3 Phase Commitment Protocol）。

2PC

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

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

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

第一階段：投票階段

該階段的主要目的在于打探數(shù)據(jù)庫集群中的各個參與者是否能夠正常的執(zhí)行事務，具體步驟如下：

1. 協(xié)調(diào)者向所有的參與者發(fā)送事務執(zhí)行請求，并等待參與者反饋事務執(zhí)行結(jié)果。

2. 事務參與者收到請求之后，執(zhí)行事務，但不提交，并記錄事務日志。

3. 參與者將自己事務執(zhí)行情況反饋給協(xié)調(diào)者，同時阻塞等待協(xié)調(diào)者的后續(xù)指令。

第二階段：事務提交階段

在第一階段協(xié)調(diào)者的詢盤之后，各個參與者會回復自己事務的執(zhí)行情況，這時候存在三種可能：

1. 所有的參與者回復能夠正常執(zhí)行事務。

2. 一個或多個參與者回復事務執(zhí)行失敗。

3. 協(xié)調(diào)者等待超時。

對于第一種情況，協(xié)調(diào)者將向所有的參與者發(fā)出提交事務的通知，具體步驟如下：

1. 協(xié)調(diào)者向各個參與者發(fā)送commit通知，請求提交事務。

2. 參與者收到事務提交通知之后，執(zhí)行commit操作，然后釋放占有的資源。

3. 參與者向協(xié)調(diào)者返回事務commit結(jié)果信息。

對于第二、三種情況，協(xié)調(diào)者均認為參與者無法正常成功執(zhí)行事務，為了整個集群數(shù)據(jù)的一致性，所以要向各個參與者發(fā)送事務回滾通知，具體步驟如下：

1. 協(xié)調(diào)者向各個參與者發(fā)送事務rollback通知，請求回滾事務。

2. 參與者收到事務回滾通知之后，執(zhí)行rollback操作，然后釋放占有的資源。

3. 參與者向協(xié)調(diào)者返回事務rollback結(jié)果信息。

兩階段提交協(xié)議解決的是分布式數(shù)據(jù)庫數(shù)據(jù)強一致性問題，其原理簡單，易于實現(xiàn)，但是缺點也是顯而易見的，主要缺點如下：

單點問題：協(xié)調(diào)者在整個兩階段提交過程中扮演著舉足輕重的作用，一旦協(xié)調(diào)者所在服務器宕機，那么就會影響整個數(shù)據(jù)庫集群的正常運行，比如在第二階段中，如果協(xié)調(diào)者因為故障不能正常發(fā)送事務提交或回滾通知，那么參與者們將一直處于阻塞狀態(tài)，整個數(shù)據(jù)庫集群將無法提供服務。

同步阻塞：兩階段提交執(zhí)行過程中，所有的參與者都需要聽從協(xié)調(diào)者的統(tǒng)一調(diào)度，期間處于阻塞狀態(tài)而不能從事其他操作，這樣效率及其低下。

數(shù)據(jù)不一致性：兩階段提交協(xié)議雖然為分布式數(shù)據(jù)強一致性所設計，但仍然存在數(shù)據(jù)不一致性的可能，比如在第二階段中，假設協(xié)調(diào)者發(fā)出了事務commit的通知，但是因為網(wǎng)絡問題該通知僅被一部分參與者所收到并執(zhí)行了commit操作，其余的參與者則因為沒有收到通知一直處于阻塞狀態(tài)，這時候就產(chǎn)生了數(shù)據(jù)的不一致性。

3PC

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

第一階段：can_commit

該階段協(xié)調(diào)者會去詢問各個參與者是否能夠正常執(zhí)行事務，參與者根據(jù)自身情況回復一個預估值，相對于真正的執(zhí)行事務，這個過程是輕量的，具體步驟如下：

1. 協(xié)調(diào)者向各個參與者發(fā)送事務詢問通知，詢問是否可以執(zhí)行事務操作，并等待回復。

2. 各個參與者依據(jù)自身狀況回復一個預估值，如果預估自己能夠正常執(zhí)行事務就返回確定信息，并進入預備狀態(tài)，否則返回否定信息。

第二階段：pre_commit

本階段協(xié)調(diào)者會根據(jù)第一階段的詢盤結(jié)果采取相應操作，詢盤結(jié)果主要有三種：

1. 所有的參與者都返回確定信息。

2. 一個或多個參與者返回否定信息。

3. 協(xié)調(diào)者等待超時。

針對第一種情況，協(xié)調(diào)者會向所有參與者發(fā)送事務執(zhí)行請求，具體步驟如下：

1. 協(xié)調(diào)者向所有的事務參與者發(fā)送事務執(zhí)行通知。

2. 參與者收到通知后，執(zhí)行事務，但不提交。

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

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

1. 協(xié)調(diào)者向所有事務參與者發(fā)送abort通知

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

第三階段：do_commit

如果第二階段事務未中斷，那么本階段協(xié)調(diào)者將會依據(jù)事務執(zhí)行返回的結(jié)果來決定提交或回滾事務，分為三種情況：

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

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

3. 協(xié)調(diào)者等待超時。

針對第一種情況，協(xié)調(diào)者向各個參與者發(fā)起事務提交請求，具體步驟如下：

1. 協(xié)調(diào)者向所有參與者發(fā)送事務commit通知。

2. 所有參與者在收到通知之后執(zhí)行commit操作，并釋放占有的資源。

3. 參與者向協(xié)調(diào)者反饋事務提交結(jié)果。

針對第二、三種情況，協(xié)調(diào)者認為事務無法正常執(zhí)行，于是向各個參與者發(fā)送事務回滾請求，具體步驟如下：

1. 協(xié)調(diào)者向所有參與者發(fā)送事務rollback通知。

2. 所有參與者在收到通知之后執(zhí)行rollback操作，并釋放占有的資源。

3. 參與者向協(xié)調(diào)者反饋事務提交結(jié)果。

上述就是小編為大家分享的怎么進行分布式事務淺析了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設公司行業(yè)資訊頻道。

分享題目：怎么進行分布式事務淺析-創(chuàng)新互聯(lián)
本文地址：http://aaarwkj.com/article22/dsjccc.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供服務器托管、網(wǎng)站維護、網(wǎng)站收錄、網(wǎng)站營銷、ChatGPT、網(wǎng)站設計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)