傳統(tǒng)的事務(wù)

事務(wù)(Transaction)是訪問并可能更新數(shù)據(jù)庫中各種數(shù)據(jù)項(xiàng)的一個(gè)程序執(zhí)行單元(unit)。在關(guān)系數(shù)據(jù)庫中，一個(gè)事務(wù)由一組SQL語句組成。事務(wù)應(yīng)該具有4個(gè)屬性：原子性、一致性、隔離性、持久性。這四個(gè)屬性通常稱為ACID特性。

• 原子性：一個(gè)事務(wù)是一個(gè)不可分割的工作單位，事務(wù)中包括的操作要么全部完成，要么全部取消
• 一致性：事務(wù)使數(shù)據(jù)庫從一個(gè)一致性狀態(tài)轉(zhuǎn)換為另一個(gè)一致性狀態(tài)，事務(wù)的中間狀態(tài)不可被觀察到。
• 隔離性：一個(gè)事務(wù)內(nèi)部的操作及使用的數(shù)據(jù)對(duì)并發(fā)中的其它事務(wù)是隔離的。
• 持久性：一個(gè)事務(wù)一旦被提交，其對(duì)數(shù)據(jù)庫中數(shù)據(jù)的改變是永久性的，不因其它故障而受影響。

集中式數(shù)據(jù)庫與分布式數(shù)據(jù)庫

ACID

以一個(gè)學(xué)生管理系統(tǒng)為例，可以看到對(duì)于這個(gè)學(xué)生成績管理系統(tǒng)，不同的系統(tǒng)使用角色，對(duì)它有不同的要求：

那么傳統(tǒng)的事務(wù)
ACID屬性，是如何幫助我們做到滿足這些需求的呢？

數(shù)據(jù)量變大

而實(shí)際上，當(dāng)我們考慮更大的數(shù)據(jù)量的時(shí)候，會(huì)發(fā)現(xiàn)，依賴于傳統(tǒng)集中式數(shù)據(jù)庫并無法很好地滿足我們對(duì)系統(tǒng)的需求。當(dāng)數(shù)據(jù)量變大，第一個(gè)要面對(duì)的問題是數(shù)據(jù)再也無法只放在一臺(tái)機(jī)器上了，數(shù)據(jù)量的變大，意味著會(huì)有越來越多的客戶端來查詢這個(gè)數(shù)據(jù)庫，那么就會(huì)出現(xiàn)查詢的瓶頸，并且如果數(shù)據(jù)數(shù)非常重要的話，那么這些數(shù)據(jù)時(shí)丟不起的，而如果僅依賴于集中式數(shù)據(jù)庫，那么當(dāng)這個(gè)集中式數(shù)據(jù)庫發(fā)生一些致命性的狀況的時(shí)候，數(shù)據(jù)可能丟失。總而言之，對(duì)于集中式數(shù)據(jù)庫來說，如果它出現(xiàn)了什么問題：不可查、丟數(shù)據(jù)等。那么其實(shí)意味著整個(gè)業(yè)務(wù)系統(tǒng)都陷入了不可用的狀態(tài)。

總結(jié)下來，集中式數(shù)據(jù)庫在通信、系統(tǒng)可靠性、可擴(kuò)展性、性能瓶頸以及設(shè)計(jì)管理上，存在著明顯的缺點(diǎn)：

