一、MPP 架構
1、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）高。
2、MPP架構特征
● 任務并行執行;
● 資料分布式存儲(本地化);
● 分布式計算;
● 私有資源;
● 橫向擴充;
● Shared Nothing架構。
3、基于MPP架構的資料庫架構
這種架構中的每一個節點（node）都是獨立的、自給的、節點之間對等，而且整個系統中不存在單點瓶頸，具有非常強的擴充性。
二、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 。
三、SOA 架構
SOA 即面向服務的架構，将應用程式的不同功能單元（稱為服務）進行拆分，并通過這些服務之間定義良好的接口和協定聯系起來，接口是采用中立的方式進行定義的，它應該獨立于實作服務的硬體平台、作業系統和程式設計語言。這使得構件在各種各樣的系統中的服務可以以一種統一和通用的方式進行互動。
面向服務架構，它可以根據需求通過網絡對松散耦合的粗粒度應用元件進行分布式部署、組合和使用。服務層是SOA的基礎，可以直接被應用調用，進而有效控制系統中與軟體代理互動的人為依賴性，SOA是一種粗粒度、松耦合服務架構，服務之間通過簡單、精确定義接口進行通訊，不涉及底層程式設計接口和通訊模型。
松耦合系統腳骨的好處有兩點：
1、它的靈活性，它非常的靈活。
2、當組成整個應用程式的每個服務的内部結構和實作逐漸地發生改變時，它能夠繼續存在。與之相反，緊耦合意味着應用程式的不同元件之間的接口與其功能和結構是緊密相連的，因而當需要對部分或整個應用程式進行某種形式的更改時，它們就顯得非常脆弱。
一個服務通常以獨立的形式存在與作業系統程序中。各個服務之間通過網絡調用跟SOA 相提并論的還有一個ESB（企業服務總線），單來說ESB 就是一根管道，用來連接配接各個服務節點。為了內建不同系統，不同協定的服務，ESB 做了消息的轉化解釋和路由工作，讓不同的服務互聯互通。
SOA 所解決的核心問題：
1. 系統內建：站在系統的角度，解決企業系統間的通信問題，把原先散亂、無規劃的系統間的網狀結構，梳理成規整、可治理的系統間星形結構，這一步往往需要引入一些産品，比如ESB、以及技術規範、服務管理規範；
這一步解決的核心問題是【有序】
2. 系統的服務化：站在功能的角度，把業務邏輯抽象成可複用、可組裝的服務，通過服務的編排實作業務的快速再生，目的：把原先固有的業務功能轉變為通用的業務服務，實作業務邏輯的快速複用；這一步解決的核心問題是【複用】
3. 業務的服務化：站在企業的角度，把企業職能抽象成可複用、可組裝的服務；把原先職能化的企業架構轉變為服務化的企業架構，進一步提升企業的對外服務能力；“前面兩步都是從技術層面來解決系統調用、系統功能複用的問題”。第三步，則是以業務驅動把一個業務單元封裝成一項服務。
本文作者：張永清 來源出處：https://www.cnblogs.com/laoqing/p/13042432.html
四、微服務架構
微服務架構其實和SOA 架構類似,微服務是在SOA 上做的升華，微服務架構強調的一個重點是“業務需要徹底的元件化和服務化”，原有的單個業務系統會拆分為多個可以獨立開發、設計、運作的小應用。這些小應用之間通過服務完成互動和內建。
元件表示一個可以獨立更換和更新的單元，就像PC 中的CPU、記憶體、顯示卡、硬碟一樣，獨立且可以更換更新而不影響其他單元。如果我們把PC 作為元件以服務的方式建構，那麼這台PC 隻需要維護主機闆和一些必要的外部裝置。CPU、記憶體、硬碟都是以元件方式提供服務，PC 需要調用CPU 做計算處理，隻需要知道CPU 這個元件的位址即可。
SOA與微服務差別：
1、SOA注重重用，微服務注重重寫
SOA 的主要目的是為了企業各個系統更加容易地融合在一起。
微服務通常由重寫一個子產品開始。要把整個巨石型的應用重寫是有很大的風險的，也不一定必要。我們向微服務遷移的時候通常從耦合度最低的子產品或對擴充性要求最高的子產品開始。
把它們一個一個剝離出來用靈活地重寫，可以嘗試最新的技術和語言和架構，然後 單獨布署。它通常不依賴其他服務。微服務中常用的 API Gateway 的模式主要目的也不是重用代碼。
而是減少用戶端和服務間的往來。API gateway 模式不等同與 Facade 模式，我們可以使用如 Future 之類的調用，甚至傳回不完整資料。
2、SOA注重水準服務，微服務注重垂直服務
SOA 設計喜歡給服務分層(如 Service Layers 模式)。我們常常見到一個 Entity 服務層的設計，美其名曰 Data Access Layer。這種設計要求所有的服務都通過這個 Entity 服務層。來擷取資料。這種設計非常不靈活，比如每次資料層的改動都可能影響到所有業務層的服務。而每個微服務通常有它自己獨立的 Data Store。我們在拆分資料庫時可以适當的做些去範式化，讓它不需要依賴其他服務的資料。
微服務通常是直接面對使用者的，每個微服務通常直接為使用者提供某個功能。類似的功能可能針對手機有一個服務，針對機頂盒是另外一個服務。在 SOA 設計模式中這種情況通常會用到 Multi-ChannelEndpoint 的模式傳回一個大而全的結果兼顧到所有的用戶端的需求。
3、SOA注重自上而下，微服務注重自下而上
SOA 架構在設計開始時會先定義好服務合同。它喜歡集中管理所有的服務，包括集中管理業務邏輯，資料，流程，Schema 等。它使用 Enterprise Inventory 和 Service Composition 等方法來集中管理服務。SOA 架構通常會預先把每個子產品服務接口都定義好。子產品系統間的通訊必須遵守這些接口，各服務是針對他們的調用者。
SOA 架構适用于 TO GAF 之類的架構方法論。
微服務則靈活得多。隻要使用者用得到，就先把這個服務挖出來。然後針對性的，快速确認業務需求，快速開發疊代。
微服務與 SOA 有很多相同之處。兩者都屬于典型的、包含松耦合分布式元件的系統結構。在圍繞着服務的概念建立架構這一方面，微服務提供了一種更清晰、定義更良好的方式。微服務的原則與靈活軟體開發思想是高度一緻的，而它與 SOA 原則的演化的目标也是相同的，則減少傳統的企業服務總線開發的高複雜性。兩者之間最關鍵的差別在于，微服務專注于以自治的方式産生價值。但是兩種架構背後的意圖是不同的：SOA 嘗試将應用內建，一般采用中央管理模式來確定各應用能夠互動運作。微服務嘗試部署新功能，快速有效地擴充開發團隊。它着重于分散管理、代碼再利用與自動化執行。
五、架構設計圖
1、技術架構
從技術層面描述，主要是分層模型，例如持久層、資料層、邏輯層、應用層、表現層等，然後每層使用什麼技術架構，例如Spring、hibernate、ioc、MVC、成熟的類庫、中間件、WebService等，分别說明，要求這些技術能夠将整個系統的主要實作概括
2、系統架構
指的完整系統的組成架構，例如系統分成幾個部分？服務平台、管理門戶、終端門戶、ATM門戶、外部系統以及接口、支撐系統等，将這些系統進行合理的劃分。然後再進行功能分類細分，總之，将整個系統業務分解為邏輯功能子產品，并且科學合理，就是系統架構
3、部署架構
指的是系統如何部署，包括應用的節點機器，網絡、交換機，防火牆等。比如采用什麼網絡，nginx 部署幾台，vip如何轉發、APP應用部署多少個節點等。
4、資料架構
資料架構指導資料庫的設計. 不僅僅要考慮開發中涉及到的資料庫，實體模型，也要考慮實體架構中資料存儲的設計。
5、代碼架構
子系統代碼架構主要為開發人員提供切實可行的指導，如果代碼架構設計不足，就會造成影響全局的架構設計。比如公司内不同的開發團隊使用不同的技術棧或者元件，結果公司整體架構設計就會失控。
代碼架構主要定義：
①. 代碼單元:
配置設計架構、類庫。
②. 代碼單元組織：
編碼規範，編碼的慣例。項目子產品劃分頂層檔案結構設計，比如mvc設計。依賴關系
六、分布式架構中分布式事務的解決方案
1、分布式架構中分布式事務問題以及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）與逾時機制來再次校驗目前是否全部資料總管（參與者）都能夠送出成功（或逾時），若成功則進行真正的送出階段，若不成功則復原。
事務詢問。協調者向參與者發送一個包含事務内容的canCommit請求，詢問是否可以執行事務送出操作，并開始等待參與者相應。
參與者向協調者回報事務詢問的相應。
Can Commit階段和2PC的送出請求階段一樣。
執行事務PreCommit
假如協調者擷取的所有相應都是YES則執行事務預送出。
發送預送出請求。
事務預送出，執行事務操作，并将Undo和Redo資訊記錄到事務日志中
各參與中向協調者回報事務執行結果的相應。
階段三：doCommit
真正的事務送出，存在兩種結果：
執行送出
發送送出請求 協調者由預送出轉換到送出狀态，向所有參與者發送doCommit請求
事務送出 參與者收到doCommit請求後，執行事務送出
回報事務送出結果 參與者完成事務送出後，向協調者發送ACK消息
完成事務 協調者接收到所有參與者回報的ACK消息後，完成事務
中斷事務
發送中斷請求
事務復原
回報事務復原結果
進入階段三也存在兩種故障：
協調者出現問題 協調者和參與者網絡出現問題。
無論出現那種情況，最終都會導參與者無法及時接收到來自接收到協調者的doCommit請求或者是abort請求，針對這樣的異常，參與者都會在等待逾時之後，繼續進行事務送出。
優點：降低參與者阻塞範圍，并能夠在出現單點故障後繼續達成一緻
缺點：引入preCommit階段，在這個階段如果出現網絡分區，協調者無法與參與者正常通信，參與者依然會進行事務送出，造成資料不一緻。
3PC解決了參與者的阻塞範圍，并且解決了協調者單點故障的問題。但是3PC還是存在問題：3PC無法解決當存在網絡分區的時候，參與者無法通信的問題，在這種情況下，參與者隻有一部分參與者能夠執行送出請求，造成參與者資料不一緻。
2、帶有業務侵入的分布式事務解決方案：
1）、消息隊列：
對于分布式事務問題，最簡單的一種方式是使用消息隊列來作為消息表，在業務的調用流程中通過消息隊列來傳達事務的執行結果，然後下一個流程作為消費者消費這個執行結果即可。由于要借助消息隊列來完成這個過程，是以這種做法是有業務侵入的。
使用MQ解決分布式事務問題有如下的優點和缺點：
優點：簡單易實作，并且随着MQ叢集的出現和RocketMQ的prepare機制，使得這種方案具備高可用性和高性能，能達到最終一緻性。是最常見的解決方案。
缺點：消費者隻能成功，不能失敗，若消費者失敗也不能復原前者的事務；具有一定的業務侵入性。
重點推薦：RocketMQ，因為其支援事務消息，RocketMQ的事務消息是基于2PC的送出協定。
RocketMQ通過兩個内部的topic來實作對消息的兩階段支援，RocketMQ在實作事務消息時，實際上是通過将生産投遞過來的消息（消息上帶有事務辨別）投遞到一個名為RMS_SYS_TRANS_HALF_TOPIC的topic中，而不是投遞到真正的topic中，這個過程是第一階段(prepare)，然後producer再通過TransactionListener的executeLocalTransaction方法執行本地事務，當producer的localTransaction處理成功或者失敗後，producer會向broker發送commit或rollback指令，如果是commit，則broker會将投遞到RMQ_SYS_TRANS_HALF_TOPIC中的消息投遞到真實的topic中，然後再投遞一個表示删除的消息到RMQ_SYS_TRANS_OP_HALF_TOPIC中，表示目前事務已完成；如果是rollback，則沒有投遞到真實topic的過程，隻需要投遞表示删除的消息到RMQ_SYS_TRANS_OP_HALF_TOPIC。最後，消費者和消費普通的消息一樣消費事務消息。
整個過程如果沒有遇到問題，則一切OK，但整個過程中可能會遇到以下錯誤：
第一階段（prepare）失敗：給應用傳回發送消息失敗
事務失敗：發送復原指令給broker，由broker執行消息的復原
Commit或rollback失敗：由broker定時向producer發起事務檢查，如果本地事務成功，則送出消息事務，否則復原消息事務
事務狀态的檢查有兩種情況：
commit/rollback：broker會執行相應的commit/rollback操作
如果是TRANSACTION_NOT_TYPE，則一段時間後會再次檢查，當檢查的次數超過上限（預設15次）則丢棄消息
異常情況示意圖如下：
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造成的結果，補償過程也被稱為沖正過程。
例如現在T1、T2、T3為扣減庫存、建立訂單、支付訂單，如果在支付訂單時失敗了，那麼就對原先的操作做回退，也就是補償沖正：C3支付復原、C2訂單復原、C1庫存復原，使得資料回到最開始的狀态。
可以将Saga的各事務做成服務編排，制訂好每個事務之間的調用順序和回退順序，這樣可以将整個Saga事務的流程清晰化和規範化：
優點：實作簡單，并且整個Saga事務的流程都十分地清晰，基于消息隊列建構的Saga事務還可以避免單點問題。
缺點：具有業務侵入性，需要制訂好每個子事務失敗後對應的復原（沖正）操作。
可以看到，和TCC相比，Saga沒有“預留”動作，它的Ti就是直接送出到庫。
3、業務非侵入的解決方案：
1）、FMT：
FMT（Framework-managed transaction）即架構管理事務，是一種無侵入的事務解決方案。該模式下，分布式事務架構會托管所有的事務操作，事務的一階段和二階段操作均由架構自動生成。
FMT一階段：攔截業務SQL語句，儲存SQL執行前的快照，執行SQL，并且添加相應的行鎖，避免出現并發沖突。
FMT二階段：執行其他業務SQL，若都成功，那麼删除一階段中産生的鎖和快照；若其一失敗，則重做快照，復原資料，删除行鎖。
優點：整個事務處理過程由架構自動化完成，無需人工參與，無業務侵入性。
缺點：由于基于架構來對SQL、事務等進行攔截，是以會有性能損耗（譬如需要使用注解、反射、動态代理等機制）。
2）、XA：
XA模式是另外一種無侵入的分布式事務解決方案，不同于FMT的是，XA模式下，所有一階段和二階段都由資料庫來完成，而不是由架構來完成。其原理與FMT相似，都是借助了快照來完成回退操作。
優點：主流的資料庫都實作了XA分布式事務方案，是以可以友善地實作。
缺點：嚴重依賴于資料庫自身的規範和接口，不能高效拓展。
3）、Atomikos
對于資料庫層面的分布式事務而言，JTA（Java Transaction API，XA的JAVA實作方案）是一個不錯的解決方案，通常JTA需要應用伺服器的支援，但在查閱SpringBoot的文檔時發現，它推薦了Atomikos和 Bitronix兩種無需伺服器支援的分布式事務元件，在這兩個元件中，Atomikos更受大家的好評，是以建議選擇使用Atomikos。Atomikos是一個公司的名字，AtomikosTransactionsEssentials是其開源的分布式事務軟體包，而ExtremeTransactions是商業的分布式事務軟體包。TransactionsEssentials是基于apache-license的，是JTA/XA的開源實作，支援Java Application和J2EE應用。 需要的jar包：jta.jar、transactions-essentials-all.jar。（可以在http://www.atomikos.com下載下傳）。
github位址：https://github.com/atomikos/transactions-essentials
4）、Seata
Seata 是一款開源的分布式事務解決方案，緻力于在微服務架構下提供高性能和簡單易用的分布式事務服務，由阿裡巴巴一起參與開源的。目前還處于成長期，很多功能還有待實作和完善。
官方首頁：http://seata.io/zh-cn/index.html
github位址：https://github.com/seata/seata
4、總結
分布式事務的解決基礎是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的兩個階段都由資料庫自身來保證。
最後，其實每一種方案都有各自的優點與缺點，要結合自身業務的情況和系統的特性來選擇具體的方案，選擇性地犧牲某些方面以保證某些方面。
七、大資料平台架構
1、Lambda架構
1）、Lambda架構的主要思想是将大資料系統架構為多個層次，分别為批處理層（batchlayer）、實時處理層（speedlayer）、服務層（servinglayer），如下圖所示
2）、基于Lambda架構的大資料開發平台的架構設計：
下圖是一個基于實時處理和離線處理兩條線的資料采集和處理架構方案：
大資料開發平台一般主要解決大資料任務的送出，排程執行以及監控，大資料的任務類型一般很多，有資料采集任務、資料同步任務、實時計算任務、離線計算任務等。
未完待續，後續會繼續補充大資料相關的架構
作者的原創文章，轉載須注明出處。原創文章歸作者所有，歡迎轉載，但是保留版權。對于轉載了部落客的原創文章，不标注出處的，作者将依法追究版權，請尊重作者的成果。