比較全的常見的架構設計思想整理

1、MPP 架構

一、MPP架構的基礎概念

MPP (Massively Parallel Processing)，即大規模並行處理，在數據庫非共享集羣中，每一個節點都有獨立的磁盤存儲系統和內存系統，業務數據根據數據庫模型和應用特色劃分到各個節點上，每臺數據節點經過專用網絡或者商業通用網絡互相鏈接，彼此協同計算，做爲總體提供數據庫服務。非共享數據庫集羣有徹底的可伸縮性、高可用、高性能、優秀的性價比、資源共享等優點。

簡單來講，MPP是將任務並行的分散到多個服務器和節點上，在每一個節點上計算完成後，將各自部分的結果彙總在一塊兒獲得最終的結果(與Hadoop類似)。

 

 

MPP 屬於Shared Nothing，根據Shared 的不一樣，能夠分爲以下幾種：

Shared Everthting:通常是針對單個主機，徹底透明共享CPU/MEMORY/IO，並行處理能力是最差的，典型的表明SQLServer

Shared Disk：各個處理單元使用本身的私有 CPU和Memory，共享磁盤系統。典型的表明Oracle Rac， 它是數據共享，可經過增長節點來提升並行處理的能力，擴展能力較好。其相似於SMP（對稱多處理）模式，可是當存儲器接口達到飽和的時候，增長節點並不能得到更高的性能 。

Shared Nothing：各個處理單元都有本身私有的CPU/內存/硬盤等，不存在共享資源，相似於MPP（大規模並行處理）模式，各處理單元之間經過協議通訊，並行處理和擴展能力更好。典型表明DB2 DPF和hadoop ，各節點相互獨立，各自處理本身的數據，處理後的結果可能向上層彙總或在節點間流轉。

咱們常說的 Sharding 其實就是Share Nothing架構，它是把某個表從物理存儲上被水平分割，並分配給多臺服務器（或多個實例），每臺服務器能夠獨立工做，具有共同的schema，好比MySQL Proxy和Google的各類架構，只需增長服務器數就能夠增長處理能力和容量。

不少 Nosql數據庫都是基於 MPP Shared Nothing架構的，好比

Greenplum是一種基於PostgreSQL的分佈式數據庫。其採用shared nothing架構（MPP），主機，操做系統，內存，存儲都是自我控制的，不存在共享。也就是每一個節點都是一個單獨的數據庫。節點之間的信息交互是經過節點互聯網絡實現。經過將數據分佈到多個節點上來實現規模數據的存儲，經過並行查詢處理來提升查詢性能。
這個就像是把小數據庫組織起來，聯合成一個大型數據庫。將數據分片，存儲在每一個節點上。每一個節點僅查詢本身的數據。所獲得的結果再通過主節點處理獲得最終結果。經過增長節點數目達到系統線性擴展。

elasticsearch也是一種MPP架構的數據庫，Presto、Impala等都是MPP engine，各節點不共享資源，每一個executor能夠獨自完成數據的讀取和計算，缺點在於怕stragglers，遇到後整個engine的性能降低到該straggler的能力，所謂木桶的短板，這也是爲何MPP架構不適合異構的機器，要求各節點配置同樣。

Spark SQL應該仍是算作Batching Processing, 中間計算結果須要落地到磁盤，因此查詢效率沒有MPP架構的引擎（如Impala）高。

二、MPP架構特徵

● 任務並行執行;

● 數據分佈式存儲(本地化);

● 分佈式計算;

● 私有資源;

● 橫向擴展;

● Shared Nothing架構。

三、基於MPP架構的數據庫架構

這種架構中的每個節點（node）都是獨立的、自給的、節點之間對等，並且整個系統中不存在單點瓶頸，具備很是強的擴展性。

 

2、SMP(Symmetric Multi-Processor)架構

SMP又稱對稱多處理器結構，SMP系統內有許多緊耦合多處理器，在這樣的系統中，全部的CPU共享所有資源，如總線，內存和I/O系統等;

所謂對稱多處理器結構，是指服務器中多個 CPU 對稱工做，無主次或從屬關係。各 CPU 共享相同的物理內存，每一個 CPU 訪問內存中的任何地址所需時間是相同的，所以 SMP 也被稱爲一致存儲器訪問結構 (UMA ： Uniform Memory Access) 。對 SMP 服務器進行擴展的方式包括增長內存、使用更快的 CPU 、增長 CPU 、擴充 I/O( 槽口數與總線數 ) 以及添加更多的外部設備 ( 一般是磁盤存儲 ) 。