• 集中數(shù)據(jù)庫會(huì)有多個(gè)成績錄入員，因?yàn)榧袛?shù)據(jù)庫只存在于某個(gè)服務(wù)器上，而成績錄入員卻是分散在全國各地的，因此會(huì)造成額外的通信開銷。
• 由于集中式數(shù)據(jù)庫所有的數(shù)據(jù)都存在一個(gè)點(diǎn)上，那么一旦這個(gè)點(diǎn)發(fā)生故障，就會(huì)導(dǎo)致整個(gè)成績管理系統(tǒng)停止運(yùn)作，系統(tǒng)的可靠性差。
• 隨著數(shù)據(jù)量的變大，錄入的客戶端變多，查詢的客戶端變多，那么存儲(chǔ)系統(tǒng)本身的性能可能就會(huì)成為瓶頸，包括 CPU計(jì)算能力，IO吞吐能力，存儲(chǔ)能力，都有可能成為瓶頸。
• 可擴(kuò)展性差，正由于集中式數(shù)據(jù)庫存在著性能差的問題，因此只能通過升級(jí)單機(jī)硬件能力的方式，實(shí)現(xiàn)數(shù)據(jù)庫服務(wù)能力擴(kuò)展，比如原來采用 MySQL 單機(jī)數(shù)據(jù)庫，遇到訪問瓶頸時(shí)更換磁盤，訪問量更高時(shí)就需要考慮使用 Oracle 的商用解決方案、高端的存儲(chǔ)設(shè)備、高端小型機(jī)，也就是 IOE 架構(gòu)，甚至升級(jí) IOE 設(shè)備，以換取更高的擴(kuò)展和服務(wù)能力，這個(gè)過程就會(huì)存在設(shè)備升級(jí)和數(shù)據(jù)遷移的成本，其可擴(kuò)展性的代價(jià)會(huì)面臨巨大的成本問題。此外，根據(jù)摩爾定律，單機(jī)硬件能力的升級(jí)，并不能換來等比的效率加速比例，也就是說，增加多一倍的CPU核數(shù)，并不能帶來一倍的性能提升，這個(gè)提升并不是線性的。
• 當(dāng)一個(gè)系統(tǒng)的功能變得越來越復(fù)雜，例如說b不僅記錄學(xué)生的成績，還記錄學(xué)生的獎(jiǎng)懲歷史，出勤情況，而數(shù)據(jù)庫仍然只有一個(gè)點(diǎn)的情況下，集中數(shù)據(jù)庫上承載的業(yè)務(wù)類型越來越多，導(dǎo)致管理困難。

傳統(tǒng)集中式數(shù)據(jù)庫雖然能夠很好地保證業(yè)務(wù)一致性，但其面臨高速增長的訪問量和數(shù)據(jù)量時(shí)存在性能和處理能力上的瓶頸。

數(shù)據(jù)分布式存儲(chǔ)

分布式數(shù)據(jù)庫雖然引進(jìn)了復(fù)雜性例如分布式事務(wù)的問題，但是分布式數(shù)據(jù)庫能解決集中式數(shù)據(jù)庫的大多數(shù)痛點(diǎn)。
分布式數(shù)據(jù)庫與集中式數(shù)據(jù)庫的區(qū)別主要在數(shù)據(jù)分布和可擴(kuò)展性兩方面：

• 分布式數(shù)據(jù)庫的數(shù)據(jù)分散存儲(chǔ)，集中式數(shù)據(jù)庫的數(shù)據(jù)集中存儲(chǔ)。
• 分布式數(shù)據(jù)庫的擴(kuò)展高效并且性價(jià)比高，而集中式數(shù)據(jù)庫不能無限擴(kuò)容并且擴(kuò)容存在著成本導(dǎo)致的性價(jià)比的問題。

總結(jié)起來，分布式數(shù)據(jù)庫具有以下的特點(diǎn)：

• 數(shù)據(jù)分布性，數(shù)據(jù)可以分布在不同的機(jī)器上，不同地理位置上。
• 數(shù)據(jù)統(tǒng)一性，雖然數(shù)據(jù)存放在不同的機(jī)器上，不同的地理位置上，但從整體上來看，它的系統(tǒng)邏輯應(yīng)該是一致的
• 數(shù)據(jù)的透明性，雖然數(shù)據(jù)分散了，但是無論是查詢還是更新，它們都應(yīng)該有統(tǒng)一的入口
• 數(shù)據(jù)的安全性，單個(gè)數(shù)據(jù)節(jié)點(diǎn)如果出現(xiàn)錯(cuò)誤，它不應(yīng)該影響其它節(jié)點(diǎn)，從而數(shù)據(jù)庫整體的安全性
• 數(shù)據(jù)的可擴(kuò)展性，當(dāng)現(xiàn)有集群稱為瓶頸時(shí)，分布式數(shù)據(jù)庫系統(tǒng)可以通過擴(kuò)容來解決可擴(kuò)展性的問題
• 數(shù)據(jù)的自治性，雖然數(shù)據(jù)分散存儲(chǔ)，但每一個(gè)節(jié)點(diǎn)它都應(yīng)該要能夠獨(dú)立管理自己的數(shù)據(jù)，同時(shí)又不影響整體的統(tǒng)一性。

