傳統意義上的事務被定義在數據層面，它是指一組原子操作，這組原子操作必須按照既定的順序全部執行成功 。 如果某一個或者多個原子操作失敗，則回退所有之前的原子操作到原來的狀態 。
事務的特點主要有四個：原子性（ Atomicity ）、 一致性（ Consistency ）、隔離性（ Isolation ）和持久性（ Durability ）。
一個標准的事務必須同時滿足這四個特性，否則就無法保持業務數據的正確性一一並且在 SQL 規范中也明確定義了這些特性的實現標准，例如它定義了四類事務隔離級別： Read Uncommitted （讀未提交〉、 Read Committed （讀己提交）、 Repeatable Read（可重復讀 ）和 Serializable （ 可串行化〉 。
傳統業務環境下這些原子數據操作都在同一個數據庫實例上完成 ， 而隨着企業中各系統的復雜度增加，就可能會出現事務跨兩個或者多個系統數據庫實例的情況 ， 后一種事務處理機制就是常說的分布式事務。
1.分布式事務與兩階段提交協議（2PC）--作用於系統數據層
兩階段提交協議（ 2PC ） 。 簡單來說這個協議中提到兩個階段是指准備階段和提交階段
它的實現一般需要一個事務協調者來統一所有工作，協調者首先向參與事務動作的各個數據節點提交准備請求（也叫檢查請求），並等待所有參與此事務的數據節點返回確認信息。當各個數據節點收到這個准備請求后就會檢查自己是否有條件執行自己負責的處理部分，並且執行但不提交各自負責的這部分數據操作。這是一個同步過程，在收到所有節點確認信息之前協調者都不會發出下一步的執行指令， 各個節點被鎖定／預占的資源也不會被釋放一一因為各數據節點的處理過程都未正式提交。如果在這個過程中任何一個數據節點返回了“不可用”或者等待超時，那么協調者就會向各個參與事務動作的處理節點發出“回液”指令，各個處理節點就會 回滾／釋放資源，並將回滾結果回饋給協調者 ；如果協調者收到所有處理節點“准備好”／“同意”的信號，那么就會進入第二個階段一一通知各個處理節點“提交” 。當各個處理節點收到第二步指令后，就會正式提交上一步已經完成的處理動作，並向協調者回饋“完成”消息 。
分布式事務己經有非常多的實現組件和成功案例，例如第三方組件:
> JOTM (Java Open Transaction Manager）就是一個成熟的分布式事務管理器，現在許多 Tomcat 服務器上都是用它提供的分布式事務功能：
> Atomikos 也是一款常用的分布式事務管理器，也是目前配合Spring 集成的一款分布式事務管理器 。
2.關系型數據庫的設計的 ACID 原理
即原子性（ Atomicity ）、 一致性（ Consistency ）、隔離性（ Isolation ）和持久性（ Durability ），而且關系型數據庫普遍采用事務技術實現 ACID原理，其中每一個事務就是最小的原子操作，還可以設置不同的事務級別，包括可讀未提交、可重復讀這樣的事務級別：關系型數據庫還規定了 一旦事務正確提交就不能進行數據回滾 ， 如果要繼續修改數據就只能啟動一個新的事務 。 而這一切都是為了保證數據庫系統是一個強一致性系統。 就連架設在各個關系型數據庫實例之上的分布式事務機制，也是為了保證這個 目標。
只要有任何一個參與分布式事務過程的數據庫實例出現異常，整個分布式事務就無法正常提交 ，當然也就無法完成數據寫操作 。 注意，數據是可以在事務操作的同時進行讀操作的，即使某些節點出現了 問題其他數據庫節點也可以承擔這個讀操作 ， 因為這樣的操作不存在一致性改變的風險。
3.TCC (Try Commit Cancel)--作用於系統RPC層
TCC 過程實際上是 2PC 的一種變形，它與后者的關鍵區別在於 TCC 的思路着重於原子服務而非具體數據操作。 Try步驟的細分工作又包括業務檢查和資源預占，而對於如何實現這個過程，在 TCC 中並沒有明確要求必須通過對持久層數據進行寫操作，這就便於架構師在服務層而非在數據層上設計 TCC 的實現。
4.CAP
分布式系統的知識體系中有一個非常重要的概念一一CAP 原理。這個原理指導着大多數分布式系統的設計過程 ，
CAP 原理大致是說分布式系統中一定存在三個特性 ： 一 致性( Consistency ）、分區容忍性（ Partition ）和可用性（ Availability ） 。
HBase選擇了C（一致性）與P（分區可容忍性），Cassandra選擇了A（可用性）與P（分區可容忍性），HDFS 選擇了P（分區可容忍性）與A（可用性）
分區性的要求：數據 X 至少也應該在不同的節點上存儲多份(至少應該有三份)，存儲的副本量越多越能保證數據 X 的安全，也越能保證即使在多個節點同時不可用的情況下，數據 X 也同樣能夠被訪問 。
一致性的要求：當客戶端發出數據 X 的更新請求后， 從任何一個節點訪問數據 X 都可以拿到它最新的狀態。如果真要達到這么理論的一致性要求，那就只能讓所有需要讀／寫數據 X的客戶端等待 ， 直到完成數據 X 的所有副本同步后，再依次進行響應 。 但這樣做又不滿足可用性要求。
可用性的要求：任何一個沒有發生故障的節點必須在有限的時間內返回結果。然而，如果系統能夠做到當某個節點發生網絡分區后，將它從系統中剔除，由其它節點繼續提供服務。雖然沒有滿足CAP中A的要求，但是，只要恢復時間足夠快，也符合高可用的要求。
5.BASE
BASE ，即 基本可用 （ Basically Availble ）、軟狀態（ Soft State ）和最終一致（ Eventual Consistency ） ， 任何分布式系統都不可能以 CAP 原理中三個特性同時作為設計目標，沒有任何分區容忍性的分布式系統甚至都不能稱為分布式系統。
一致性的概念：強一致性和最終一致性 。
強一致性可以概括為任何時刻客戶在分布式系統中獲取數據 X，無論它在分布式系統的哪個節點進行這個操作，其獲取到的數據 X 都是一致的 。 從這個定義來看 ，分布式事務機制就是一種強一致性的實現 。
弱一致性不是說不保持數據的一致性，而是說不保證數據每時每刻都一致，也不承諾什么 時候才能保證分布式系統的任何節點都能讀取到一致的數據。而最終一致性是弱一致性的一種特定結果， 即是承諾基於弱一致性，在經過一個數據不一致的時間窗口后，最終能保證數據一致 。 這個數據不一致的時間窗口在客戶端看來非常短，而且分布式系統還可以通過多種方式向客戶端屏蔽不一致的數據，例
如主從副本方式 。
BASE 的核心思路是在保證可用性和分區容忍性的前提下，找到一個犧牲一致性的程度，而最終一致性為我們指明了 這個程度一一保證數據最終一致即可。那么對於跨系統分布式業務我們也可以借鑒這個概念： 各個原子服務無須關心其他原子服務什么時候執行或者執行順序，只需要各自負責自己的那部分業務，並最終完成處理即可。如果出現需要回退的情況，則各個原子服務負責取消自己負責的那部分操作 ， 回到原始狀態 。
6.事務補償機制
這種機制本身並不提供事務，而是在需要進行回溶操作時能夠依據某種手段獲知整個執行路徑，並完成符合業務規則的逆向執行動作。為了保證事務補償機制能夠運行，業務系統提供了某個原子服務就必須提供一個和這個原子服務反向操作的另一個原子服務，這樣才可以保證事務補償機制在任何一個正 向執行的分布式業務工作的環境中，都有一個與之對應的反向執行過程。
當一個原子服務被執行時數據即時被更改，占用資源使用后即時被釋放，執行日志被詳細記錄。如果某一個原子服務執行失敗並不是將之前未提交數據回滾，而是通過一個對應的反向服務將之前的結果逆向執行，這里的逆向執行將重新修改數據 、 重新占用資源、重新生成新的日志。根據各個原子服務間的依賴性，這個執行過程既可以是順序執行的又可以是並行執行的。
事務補償機制可以通過多種方式進行實現:
1.獨立實現一個事務補償控制模塊，井向這個模塊注冊每一個正向方法和對應的逆向方法，跨系統業務由這個模塊負責執行井在出現執行錯誤的情況下進行重試或者逆向執行：
2.采用日志方式進行實現，將跨系統業務的發起方和各個執行方執行的每一步寫入日志，並在出現執行錯誤時利用日志記錄的信息分析和執行回滾策略，最后還要通過日志記錄整個業務是否達到了最終一致性。
應用場景：
事務補償機制可以解決長耗時業務過程中資源占用的問題，但是還是不能有效縮短業務執行時間 。因為在每個原子服務執行完成后資源就被釋放了，而不是像兩階段提交協議那樣在整個業務執行完成前都需要獨占資源。
事務補償機制雖然部分解決了分布式事務在業務系統的適用度問題，但是它本身也不是完美的。例如它不適用需要保證實時一致性的業務場景，
6.可靠的異步消息
可靠的異步消息系統是目前解決這類問題(電商訂單涉及多個子系統調用的問題)所常用的方式，
“可靠”的定義是消息系統不會無故丟失消息，保證消息送達到指定的目標系統：
“異步”是指消息的發送方（又稱生產方）在迭出消息后 ，無須等待消息接收方（又稱消費方）反饋任何結果即可執行后續的操作。
典型的可靠的異步消息系統有 ActiveMQ 、 RabbitMQ 和 RocketMQ。
7.為保持最終一致性的事務補償機制，或者又是可異步工作的可靠消息系統，在設計和使用時都需要注意問題
1）注意重試操作：由於分布式業務的各個執行步驟存在於不同的系統中，這些系統依靠網絡進行互相通信，所以在服務的調用過程中不可能保證 100%成功 。 也就是說即使每個原子服務工作正常，整個分布式業務的工作過程也可能因為某些工作環境原因而調用失敗，所以一旦某個原子服務調用失敗，協調者要做的事情並不是立即進行業務回滾、逆向操作或者異常消息通知，而應該首先進行重試操作，這是為了排除包括網絡抖動、主從服務切換在內的服務臨時不可用情況 。經過一定數量的重試后，如果服務還是不可用，則協調者再進行業務回液、逆向操作或者異常消息通知 。 以上示例代碼的客戶端並沒有任何的重試過程，就開始進行逆向操作了 。
2）注意冪等性：所謂冪等性是指參與同 一個分布式業務的各個操作步驟，無論執行多少次操作動作其結果都與執行一次操作動作后的結果一致。實際上這是對重試操作特性的一種支持，由於重試操作在異常情況下進行，所以誰也不能保證原子服務不會被錯誤地多次調用，甚至不能保證請求發起者不會錯誤地重復發起同一個分布式業務操作過程 。 例如，訂單生成時要避免重復生成的情況發生、訂單執行過程要防止出 現重復生成配送單的情況、訂單逆向執行的退款步驟要防止重復退款的情況發生。
3）注意基於日志：日志的作用可概括為事中記錄和事后回溯， 一個分布式服務過程的每一個執行步驟都應該詳細記錄日志，無論這個過程是正向執行還是逆向執行； 在分布式服務執行完成后也應該記錄日志，無論這個分布式服務執行是否成功 。這些日志可以在分布式業務執行結束后檢查最后的執行效果，在協調器出現窯機時利用日 志恢復協調器執行狀態保持執行過程的一致性，在需要進行逆向執行時也可利用日志找到對應的回溯路徑。以之前的示例代碼來說 ， Invoker 角色中的代碼雖然可以在某個原子服務出現異常時，按照分布式業務對應的逆向過程進行執行，但是卻沒有使用任何辦法保證逆向過程執行的可靠性一一沒有記錄日志 。 所以要是某個原子服務執行的逆向過程失敗，整個系統的數據一致性就沒有保證了。
4）參與分布式服務的各個原子服務，在沒有業務間依賴的情況下可以采用並行執行的方式縮短整個分布式服務的執行時間 ，提高執行效率。
8.Hystrix與熔斷機制
通過多種手段幫助技術人員解決系統間調用時的錯誤，防止系統雪崩效應。Hystrix 將分布式業務的正向操作和逆向操作分離開，並通過設置最長等待時間、拋出異常等方式讓逆向操作自動執行。
關鍵點
1）首先 Hystrix 的單次執行是以一個命令完成的，其內是一個完整的命令模式，其外向開發人員暴露的是一個命令元素（Command 角色，其實現為HystrixCommand<R> 類或 HystrixExecutable<R>接口）。
開發人員需要實現其中的 run（）方法與getFallback（）方法
2）Hystrix 將具體的任務（一個 Command 角色）放入線程池中執行，而且 Hystrix 中不但可以管理 一 個線程池，還可以為不同的 Command 設置不同的ThreadPoo!Key ， 讓它們工作在不同 的線程池中
3）Hystrix 對 Command 的執行分為三種方式，同步執行 execute()、異步執行 queue()和帶有觀察器的執行方式 observe()
9.系統間服務調用的問題
1）訪問權限問題： 在整個系統生態環境中，不是任何用戶都可以隨意訪問任意業務服務接口的 。 除了訪問接口的用戶組、用戶和密碼管理（或者是公私鑰文件），還需要限制用戶的訪問權限。
2）版本控制問題： 為了子系統能夠保證 24 小時連續提供服務，就需要標注服務接口的版本號，讓之前沒有完成升級的服務節點提供／訪問老版本的服務接口：己經完成升級的服務節點提供新版本的服務接口。
3）服務時效、次數控制問題： 各個子系統提供的服務本身也是具有時效性的。比如某一個服務 Y 只在每天早上 10 : 00～11 :00 才能提供訪問調用，且對於某個用戶來說每天只能調用 100 次。
4）性能措施問題： 系統服務接口能夠承受多大的 TPS 是衡量其性能的一個重要指標 。 但是在生產環境下，往往再高的系統接口都會遇到 TPS 瓶頸。在此種情況下，我們一般會准備備用手段對請求進行導流，
5）跨平台性問題： 在有歷史遺留情況的系統中，或者有多個技術背景不同的團隊同時進行研發的大中型業務系統中，這就要求遠程業務接口能夠支持多種語言客戶端的調用 。 目前對這類問題的解決方法無外乎幾種：
（1)一種是使用各開發語言都更容易理解和管理的基於網絡應用層協議的接口調用方式，例如 HTTP RESTful 形式的服務接口：
（2)一種是基於某種支持跨語言特性的RPC 組件提供接口支持，例如基於 Apache Thrift提供的服務接口 ：
（3)還有一種是代理裝置，通過這個代理裝置，將某種語言某種消息格式的調用轉換為另 一種語言另一種消息格式的調用，而 ESB 技術就類似於這樣一種代理裝置。
10.SOA架構
SOA ( Service-Oriented Architecture ） 中文全稱 “面向服務的架構” 。 SOA 主要圍繞多個 “服務”如何進行集成以達到某種服務目的進行討論 。
服務: 在業務系統中被發布出來供用戶使用，並能夠完成一個完整業務過程的功能。
服務着眼於完整的業務：服務的定義對象是業務系統中的完整業務功能。
服務的粒度雖然相對粗放，但卻是可控的：服務拆分的目標是保留重用度：務粒度的拆分完全依據業務系統中業務過程進行定義和分析
服務集成的目的是形成一個新的服務：對企業內部（或者企業間〉的業務服務進行集成，被集成的業務服務稱之為原子服務，集成的目 的是重用這些原子服務形成一個新的服務。
SOA 需保證屏蔽細節：從技術細節層面看，開發語言、外傳輸協議、消息格式都可以使用 SOA 進行集成與轉換；從業務細節層面看， 第三方系統只需要知道調用某一個服務就可以達到業務目的，至於提供服務的業務系統如何實現業務過程則無須關心。
SOA 讓各業務系統保持松散：通過屏蔽各業務系統技術細節和業務細節，兼容各業務系統的不同傳輸協議和不同消息格式，可以讓通過 SOA進行業務集成的，各個業務系統保持低禍合狀態。
11.ESB
SOA 架構模型是解決問題的綱領性思路，在這個規則下ESB ( Enterprise Service Bus ，企業服務總線〉是其一種具體辦法。
為了滿足 SOA 架構思想的設計要點，達到既定的工作目標， ESB 總錢技術至少需要幫助這些業務系統完成以下工作。
· 多種調用協議的兼容支撐和轉換
· 多種消息格式兼容支撐和轉換
· 服務監控管理（注冊、安全、版本、優先級）：首先業務系統提供的服務可能會以－定周期發生變化，ESB能夠保證在這樣的情況下集成服務依然可以工作；其次ESB 應該有一套完整的功能來保證服務集成的安全性和權限 。
· 服務集成和編排：服務編排的作用就是明確原子服務執行的先后順序、判斷原子服務執行的條件、確保集成后的新服務能夠按照業務設計者的要求正常工作 。
常見的 ESB 產品
1.IBM 提供了兩款純軟件的 ESB 產品 ： IBM WebSphere ESB 和 IBM WebSphere MessageBroker（WMB〉
2.Oracle Service Bus ( OSB ）是 Oracle 的付費產品，和 WMB 類似， OSB 也是全分布式的ESB 產品
3.普元 ESB 產品是國內比較有代表性的擁有自 主產權的 ESB 產品 。
4.Mule ESB 是服務提供商 MuleSoft的產品
5.Apache Camel 是 Apache 基金會下的一個頂級開源項目，它提供了一套消息路由規則、消息轉換引擎和服務編排等能力。 不過它並沒有現成的消息轉換組件
12.服務治理框架
ESB 企業總線的存在目的之一是滿足企業建設過程中新系統和遺留系統的集成問題，所以ESB 中的一個功能側重點就是協議轉換和信息轉發
服務治理框架並不進行原子服務的真實調用，而只記錄原子服務的調用地址、權限、熔斷方案、備用路徑等信息，井在各原子服務調用時監控實時壓力 。當D 系統需要調用外圍系統時，首先會請求服務治理框架拿到真實的調用路徑 ， 再自行進行調用。
降低了服務調用的跨平台能力、服務編排能力和對遺留系統的集成能力，但是顯著提高了各系統間的調用吞吐量以及各系統集成到服務治理框架上的難度，非常適合互聯網系統對於輕量化和快速部署的要求。
常見的服務治理框架軟件
1. 阿里 DUBBO
2. Spring Cloud（Config、Eureka、Hystrix、Zuul、Ribbon等）