主要特徵是共享，系統中全部資源 (CPU 、內存、 I/O 等 ) 都是共享的。也正是因爲這種特徵，致使了SMP 服務器的主要問題，那就是它的擴展能力很是有限。對於 SMP 服務器而言，每個共享的環節均可能形成 SMP 服務器擴展時的瓶頸，而最受限制的則是內存。因爲每一個 CPU 必須經過相同的內存總線訪問相同的內存資源，所以隨着 CPU 數量的增長，內存訪問衝突將迅速增長，最終會形成 CPU 資源的浪費，使 CPU 性能的有效性大大下降。實驗證實， SMP 服務器 CPU 利用率最好的狀況是 2 至 4 個 CPU 。

3、SOA 架構

SOA 即面向服務的架構，將應用程序的不一樣功能單元（稱爲服務）進行拆分，並經過這些服務之間定義良好的接口和協議聯繫起來，接口是採用中立的方式進行定義的，它應該獨立於實現服務的硬件平臺、操做系統和編程語言。這使得構件在各類各樣的系統中的服務能夠以一種統一和通用的方式進行交互。

面向服務架構，它能夠根據需求經過網絡對鬆散耦合的粗粒度應用組件進行分佈式部署、組合和使用。服務層是SOA的基礎，能夠直接被應用調用，從而有效控制系統中與軟件代理交互的人爲依賴性，SOA是一種粗粒度、鬆耦合服務架構，服務之間經過簡單、精肯定義接口進行通信，不涉及底層編程接口和通信模型。

鬆耦合系統腳骨的好處有兩點：

一、它的靈活性，它很是的靈活。

二、當組成整個應用程序的每一個服務的內部結構和實現逐漸地發生改變時，它可以繼續存在。與之相反，緊耦合意味着應用程序的不一樣組件之間的接口與其功能和結構是緊密相連的，於是當須要對部分或整個應用程序進行某種形式的更改時，它們就顯得很是脆弱。

 

 

一個服務一般以獨立的形式存在與操做系統進程中。各個服務之間經過網絡調用跟SOA 相提並論的還有一個ESB（企業服務總線），單來講ESB 就是一根管道，用來鏈接各個服務節點。爲了集成不一樣系統，不一樣協議的服務，ESB 作了消息的轉化解釋和路由工做，讓不一樣的服務互聯互通。

SOA 所解決的核心問題：

1. 系統集成：站在系統的角度，解決企業系統間的通訊問題，把原先散亂、無規劃的系統間的網狀結構，梳理成規整、可治理的系統間星形結構，這一步每每須要引入一些產品，好比ESB、以及技術規範、服務管理規範；
這一步解決的核心問題是【有序】

2. 系統的服務化：站在功能的角度，把業務邏輯抽象成可複用、可組裝的服務，經過服務的編排實現業務的快速再生，目的：把原先固有的業務功能轉變爲通用的業務服務，實現業務邏輯的快速複用；這一步解決的核心問題是【複用】

3. 業務的服務化：站在企業的角度，把企業職能抽象成可複用、可組裝的服務；把原先職能化的企業架構轉變爲服務化的企業架構，進一步提高企業的對外服務能力；「前面兩步都是從技術層面來解決系統調用、系統功能複用的問題」。第三步，則是以業務驅動把一個業務單元封裝成一項服務。

本文做者：張永清 來源出處：http://www.javashuo.com/article/p-tymdoedk-b.html

4、微服務架構

微服務架構其實和SOA 架構相似,微服務是在SOA 上作的昇華，微服務架構強調的一個重點是「業務須要完全的組件化和服務化」，原有的單個業務系統會拆分爲多個能夠獨立開發、設計、運行的小應用。這些小應用之間經過服務完成交互和集成。

組件表示一個能夠獨立更換和升級的單元，就像PC 中的CPU、內存、顯卡、硬盤同樣，獨立且能夠更換升級而不影響其餘單元。若是咱們把PC 做爲組件以服務的方式構建，那麼這臺PC 只須要維護主板和一些必要的外部設備。CPU、內存、硬盤都是以組件方式提供服務，PC 須要調用CPU 作計算處理，只須要知道CPU 這個組件的地址便可。

 

 

 

 

SOA與微服務區別：

一、SOA注重重用，微服務注重重寫