分布式事務(wù)

在高速增長的訪問量和數(shù)據(jù)量的背景下，為了解決單機(jī)性能瓶頸以及可擴(kuò)展性等問題，數(shù)據(jù)庫分庫分表拆分和服務(wù)化（微服務(wù)）的運(yùn)用越來越廣泛。完成一個(gè)業(yè)務(wù)功能，可能需要橫跨多個(gè)服務(wù)或者橫跨多個(gè)數(shù)據(jù)庫節(jié)點(diǎn)；也就是說，需要操作的資源位于多個(gè)資源服務(wù)器上，從業(yè)務(wù)的角度來看，需要保證對(duì)多個(gè)資源服務(wù)器的操作，要么全部成功，要么全部失敗。從本質(zhì)上來說，分布式事務(wù)要保證不同資源服務(wù)器上的數(shù)據(jù)一致性。

場(chǎng)景

典型的分布式事務(wù)場(chǎng)景主要有跨庫事務(wù)、分庫分表以及跨服務(wù)事務(wù)。

跨庫事務(wù)

分庫分表

當(dāng)對(duì)數(shù)據(jù)庫通過中間件代理的形式進(jìn)行水平拆分后，不可避免的會(huì)在一個(gè)事務(wù)中操作多個(gè)分片節(jié)點(diǎn)

跨服務(wù)

在服務(wù)化的架構(gòu)下，完成業(yè)務(wù)功能可能涉及到對(duì)多個(gè)服務(wù)的調(diào)用，而這些服務(wù)分別會(huì)操作不同的數(shù)據(jù)庫。需要保證跨服務(wù)對(duì)數(shù)據(jù)庫的操作要么都成功，要么都失敗，這是服務(wù)化場(chǎng)景下面臨的分布式問題。

X/Open DTP模型與XA規(guī)范

DTP 模型

X/Open DTP(X/Open Distributed Transaction Processing Reference Model) 是X/Open 這個(gè)組織定義的一套分布式事務(wù)的標(biāo)準(zhǔn)，也就是了定義了規(guī)范和API接口，由廠商進(jìn)行具體的實(shí)現(xiàn)。

模型元素

• 應(yīng)用程序(Application Program ，簡稱AP)：用于定義事務(wù)邊界(即定義事務(wù)的開始和結(jié)束)，并且在事務(wù)邊界內(nèi)對(duì)資源進(jìn)行操作。
• 資源管理器(Resource Manager，簡稱RM)：如數(shù)據(jù)庫、文件系統(tǒng)等，并提供訪問資源的方式。
• 事務(wù)管理器(Transaction Manager ，簡稱TM)：負(fù)責(zé)分配事務(wù)唯一標(biāo)識(shí)，監(jiān)控事務(wù)的執(zhí)行進(jìn)度，并負(fù)責(zé)事務(wù)的提交、回滾等。
• 通信資源管理器(Communication Resource Manager，簡稱CRM)：控制一個(gè)TM域(TM domain)內(nèi)或者跨TM域的分布式應(yīng)用之間的通信。
• 通信協(xié)議(Communication Protocol，簡稱CP)：提供CRM提供的分布式應(yīng)用節(jié)點(diǎn)之間的底層通信服務(wù)。

