分佈式事務及解決方案
1.相關概念：
1.1分佈式系統？
即部署在不同的節點（服務器）的通過網絡來完成交互的協同工作的系統
如：電商的訂單服務，下單—>減庫存，訂單和庫存服務不在同一個節點上。
1.2事務？
由一組操作組成的一個工作單元，這個工作單元具有原子性（atomicity）、一致性（consistency）、隔 離性（isolation）和持久性（durability）
- 原子性：執行單元中的操作要麼全部執行成功，要麼全部失敗。如果有一部分成功一部分失敗那麼成功的操作要全 部回滾到執行前的狀態
- 一致性：執行一次事務會使用數據從一個正確的狀態轉換到另一個正確的狀態，執行前後數據都是完整的，不存在中間狀態。
- 隔離性：在該事務執行的過程中，任何數據的改變只存在於該事務之中，對外界沒有影響，事務與事務之間是完全的隔離的。只有事務提交後其它事務纔可以查詢到最新的數據。
- 持久性：事務完成後對數據的改變會永久性的存儲起來，即使發生宕機數據依然存在。
1.3本地事務？
用關係數據庫來控制事務，關係數據庫通常都具有ACID特性，傳統的單體應用通常會將數據全部存儲 在一個數據庫中，會藉助關係數據庫來完成事務控制
1.4分佈式事務？
在分佈式系統中一次操作由多個系統協同完成，這種一次事務操作涉及多個系統通過網絡協同完成的過程稱爲分佈式事務
注意：分佈式事務強調的是多個系統在網絡協同下完成一個事務的過程，而不是此過程中訪問了幾個數據庫，是不是不同節點的數據庫。
如：訂單—庫存服務，在此過程中即使訂單和庫存的數據庫是同一個，但訂單和庫存服務分屬於不同的系統，也可稱爲分佈式事務。
2.CAP理論
CAP理論是：分佈式系統在設計時只能在一致性(Consistency)、可用性(Availability)、分區容忍性(Partition Tolerance)中滿足兩種，無法兼顧三種。
一致性(Consistency)：當不同的節點用來存儲相同的數據時，不同結點的數據需要保持同一時刻數據一致性。
可用性(Availability)：在由不同節點組成的集羣服務中，其中一個結點宕機不影響整個集羣對外提供服務。
分區容錯性(Partition Tolerance)：分區容錯性就是允許系統通過網絡協同工作，分區容錯性要解決由於網絡分區導致數據的不完整及無法訪問等問題
分佈式系統能否兼顧C、A、P？
在保證分區容錯的情況下，提高系統的可用性—>增加節點—>節點數量一多，系統的數據的一致性越難保持—>數據一致性越差
3.解決方案
3.1兩階段提交協議(2PC)
兩階段提交由 協調者和參與者組成，共經過兩個階段和三個操作，部分關係數據庫如Oracle、MySQL支持兩階段提交協議
2PC協議流程圖：
1.第一階段：準備階段（prepare）
協調者通知參與者準備提交訂單，參與者開始投票。
協調者完成準備工作向協調者回應Yes。
2.第二階段：提交(commit)/回滾(rollback)階段
協調者根據參與者的投票結果發起最終的提交指令。
如果有參與者沒有準備好則發起回滾指令。
以訂單—庫存爲例：
1、應用程序連接兩個數據源
2、應用程序通過事務協調器向兩個庫發起prepare，兩個數據庫收到消息分別執行本地事務（記錄日誌），但不提 交，如果執行成功則回覆yes，否則回覆no
3、事務協調器收到回覆，只要有一方回覆no則分別向參與者發起回滾事務，參與者開始回滾事務。
4、事務協調器收到回覆，全部回覆yes，此時向參與者發起提交事務。如果參與者有一方提交事務失敗則由事務協 調器發起回滾事務。
此方案優缺點：
優點：實現強一致性，部分關係數據庫支持
缺點：整個事務的執行需要由協調者在多個節點之間去協調，增加了事務的執行時間，性能低下
3.2事務補償（TCC）
TCC事務補償是基於2PC實現的業務層事務控制方案，它是Try、Confirm和Cancel三個單詞的首字母
- Try 檢查及預留業務資源 完成提交事務前的檢查，並預留好資源
- Confirm 確定執行業務操作 對try階段預留的資源正式執行
- Cancel 取消執行業務操作 對try階段預留的資源釋放
以訂單—庫存爲例：
1.Try
下單業務由訂單服務和庫存服務協同完成，在try階段訂單服務和庫存服務完成檢查和預留資源。 訂單服務檢查當前是否滿足提交訂單的條件（比如：當前存在未完成訂單的不允許提交新訂單）。 庫存服務檢查當前是否有充足的庫存，並鎖定資源。
2.Confirm
訂單服務和庫存服務成功完成Try後開始正式執行資源操作
訂單服務向訂單寫一條訂單信息
庫存服務減去庫存
3、Cancel
如果訂單服務和庫存服務有一方出現失敗則全部取消操作
訂單服務需要刪除新增的訂單信息
庫存服務將減去的庫存再還原
此方案優缺點：
優點：最終保證數據的一致性，在業務層實現事務控制，靈活性好。
缺點：開發成本高，每個事務操作每個參與者都需要實現try/confirm/cancel三個接口。
注意：TCC的try/confirm/cancel接口都要實現冪等性，在爲在try、confirm、cancel失敗後要不斷重試。
3.3消息隊列實現最終一致
以訂單—庫存爲例：
1、訂單服務和庫存服務完成檢查和預留資源
2、訂單服務在本地事務中完成添加訂單表記錄和添加“減少庫存任務消息”
3、由定時任務根據消息表的記錄發送給MQ通知庫存服務執行減庫存操作
4、庫存服務執行減少庫存，並且記錄執行消息狀態（爲避免重複執行消息，在執行減庫存之前查詢是否執行過此消息）
5、庫存服務向MQ發送完成減少庫存的消息
6、訂單服務接收到完成庫存減少的消息後刪除原來添加的“減少庫存任務消息”
此方案優缺點：
優點 ：
由MQ按異步的方式協調完成事務，性能較高
不用實現try/confirm/cancel接口，開發成本比TCC低
缺點：
此方式基於關係數據庫本地事務來實現，會出現頻繁讀寫數據庫記錄，浪費數據庫資源，另外對於高併發操作不是最佳方案