SOA 的主要目的是爲了企業各個系統更加容易地融合在一塊兒。
微服務一般由重寫一個模塊開始。要把整個巨石型的應用重寫是有很大的風險的，也不必定必要。咱們向微服務遷移的時候一般從耦合度最低的模塊或對擴展性要求最高的模塊開始。

把它們一個一個剝離出來用敏捷地重寫，能夠嘗試最新的技術和語言和框架，而後 單獨佈署。它一般不依賴其餘服務。微服務中經常使用的 API Gateway 的模式主要目的也不是重用代碼。

而是減小客戶端和服務間的往來。API gateway 模式不等同與 Facade 模式，咱們可使用如 Future 之類的調用，甚至返回不完整數據。

二、SOA注重水平服務，微服務注重垂直服務

本文做者：張永清 來源出處：http://www.javashuo.com/article/p-tymdoedk-b.html

SOA 設計喜歡給服務分層(如 Service Layers 模式)。咱們經常見到一個 Entity 服務層的設計，美其名曰 Data Access Layer。這種設計要求全部的服務都經過這個 Entity 服務層。來獲取數據。這種設計很是不靈活，好比每次數據層的改動均可能影響到全部業務層的服務。而每一個微服務一般有它本身獨立的 Data Store。咱們在拆分數據庫時能夠適當的作些去範式化，讓它不須要依賴其餘服務的數據。

微服務一般是直接面對用戶的，每一個微服務一般直接爲用戶提供某個功能。相似的功能可能針對手機有一個服務，針對機頂盒是另一個服務。在 SOA 設計模式中這種狀況一般會用到 Multi-ChannelEndpoint 的模式返回一個大而全的結果兼顧到全部的客戶端的需求。

三、SOA注重自上而下，微服務注重自下而上

SOA 架構在設計開始時會先定義好服務合同。它喜歡集中管理全部的服務，包括集中管理業務邏輯，數據，流程，Schema 等。它使用 Enterprise Inventory 和 Service Composition 等方法來集中管理服務。SOA 架構一般會預先把每一個模塊服務接口都定義好。模塊系統間的通信必須遵照這些接口，各服務是針對他們的調用者。

SOA 架構適用於 TO GAF 之類的架構方法論。

微服務則敏捷得多。只要用戶用獲得，就先把這個服務挖出來。而後針對性的，快速確認業務需求，快速開發迭代。

微服務與 SOA 有不少相同之處。二者都屬於典型的、包含鬆耦合分佈式組件的系統結構。在圍繞着服務的概念建立架構這一方面，微服務提供了一種更清晰、定義更良好的方式。微服務的原則與敏捷軟件開發思想是高度一致的，而它與 SOA 原則的演化的目標也是相同的，則減小傳統的企業服務總線開發的高複雜性。二者之間最關鍵的區別在於，微服務專一於以自治的方式產生價值。可是兩種架構背後的意圖是不一樣的：SOA 嘗試將應用集成，通常採用中央管理模式來確保各應用可以交互運做。微服務嘗試部署新功能，快速有效地擴展開發團隊。它着重於分散管理、代碼再利用與自動化執行。

5、架構設計圖

一、技術架構

從技術層面描述，主要是分層模型，例如持久層、數據層、邏輯層、應用層、表現層等，而後每層使用什麼技術框架，例如Spring、hibernate、ioc、MVC、成熟的類庫、中間件、WebService等，分別說明，要求這些技術可以將整個系統的主要實現歸納

二、系統架構

指的完整系統的組成架構，例如系統分紅幾個部分？服務平臺、管理門戶、終端門戶、ATM門戶、外部系統以及接口、支撐系統等，將這些系統進行合理的劃分。而後再進行功能分類細分，總之，將整個系統業務分解爲邏輯功能模塊，而且科學合理，就是系統架構

三、部署架構

指的是系統如何部署，包括應用的節點機器，網絡、交換機，防火牆等。好比採用什麼網絡，nginx 部署幾臺，vip如何轉發、APP應用部署多少個節點等。

四、數據架構

數據架構指導數據庫的設計. 不只僅要考慮開發中涉及到的數據庫，實體模型，也要考慮物理架構中數據存儲的設計。

五、代碼架構

子系統代碼架構主要爲開發人員提供切實可行的指導，若是代碼架構設計不足，就會形成影響全局的架構設計。好比公司內不一樣的開發團隊使用不一樣的技術棧或者組件，結果公司總體架構設計就會失控。

代碼架構主要定義：