一個(gè)DTP模型實(shí)例，至少有3個(gè)組成部分：AP、RMs、TM。如下所示：

AP通過TM來聲明一個(gè)全局事務(wù)，然后操作不同的RM上的資源，最后通知TM來提交或者回滾全局事務(wù)。AP 可以和 TM 以及 RM 通信，TM 和 RM 互相之間可以通信，DTP模型里面定義了XA接口，TM 和 RM 通過XA接口進(jìn)行雙向通信，例如:TM通知RM提交事務(wù)或者回滾事務(wù)，RM把提交結(jié)果通知給TM。AP和RM之間則通過RM提供的Native API 進(jìn)行資源控制，這個(gè)沒有進(jìn)行約API和規(guī)范，各個(gè)廠商自己實(shí)現(xiàn)自己的資源控制，比如Oracle自己的數(shù)據(jù)庫驅(qū)動(dòng)程序。

XA 規(guī)范

在DTP本地模型實(shí)例中，由AP、RMs和TM組成，不需要其他元素。AP、RM和TM之間，彼此都需要進(jìn)行交互，如下圖所示：

上圖中(1)表示AP-RM的交互接口，(2)表示AP-TM的交互接口，(3)表示RM-TM的交互接口
XA規(guī)范的最主要的作用是，就是定義了RM-TM的交互接口

XA規(guī)范中定義的RM 和 TM交互的接口如下圖所示：

二階段提交

XA規(guī)范除了定義的RM-TM交互的接口(XA Interface)之外，還對(duì)兩階段提交協(xié)議進(jìn)行了優(yōu)化。 兩階段協(xié)議(two-phase commit)是在OSI TP標(biāo)準(zhǔn)中提出的；在DTP參考模型中，指定了全局事務(wù)的提交要使用two-phase commit協(xié)議；而XA規(guī)范只是定義了兩階段提交協(xié)議中需要使用到的接口，也就是上述提到的RM-TM交互的接口，因?yàn)閮呻A段提交過程中的參與方，只有TM和RMs。

• 階段1

TM通知各個(gè)RM準(zhǔn)備提交它們的事務(wù)分支。如果RM判斷自己進(jìn)行的工作可以被提交，那就就對(duì)工作內(nèi)容進(jìn)行持久化，再給TM肯定答復(fù)；要是發(fā)生了其他情況，那給TM的都是否定答復(fù)。在發(fā)送了否定答復(fù)并回滾了已經(jīng)的工作后，RM就可以丟棄這個(gè)事務(wù)分支信息。

• 階段2

TM根據(jù)階段1各個(gè)RM prepare的結(jié)果，決定是提交還是回滾事務(wù)。如果所有的RM都prepare成功，那么TM通知所有的RM進(jìn)行提交；如果有RM prepare失敗的話，則TM通知所有RM回滾自己的事務(wù)分支。

二階段提交優(yōu)化

XA規(guī)范對(duì)兩階段提交協(xié)議有2點(diǎn)優(yōu)化：

• 只讀斷言

在階段1中，RM可以斷言“我這邊不涉及數(shù)據(jù)增刪改”來答復(fù)TM的prepare請(qǐng)求，從而讓這個(gè)RM脫離當(dāng)前的全局事務(wù)，從而免去了Phase 2。
這種優(yōu)化發(fā)生在其他RM都完成prepare之前的話，使用了只讀斷言的RM早于AP其他動(dòng)作（比如說這個(gè)RM返回那些只讀數(shù)據(jù)給AP）前，就釋放了相關(guān)數(shù)據(jù)的上下文（比如讀鎖之類的），這時(shí)候其他全局事務(wù)或者本地事務(wù)就有機(jī)會(huì)去改變這些數(shù)據(jù)，結(jié)果就是無法保障整個(gè)系統(tǒng)的可序列化特性，有臟讀的風(fēng)險(xiǎn)。

• 一階段提交

如果需要增刪改的數(shù)據(jù)都在同一個(gè)RM上，TM可以使用一階段提交跳過兩階段提交中的階段1，直接執(zhí)行階段2。

