引入分散式事務：
在電商系統中，扣減庫存與儲存訂單是在兩個服務中存在的，如果扣減庫存後訂單儲存失敗了是不會回滾的，這樣就會造成資料不一致的情況，這其實就是我們所說的分散式事務的問題，接下來我們來學習分散式事務的解決方案。
-----本地事務與分散式事務介紹
一、事務
概念：資料庫事務(簡稱：事務，Transaction)是指資料庫執行過程中的一個邏輯單位，由一個有限的資料庫操作序列構成。
事務的四個特性，習慣上被稱為ACID特性：
原子性(Atomicity)：事務作為一個整體被執行，包含在其中的對資料庫的操作要麼全部被執行，要麼都不執行。
一致性(Consistency)：事務應確保資料庫的狀態從一個一致狀態轉變為另一個一致狀態。一致狀態是指資料庫中的資料應滿足完整性約束。除此之外，一致性還有另外一層語義，就是事務的中間狀態不能被觀察到(這層語義也有說應該屬於原子性)。
隔離性(Isolation)：多個事務併發執行時，一個事務的執行不應影響其他事務的執行，如同只有這一個操作在被資料庫所執行一樣。
永續性(Durability)：已被提交的事務對資料庫的修改應該永久儲存在資料庫中。在事務結束時，此操作將不可逆轉。
二、本地事務
起初，事務僅限於對單一資料庫資源的訪問控制,架構服務化以後，事務的概念延伸到了服務中。倘若將一個單一的服務操作作為一個事務，那麼整個服務操作只能涉及一個單一的資料庫資源,這類基於單個服務單一資料庫資源訪問的事務，被稱為本地事務(Local Transaction)。
三、分散式事務
分散式事務指事務的參與者、支援事務的伺服器、資源伺服器以及事務管理器分別位於不同的分散式系統的不同節點之上,且屬於不同的應用，分散式事務需要保證這些操作要麼全部成功，要麼全部失敗。本質上來說，分散式事務就是為了保證不同資料庫的資料一致性。
最早的分散式事務應用架構很簡單，不涉及服務間的訪問呼叫，僅僅是服務內操作涉及到對多個資料庫資源的訪問。
當一個服務操作訪問不同的資料庫資源，又希望對它們的訪問具有事務特性時，就需要採用分散式事務來協調所有的事務參與者。
對於上面介紹的分散式事務應用架構，儘管一個服務操作會訪問多個資料庫資源，但是畢竟整個事務還是控制在單一服務的內部。如果一個服務操作需要呼叫另外一個服務，這時的事務就需要跨越多個服務了。在這種情況下，起始於某個服務的事務在呼叫另外一個服務的時候，需要以某種機制流轉到另外一個服務，從而使被呼叫的服務訪問的資源也自動加入到該事務當中來。下圖反映了這樣一個跨越多個服務的分散式事務：
如果將上面這兩種場景(一個服務可以呼叫多個資料庫資源，也可以呼叫其他服務)結合在一起，對此進行延伸，整個分散式事務的參與者將會組成如下圖所示的樹形拓撲結構。在一個跨服務的分散式事務中，事務的發起者和提交均系同一個，它可以是整個呼叫的客戶端，也可以是客戶端最先呼叫的那個服務。
較之基於單一資料庫資源訪問的本地事務，分散式事務的應用架構更為複雜。在不同的分散式應用架構下，實現一個分散式事務要考慮的問題並不完全一樣，比如對多資源的協調、事務的跨服務傳播等，實現機制也是複雜多變。
四、分散式事務相關理論
CAP定理
CAP定理是在 1998年加州大學的電腦科學家 Eric Brewer （埃裡克.布魯爾）提出，分散式系統有三個指標
- Consistency 一致性
- Availability 可用性
- Partition tolerance 分割槽容錯性
它們的第一個字母分別是 C、A、P。Eric Brewer 說，這三個指標不可能同時做到。這個結論就叫做 CAP 定理。
3.分割槽容錯 Partition tolerance
大多數分散式系統都分佈在多個子網路。每個子網路就叫做一個區（partition）。分割槽容錯的意思是，區間通訊可能失敗。比如，一臺伺服器放在中國，另一臺伺服器放在美國，這就是兩個區，它們之間可能無法通訊。
上圖中，G1 和 G2 是兩臺跨區的伺服器。G1 向 G2 傳送一條訊息，G2 可能無法收到。系統設計的時候，必須考慮到這種情況。
一般來說，分割槽容錯無法避免，因此可以認為 CAP 的 P 總是成立。CAP 定理告訴我們，剩下的 C 和 A 無法同時做到。
2.可用性 Availability
Availability 中文叫做"可用性"，意思是隻要收到使用者的請求，伺服器就必須給出回應。
使用者可以選擇向 G1 或 G2 發起讀操作。不管是哪臺伺服器，只要收到請求，就必須告訴使用者，到底是 v0 還是 v1，否則就不滿足可用性。
1.一致性 Consistency
Consistency 中文叫做"一致性"。意思是，寫操作之後的讀操作，必須返回該值。
舉例來說，某條記錄是 v0，使用者向 G1 發起一個寫操作，將其改為 v1。
問題是，使用者有可能向 G2 發起讀操作，由於 G2 的值沒有發生變化，因此返回的是 v0。G1 和 G2 讀操作的結果不一致，這就不滿足一致性了。
為了讓 G2 也能變為 v1，就要在 G1 寫操作的時候，讓 G1 向 G2 傳送一條訊息，要求 G2 也改成 v1。
五、分散式事務當一致性和可用性的矛盾
一致性和可用性，為什麼不可能同時成立？答案很簡單，因為可能通訊失敗（即出現分割槽容錯）。
如果保證 G2 的一致性，那麼 G1 必須在寫操作時，鎖定 G2 的讀操作和寫操作。只有資料同步後，才能重新開放讀寫。鎖定期間，G2 不能讀寫，沒有可用性。
如果保證 G2 的可用性，那麼勢必不能鎖定 G2，所以一致性不成立。
綜上所述，G2 無法同時做到一致性和可用性。系統設計時只能選擇一個目標。如果追求一致性，那麼無法保證所有節點的可用性；如果追求所有節點的可用性，那就沒法做到一致性。
六、 引入分散式事務BASE理論
BASE：全稱：Basically Available(基本可用)，Soft state（軟狀態）,和 Eventually consistent（最終一致性）三個短語的縮寫，來自 ebay 的架構師提出。BASE 理論是對 CAP 中一致性和可用性權衡的結果，其來源於對大型網際網路分散式實踐的總結，是基於 CAP 定理逐步演化而來的。其核心思想是：
既是無法做到強一致性（Strong consistency），但每個應用都可以根據自身的業務特點，採用適當的方式來使系統達到最終一致性（Eventual consistency）。
1.Basically Available(基本可用)
什麼是基本可用呢？假設系統，出現了不可預知的故障，但還是能用，相比較正常的系統而言：
- 響應時間上的損失：正常情況下的搜尋引擎 0.5 秒即返回給使用者結果，而基本可用的搜尋引擎可以在 1 秒作用返回結果。
- 功能上的損失：在一個電商網站上，正常情況下，使用者可以順利完成每一筆訂單，但是到了大促期間，為了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面。
2.Soft state（軟狀態）
什麼是軟狀態呢？相對於原子性而言，要求多個節點的資料副本都是一致的，這是一種 “硬狀態”。
軟狀態指的是：允許系統中的資料存在中間狀態，並認為該狀態不影響系統的整體可用性，即允許系統在多個不同節點的資料副本存在資料延時。
3.Eventually consistent（最終一致性）
系統能夠保證在沒有其他新的更新操作的情況下，資料最終一定能夠達到一致的狀態，因此所有客戶端對系統的資料訪問最終都能夠獲取到最新的值。