①. 代碼單元:

配置設計框架、類庫。

②. 代碼單元組織：

編碼規範，編碼的慣例。項目模塊劃分頂層文件結構設計，好比mvc設計。依賴關係

6、分佈式架構中分佈式事務的解決方案

一、分佈式架構中分佈式事務問題以及2PC/3PC協議

1）、單機ACID事務：

ACID原則是數據庫事務正常執行的四個，分別指原子性、一致性、獨立性及持久性。可是隨着項目愈來愈大，數據量愈來愈多，單臺數據庫的磁盤系統被佔滿了或是單張表數據量太大，致使客戶端請求數據庫時存在阻塞問題或者是效率問題，此時的作法是將數據庫進行分庫分表，將數據按必定的規則（好比按照不一樣的業務）分配到不一樣的機器上，此時數據會在多個分佈於不一樣服務器中的數據庫，因此產生了分佈式事務的問題。

2）、分佈式事務：

分佈式事務指的是跨系統、跨機器之間的事務，因爲其不知足單機的ACID特性，因此分佈式事務每每很複雜。分佈式數據庫的通常劃分方式以下：

• 垂直切分：將單個表按業務細化出多張表，每張表存放着不一樣的字段，當須要使用到多張表時將其鏈接在一塊兒（join）便可獲取到所需的數據。

• 水平切分：使用多臺數據庫或表，將原先位於一個庫或表的數據按某種規則映射到不一樣的機器上，以此來減小原先單庫或單表中所含的數據大小。
• 按業務流程拆分：
  • 一般，出現分庫分表的場景還和業務拆分相關，一個很大的系統每每會拆分爲多個小系統，每一個小系統之間經過RPC來進行調用，相互協調完成業務，這也會出現分佈式事務的問題：

 

 

 

3）、兩階段提交協議（2PC）：

兩階段提交協議(2PC)是處理分佈式事務的一種基本協議，兩階段指的是prepare和commit/rollback階段，而且劃分出了事務管理器與資源管理器角色：

在兩階段提交協議中，有一個事務管理器和多個資源管理器，事務管理器分兩階段協調資源管理器。

在第一階段，事務管理器詢問全部資源管理器準備是否成功（prepare）。

若是全部資源均準備成功，那麼在第二階段事務管理器會要求全部資源管理器執行提交操做（commit）。

若是任一資源管理器在第一階段返回準備失敗，那麼事務管理器會要求全部資源管理器在第二階段執行回滾操做（rollback）。

經過事務管理器的兩階段協調，最終全部資源管理器要麼所有提交，要麼所有回滾，最終狀態都是一致的。
　　

•  該分佈式系統中，存在一個節點做爲協調者(Coordinator)，其餘節點做爲參與者(Cohorts)。且節點之間能夠進行網絡通訊。
• 全部節點都採用預寫式日誌，且日誌被寫入後即被保持在可靠的存儲設備上，即便節點損壞不會致使日誌數據的消失。
• 全部節點不會永久性損壞，即便損壞後仍然能夠恢復。

優缺點：

優勢：原理簡單，實現方便。

缺點：
同步阻塞問題。執行過程當中，全部參與節點都是事務阻塞型的。當參與者佔有公共資源時，其餘第三方節點訪問公共資源不得不處於阻塞狀態。

單點故障。因爲協調者的重要性，一旦協調者發生故障。參與者會一直阻塞下去。尤爲在第二階段，協調者發生故障，那麼全部的參與者還都處於鎖定事務資源的狀態中，而沒法繼續完成事務操做。（若是是協調者掛掉，能夠從新選舉一個協調者，可是沒法解決由於協調者宕機致使的參與者處於阻塞狀態的問題）

數據不一致。在二階段提交的階段二中，當協調者向參與者發送commit請求以後，發生了局部網絡異常或者在發送commit請求過程當中協調者發生了故障，這回致使只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求以後就會執行commit操做。可是其餘部分未接到commit請求的機器則沒法執行事務提交。因而整個分佈式系統便出現了數據部一致性的現象。

二階段沒法解決的問題：協調者再發出commit消息以後宕機，而惟一接收到這條消息的參與者同時也宕機了。那麼即便協調者經過選舉協議產生了新的協調者，這條事務的狀態也是不肯定的，沒人知道事務是否被已經提交。

4）、三階段提交協議（3PC）