二階段提交缺點(diǎn)

同步阻塞

如果對(duì)操作讀很敏感，我們需要將事務(wù)隔離級(jí)別設(shè)置為SERIALIZABLE。而對(duì)于分布式事務(wù)來說，更是如此，可重復(fù)讀隔離級(jí)別不足以保證分布式事務(wù)一致性。

單點(diǎn)故障

一旦協(xié)調(diào)者TM發(fā)生故障。參與者RM會(huì)一直阻塞下去。尤其在第二階段，協(xié)調(diào)者發(fā)生故障，那么所有的參與者還都處于鎖定事務(wù)資源的狀態(tài)中，而無法繼續(xù)完成事務(wù)操作。（如果是協(xié)調(diào)者掛掉，可以重新選舉一個(gè)協(xié)調(diào)者，但是無法解決因?yàn)閰f(xié)調(diào)者宕機(jī)導(dǎo)致的參與者處于阻塞狀態(tài)的問題）

數(shù)據(jù)不一致

在二階段提交的階段二中，當(dāng)協(xié)調(diào)者向參與者發(fā)送commit請(qǐng)求之后，發(fā)生了局部網(wǎng)絡(luò)異常或者在發(fā)送commit請(qǐng)求過程中協(xié)調(diào)者發(fā)生了故障，這回導(dǎo)致只有一部分參與者接受到了commit請(qǐng)求。而在這部分參與者接到commit請(qǐng)求之后就會(huì)執(zhí)行commit操作。但是其他部分未接到commit請(qǐng)求的機(jī)器則無法執(zhí)行事務(wù)提交。于是整個(gè)分布式系統(tǒng)便出現(xiàn)了數(shù)據(jù)不一致性的現(xiàn)象。

三階段提交

由于二階段提交存在著諸如同步阻塞、單點(diǎn)問題等缺陷，所以，研究者們?cè)诙A段提交的基礎(chǔ)上做了改進(jìn)，提出了三階段提交。
三階段提交（3PC)，是二階段提交（2PC）的改進(jìn)版本，與兩階段提交不同的是，三階段提交有兩個(gè)改動(dòng)點(diǎn)。

引入超時(shí)機(jī)制，同時(shí)在協(xié)調(diào)者和參與者中都引入超時(shí)機(jī)制。

在第一階段和第二階段中插入一個(gè)準(zhǔn)備階段。保證了在最后提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的。也就是說，除了引入超時(shí)機(jī)制之外，3PC把2PC的準(zhǔn)備階段再次一分為二，這樣三階段提交就有CanCommit、PreCommit、DoCommit三個(gè)階段。

• CanCommit 階段

3PC的CanCommit階段其實(shí)和2PC的準(zhǔn)備階段很像。協(xié)調(diào)者向參與者發(fā)送commit請(qǐng)求，參與者如果可以提交就返回Yes響應(yīng)，否則返回No響應(yīng)。

• PreCommit 階段

協(xié)調(diào)者根據(jù)參與者的反應(yīng)情況來決定是否可以繼續(xù)事務(wù)的PreCommit操作。根據(jù)響應(yīng)情況，有以下兩種可能。
假如協(xié)調(diào)者從所有的參與者獲得的反饋都是Yes響應(yīng)，那么就會(huì)執(zhí)行事務(wù)的預(yù)執(zhí)行。

發(fā)送預(yù)提交請(qǐng)求。協(xié)調(diào)者向參與者發(fā)送PreCommit請(qǐng)求，并進(jìn)入Prepared階段。

事務(wù)預(yù)提交。參與者接收到PreCommit請(qǐng)求后，會(huì)執(zhí)行事務(wù)操作，并將undo和redo信息記錄到事務(wù)日志中。

響應(yīng)反饋。如果參與者成功的執(zhí)行了事務(wù)操作，則返回ACK響應(yīng)，同時(shí)開始等待最終指令。

