本分佈式事務系列主要講分佈式事務從
理論-> 解決方案 -> 使用框架 -> 實現及原理 -> 案例實戰 -> 事務回滾（全局異常統一處理）->分佈式事務消息
該篇着重於講述分佈式事務的基礎理論。因爲它本身就是一個偏理論性的難題。
- 分佈式事務產生背景
- ACID酸鹼平衡理論
- CAP帽子原理
- 分佈式事務案例分析--支付接口
- Base理論
一、分佈式事務產生背景
在微服務環境下，因爲會根據不同的業務會拆分成不同的服務，比如酒店服務、訂單服務、會員服務等，讓專業的人做專業的事情，每個服務都有自己獨立的數據庫，並且是獨立運行，互不影響。
服務與服務之間通訊採用RPC遠程調用技術，但是每個服務中都有自己獨立的數據源，即自己獨立的本地事務。兩個服務相互通訊的時候，兩個本地事務互不影響，從而出現分佈式事務，這就是分佈式事務產生的原因。
通俗的講，兩個人A與B都提着不同的籃子，裏面裝着雞蛋。A裝雞蛋時籃子掉了打碎了雞蛋，是碎不了B的蛋的...
注意：傳統項目大部分情況下，不會產生分佈式事務，但是在項目中如果採用多數據源方式。就也會出現該問題。
分佈式事務產生背景原理圖：
這裏是一個很經典的案例(僞代碼)，下單扣庫存。訂單模塊增加一條數據，執行成功後調用庫存服務，庫存扣減方法執行完畢後無錯誤即進行數據提交，此時庫存減少。調用完成後訂單模塊報錯，那麼在事務機制下，訂單模塊操作的數據會被回滾，從而出現了訂單回滾，庫存扣減現象，這就是分佈式事務產生的一個案例。
那麼如何解決事務問題，在學術上有一些理論知識，這裏做個簡單闡述。
二、ACID酸鹼平衡理論
關係型數據庫的ACID原理，這裏對ACID做個簡單的介紹。至於全面的ACID原理，請參考ACID
關係型數據庫天生就是解決具有複雜事務場景的問題，完全滿足ACID的特性。
數據庫管理系統中事務(transaction)的四個特性（分析時根據首字母縮寫依次解釋）：
1.原子性（Atomicity） 原子性是指事務是一個不可再分割的工作單元，事務中的操作要麼都發生，要麼都不發生
2.一致性（Consistency）一致性是指在事務開始之前和事務結束以後，數據庫的完整性約束沒有被破壞。這是說數據庫事務不能破壞關係數據的完整性以及業務邏輯上的一致性
3.隔離性（Isolation）多個事務併發訪問時，事務之間是隔離的，一個事務不應該影響其它事務運行效果。
4.持久性（Durability）這是最好理解的一個特性：持久性，意味着在事務完成以後，該事務所對數據庫所作的更改便持久的保存在數據庫之中，並不會被回滾。（完成的事務是系統永久的部分，對系統的影響是永久性的，該修改即使出現致命的系統故障也將一直保持）
ACID屬於剛性事務。強一致性。
三、CAP（帽子原理）
由於對系統或者數據進行了拆分，系統不再是單機系統，而是分佈式系統，針對分佈式系統的CAP原理包含如下三個元素。
C: Consistency,一致性。在分佈式系統中的所有數據 備份，在同一時刻具有同樣的值，所有節點在同一時刻讀取的數據都是最新的數據副本。
A: Availability,可用性，好的響應性能。完全的可用性指的是在任何故障模型下，服務都會在有限的時間內處理完成並進行響應。
P: Partition tolerance,分區容忍性。儘管網絡上有部分消息丟失，但系統仍然可繼續工作。
CAP原理是這三個要素最多隻能同時實現兩點，不可能三者兼顧。因此在進行分佈式架構設計時，必須做出取捨。而對於分佈式數據系統，分區容忍性是基本要求，否則就失去了價值。因此設計分佈式數據系統，就是在一致性和可用性之間取一個平衡。對於大多數web應用，其實並不需要強一致性，因此犧牲一致性而換取高可用性，是目前多數分佈式數據庫產品的方向。
當然，犧牲一致性，並不是完全不管數據的一致性，否則數據是混亂的，那麼系統可用性再高分佈式再好也沒有了價值。犧牲一致性，只是不再要求關係型數據庫中的強一致性，而是隻要系統能達到最終一致性即可，考慮到客戶體驗，這個最終一致的時間窗口，要儘可能的對用戶透明，也就是需要保障“用戶感知到的一致性”。通常是通過數據的多份異步複製來實現系統的高可用和數據的最終一致性的，“用戶感知到的一致性”的時間窗口則取決於數據複製到一致狀態的時間。
所以一般操作分佈式事務是採用AP，即可用性，和分區容忍性。並通過消息最終一致性完成CAP。附上一張圖：
四、經典分佈式事務案例分析
支付案例特性：
1、可跨平臺語言 2、操作較爲麻煩 3、最基礎解決方案
如圖：通過回調接口通知來完成該事物，由於可以通過接口來控制，所以無論語言，數據最終通過JSON或XML進行解析即可。
但是操作會比較麻煩，做過支付相關的同學們應該就知道。所以支付案例其實就是一種類似於分佈式事務的一種場景。
對它有個大致的瞭解，並且對理論有掌握後，解決這個問題就可以根據場景、需求、經驗、實際情況等來選擇最合適的方法了。
五、Base理論
前面說到剛性事務，也就是關係型數據庫的特性。這裏講講柔性事務，Base理論。
BASE理論是指，Basically Available（基本可用）、Soft-state（ 軟狀態/柔性事務）、Eventual Consistency（最終一致性）。
是基於CAP定理演化而來，是對CAP中一致性和可用性權衡的結果。
核心思想：即使無法做到強一致性，但每個業務根據自身的特點，採用適當的方式來使系統達到最終一致性。
1、基本可用：指分佈式系統在出現故障的時候，允許損失部分可用性，保證核心可用。但不等價於不可用。比如：搜索引擎比如百度-0.5秒返回查詢結果，但由於故障，2秒響應查詢結果；網頁訪問過大時，部分用戶提供降級服務等。
2、軟狀態：軟狀態是指允許系統存在中間狀態，並且該中間狀態不會影響系統整體可用性。即允許系統在不同節點間副本同步的時候存在延時。
3、最終一致性：
系統中的所有數據副本經過一定時間後，最終能夠達到一致的狀態，不需要實時保證系統數據的強一致性。最終一致性是弱一致性的一種特殊情況。BASE理論面向的是大型高可用可擴展的分佈式系統，通過犧牲強一致性來獲得可用性。ACID是傳統數據庫常用的概念設計，追求強一致性模型。
總結：不論是哪種理論，都有它核心的思想，這裏做個簡述：
ACID：強一致性，不管性能消耗怎樣，就是要求數據必須實時一致，硬性要求。
CAP：強調於做取捨，分區容忍性是基本要求（分佈式），故可用性與一致性做取捨，通常是分區容忍性 + 可用性 最後通過最終一致性完成數據一致。
問題：看完CAP爲啥不能三者權衡都用，一定要取捨？ 百思不得其解。答曰：由此衍生Base理論。
Base：存在軟狀態與最終一致性概念，所謂最終一致性，就是在一定時間內同步達到一致，並不是實施達到一致性，沒有ACID那麼剛性。適用於對一致性要求沒那麼高的分佈式事務場景。但是不代表一定時間就很久，這個時間就是軟狀態，至於軟多久，根據業務需求而定。