3PC，Three-Phase Commit，三階段提交協議，由CanCommit、PreCommit、Do Commit三階段組成。三階段提交協議（3PC）相較於2PC來講，新增了一個預提交階段（preCommit）與超時機制來再次校驗當前是否所有資源管理器（參與者）都可以提交成功（或超時），若成功則進行真正的提交階段，若不成功則回滾。

階段一：Can Commit

1. 事務詢問。協調者向參與者發送一個包含事務內容的canCommit請求，詢問是否能夠執行事務提交操做，並開始等待參與者相應。
2. 參與者向協調者反饋事務詢問的相應。

Can Commit階段和2PC的提交請求階段同樣。

階段二：PreCommit

執行事務PreCommit

假如協調者獲取的全部相應都是YES則執行事務預提交。

1. 發送預提交請求。
2. 事務預提交，執行事務操做，並將Undo和Redo信息記錄到事務日誌中
3. 各參與中向協調者反饋事務執行結果的相應。

階段三：doCommit
真正的事務提交，存在兩種結果：

執行提交

1. 發送提交請求 協調者由預提交轉換到提交狀態，向全部參與者發送doCommit請求
2. 事務提交 參與者收到doCommit請求後，執行事務提交
3. 反饋事務提交結果 參與者完成事務提交後，向協調者發送ACK消息
4. 完成事務 協調者接收到全部參與者反饋的ACK消息後，完成事務

中斷事務

1. 發送中斷請求
2. 事務回滾
3. 反饋事務回滾結果
4. 中斷事務

進入階段三也存在兩種故障：

1. 協調者出現問題
2. 協調者和參與者網絡出現問題。

不管出現那種狀況，最終都會導參與者沒法及時接收到來自接收到協調者的doCommit請求或者是abort請求，針對這樣的異常，參與者都會在等待超時以後，繼續進行事務提交。

 

 

優勢：下降參與者阻塞範圍，並可以在出現單點故障後繼續達成一致

缺點：引入preCommit階段，在這個階段若是出現網絡分區，協調者沒法與參與者正常通訊，參與者依然會進行事務提交，形成數據不一致。

3PC解決了參與者的阻塞範圍，而且解決了協調者單點故障的問題。可是3PC仍是存在問題：3PC沒法解決當存在網絡分區的時候，參與者沒法通訊的問題，在這種狀況下，參與者只有一部分參與者可以執行提交請求，形成參與者數據不一致。

二、帶有業務侵入的分佈式事務解決方案：

1）、消息隊列：

對於分佈式事務問題，最簡單的一種方式是使用消息隊列來做爲消息表，在業務的調用流程中經過消息隊列來傳達事務的執行結果，而後下一個流程做爲消費者消費這個執行結果便可。因爲要藉助消息隊列來完成這個過程，因此這種作法是有業務侵入的。

優缺點：

使用MQ解決分佈式事務問題有以下的優勢和缺點：

優勢：簡單易實現，而且隨着MQ集羣的出現和RocketMQ的prepare機制，使得這種方案具有高可用性和高性能，能達到最終一致性。是最多見的解決方案。

缺點：消費者只能成功，不能失敗，若消費者失敗也不能回滾前者的事務；具備必定的業務侵入性。

2）、TCC：

TCC是一種經典的2PC解決方案，也就是將整個事務控制過程分爲Try、Confirm和Cancel階段，經過Try階段來對全部的參與者進行資源的檢查與預留，若是Try階段所有成功，那麼就對全部參與者進行Confirm；若是Try階段出現一者失敗，那麼就對全部參與者進行Cancel。

因爲Try、Confirm、Cancel 3個方法均由業務編碼實現，因此TCC是具有強業務侵入性的。

 

 

• 併發控制：在實現TCC時，應當考慮併發性問題，將鎖的粒度降到最低，以最大限度提升分佈式事務的併發性。
• 冪等性：因爲網絡可能出現數據包重傳的狀況，因此須要考慮Try、Confirm和Cancel這三個階段的冪等性，也就是Try、Confirm、Cancel 執行一次和執行屢次的業務結果是同樣的。

3）、Saga：

Saga事務核心思想是將長事務拆分爲多個本地短事務，由Saga事務協調器協調，若是正常結束那就正常完成，若是某個步驟失敗，則根據相反順序一次調用補償操做。

Saga事務基本協議以下：