假如有任何一個(gè)參與者向協(xié)調(diào)者發(fā)送了No響應(yīng)，或者等待超時(shí)之后，協(xié)調(diào)者都沒有接到參與者的響應(yīng)，那么就執(zhí)行事務(wù)的中斷。

發(fā)送中斷請(qǐng)求。協(xié)調(diào)者向所有參與者發(fā)送abort請(qǐng)求。

中斷事務(wù)。參與者收到來自協(xié)調(diào)者的abort請(qǐng)求之后（或超時(shí)之后，仍未收到協(xié)調(diào)者的請(qǐng)求），執(zhí)行事務(wù)的中斷。

• doCommit階段

該階段進(jìn)行真正的事務(wù)提交，也可以分為以下兩種情況。
情況1：執(zhí)行提交

發(fā)送提交請(qǐng)求。協(xié)調(diào)接收到參與者發(fā)送的ACK響應(yīng)，那么他將從預(yù)提交狀態(tài)進(jìn)入到提交狀態(tài)。并向所有參與者發(fā)送doCommit請(qǐng)求。

事務(wù)提交。參與者接收到doCommit請(qǐng)求之后，執(zhí)行正式的事務(wù)提交。并在完成事務(wù)提交之后釋放所有事務(wù)資源。

響應(yīng)反饋。事務(wù)提交完之后，向協(xié)調(diào)者發(fā)送Ack響應(yīng)。

完成事務(wù)。協(xié)調(diào)者接收到所有參與者的ack響應(yīng)之后，完成事務(wù)。

情況2：中斷事務(wù)（協(xié)調(diào)者沒有接收到參與者發(fā)送的ACK響應(yīng)）

發(fā)送中斷請(qǐng)求。協(xié)調(diào)者向所有參與者發(fā)送abort請(qǐng)求

事務(wù)回滾。參與者接收到abort請(qǐng)求之后，利用其在階段二記錄的undo信息來執(zhí)行事務(wù)的回滾操作，并在完成回滾之后釋放所有的事務(wù)資源。

反饋結(jié)果。參與者完成事務(wù)回滾之后，向協(xié)調(diào)者發(fā)送ACK消息

中斷事務(wù)。協(xié)調(diào)者接收到參與者反饋的ACK消息之后，執(zhí)行事務(wù)的中斷。

在doCommit階段，如果參與者無法及時(shí)接收到來自協(xié)調(diào)者的doCommit或者rebort請(qǐng)求時(shí)，會(huì)在等待超時(shí)之后，會(huì)繼續(xù)進(jìn)行事務(wù)的提交。當(dāng)進(jìn)入第三階段時(shí)，說明參與者在第二階段已經(jīng)收到了PreCommit請(qǐng)求，那么協(xié)調(diào)者產(chǎn)生PreCommit請(qǐng)求的前提條件是他在第二階段開始之前，收到所有參與者的CanCommit響應(yīng)都是Yes。當(dāng)進(jìn)入第三階段時(shí)，由于網(wǎng)絡(luò)超時(shí)等原因，雖然參與者沒有收到commit或者abort響應(yīng)，但是他有理由相信：成功提交的幾率很大。
相對(duì)于2PC，3PC主要解決的單點(diǎn)故障問題，并減少阻塞，因?yàn)橐坏﹨⑴c者無法及時(shí)收到來自協(xié)調(diào)者的信息之后，他會(huì)默認(rèn)執(zhí)行commit。而不會(huì)一直持有事務(wù)資源并處于阻塞狀態(tài)。但是這種機(jī)制也會(huì)導(dǎo)致數(shù)據(jù)一致性問題，因?yàn)?#xff0c;由于網(wǎng)絡(luò)原因，協(xié)調(diào)者發(fā)送的abort響應(yīng)沒有及時(shí)被參與者接收到，那么參與者在等待超時(shí)之后執(zhí)行了commit操作。這樣就和其他接到abort命令并執(zhí)行回滾的參與者之間存在數(shù)據(jù)不一致的情況。
無論是二階段提交還是三階段提交都無法徹底解決分布式的一致性問題。

CAP理論與BASE柔性事務(wù)

CAP 理論

2000年7月，加州大學(xué)伯克利分校的 Eric Brewer 教授在分布式計(jì)算原則研究會(huì)議上提出 CAP 猜想。直到 2002 年，又麻省理工學(xué)院的 Seth Gilbert 和 Nancy Lynch 從理論上證明了 CAP 理論，從而讓 CAP 理論正式成為分布式計(jì)算領(lǐng)域的公認(rèn)定理。
CAP理論：一個(gè)分布式系統(tǒng)最多只能同時(shí)滿足一致性（consistency）、可用性（Availability）、分區(qū)容錯(cuò)性（partition-tolerance）這三項(xiàng)中的兩項(xiàng)。
{% asset_img cap.jpg CAP理論模型 %}

一致性

指更新操作成功并返回客戶端完成后，所有節(jié)點(diǎn)在同一時(shí)間的數(shù)據(jù)完全一致。

可用性

指系統(tǒng)提供的服務(wù)必須一直處于可用的狀態(tài)，對(duì)于用戶的每一個(gè)操作請(qǐng)求總是能夠在有限的時(shí)間內(nèi)返回結(jié)果。

分區(qū)容錯(cuò)性

指分布式系統(tǒng)在遇到某節(jié)點(diǎn)或網(wǎng)絡(luò)分區(qū)故障的時(shí)候，仍然能對(duì)外提供滿足一致性和可用性的服務(wù)。

BASE 理論

一個(gè)分布式系統(tǒng)無法同時(shí)滿足一致性、可用性、分區(qū)容錯(cuò)性三個(gè)特點(diǎn)，需要對(duì)其進(jìn)行取舍。對(duì)于一個(gè)分布式系統(tǒng)而言，分區(qū)容錯(cuò)性是一個(gè)最基本的要求，分布式系統(tǒng)中的組件必然需要被部署到不同的節(jié)點(diǎn)，網(wǎng)絡(luò)問題又是一個(gè)必定會(huì)出現(xiàn)的異常情況，因此分區(qū)容錯(cuò)性也就成為了一個(gè)分布式系統(tǒng)必然需要面對(duì)和解決的問題。
eBay的架構(gòu)師Dan Pritchett源于對(duì)大規(guī)模分布式系統(tǒng)的實(shí)踐總結(jié)，在ACM上發(fā)表文章提出BASE理論。
BASE理論是對(duì)CAP理論的延伸，核心思想是即使無法做到強(qiáng)一致性（Strong Consistency，CAP的一致性就是強(qiáng)一致性），但應(yīng)用可以采用適合的方式達(dá)到最終一致性（Eventual Consitency）。
BASE是指Basically Available（基本可用）、Soft state（柔性狀態(tài)）和Eventually consistent（最終一致性）

基本可用
指分布式系統(tǒng)在出現(xiàn)不可預(yù)知故障的時(shí)候，允許損失部分可用性。

柔性狀態(tài)

指允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)，并認(rèn)為該中間狀態(tài)的存在不會(huì)影響系統(tǒng)的整體可用性。

最終一致

強(qiáng)調(diào)的是所有的數(shù)據(jù)更新操作，在經(jīng)過一段時(shí)間的同步之后，最終都能夠達(dá)到一個(gè)一致的狀態(tài)。
BASE理論面向的是大型高可用可擴(kuò)展的分布式系統(tǒng)，通過犧牲一致性獲得高可用性。

柔性事務(wù)解決方案一般有：最大努力通知、可靠消息最終一致性以及TCC。

參考資料

Distributed Transaction Processing: Reference Model, Version 3
Distributed Transaction Processing:The XA Specification
Atomic Distributed Transactions: a RESTful Design
田守枝的技術(shù)博客

總結(jié)

以上是生活随笔為你收集整理的分布式事务概览的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。