• 每一個Saga事務由一系列冪等的有序子事務Ti組成。
• 每一個Ti都有對應的冪等補償動做Ci，補償動做用於撤銷Ti形成的結果，補償過程也被稱爲衝正過程。

 

 例如如今T一、T二、T3爲扣減庫存、建立訂單、支付訂單，若是在支付訂單時失敗了，那麼就對原先的操做作回退，也就是補償衝正：C3支付回滾、C2訂單回滾、C1庫存回滾，使得數據回到最開始的狀態。

 

 能夠將Saga的各事務作成服務編排，制訂好每一個事務之間的調用順序和回退順序，這樣能夠將整個Saga事務的流程清晰化和規範化：

優缺點：

優勢：實現簡單，而且整個Saga事務的流程都十分地清晰，基於消息隊列構建的Saga事務還能夠避免單點問題。

缺點：具備業務侵入性，須要制訂好每一個子事務失敗後對應的回滾（衝正）操做。

能夠看到，和TCC相比，Saga沒有「預留」動做，它的Ti就是直接提交到庫。

三、業務非侵入的解決方案：

1）、FMT：

FMT（Framework-managed transaction）即框架管理事務，是一種無侵入的事務解決方案。該模式下，分佈式事務框架會託管全部的事務操做，事務的一階段和二階段操做均由框架自動生成。

FMT一階段：攔截業務SQL語句，保存SQL執行前的快照，執行SQL，而且添加相應的行鎖，避免出現併發衝突。

 

 FMT二階段：執行其餘業務SQL，若都成功，那麼刪除一階段中產生的鎖和快照；若其一失敗，則重作快照，回滾數據，刪除行鎖。

 

 

優缺點

優勢：整個事務處理過程由框架自動化完成，無需人工參與，無業務侵入性。

缺點：因爲基於框架來對SQL、事務等進行攔截，因此會有性能損耗（譬如須要使用註解、反射、動態代理等機制）。

2）、XA：

XA模式是另一種無侵入的分佈式事務解決方案，不一樣於FMT的是，XA模式下，全部一階段和二階段都由數據庫來完成，而不是由框架來完成。其原理與FMT類似，都是藉助了快照來完成回退操做。

 

 

優缺點

優勢：主流的數據庫都實現了XA分佈式事務方案，因此能夠方便地實現。

缺點：嚴重依賴於數據庫自身的規範和接口，不能高效拓展。

四、總結

 

 

分佈式事務的解決基礎是2PC和3PC協議。

2PC和3PC協議都劃分出兩個角色：事務發起者（事務管理器）和跟隨者（資源管理器）。

2PC在第一階段，事務管理器詢問全部資源管理器準備是否成功（prepare）。若是全部資源均準備成功，那麼在第二階段事務管理器會要求全部資源管理器執行提交操做（commit）。若是任一資源管理器在第一階段返回準備失敗，那麼事務管理器會要求全部資源管理器在第二階段執行回滾操做（rollback）。經過事務管理器的兩階段協調，最終全部資源管理器要麼所有提交，要麼所有回滾，最終狀態都是一致的。

3PC相對於2PC來講，增長了超時ACK判斷以及在真正提交以前增長了預提交階段（pre commit）來保證事務可以所有提交成功。

分佈式事務的常看法決方案分爲兩大類，一類是業務侵入點、另外一類是業務非侵入的。

業務侵入的有MQ、TCC、Saga這三種解決方案。MQ的優勢是實現簡單而且不會存在單點問題，可是須要使用特定的MQ譬如RocketMQ中的Half Message纔可以知足需求，而且消費者對於消息的消費是必定須要成功的；TCC是一種常用的方案，它的作法是將整個分佈式事務拆分爲三個部分：Try、Confirm和Cancel，在Try階段進行資源的檢查與預留，在第二階段進行事務的統一Confirm和Cancel；Saga的作法是將長事務拆分紅順序執行的子事務，若是其中一個子事務執行失敗，則須要繼續相應的事務補償、回滾和數據衝正。

非業務侵入的解決方案有FMT和XA兩種選擇，FMT的思路是由框架來對SQL進行攔截，而且保存以前的快照，在第二個階段中若是所有事務都執行成功那麼就刪除以前的快照而且釋放掉行鎖，若是執行失敗，那麼會執行以前的快照。XA和FMT的作法是相似的，不過XA的兩個階段都由數據庫自身來保證。

最後，其實每一種方案都有各自的優勢與缺點，要結合自身業務的狀況和系統的特性來選擇具體的方案，選擇性地犧牲某些方面以保證某些方面。

 

未完待續，後續會補充大數據相關的架構