怎么實作分布式事務？

1.什么是事務？

事務應該具有4個屬性：原子性、一致性、隔離性、持久性，這四個屬性通常稱為ACID特性，

原子性（atomicity），一個事務是一個不可分割的作業單位，事務中包括的操作要么都做，要么都不做，

一致性（consistency），事務必須是使資料庫從一個一致性狀態變到另一個一致性狀態，一致性與原子性是密切相關的，

隔離性（isolation），一個事務的執行不能被其他事務干擾，即一個事務內部的操作及使用的資料對并發的其他事務是隔離的，并發執行的各個事務之間不能互相干擾，

持久性（durability），持久性也稱永久性（permanence），指一個事務一旦提交，它對資料庫中資料的改變就應該是永久性的，接下來的其他操作或故障不應該對其有任何影響，

2.什么是分布式事務？

簡單的說，就是一個大操作，由很多小操作組成，而這些小操作又分布在不同的服務器上，分布式事務就是需要保證這些小操作要么全部成功，要么全部失敗，

3.在此之前要了解一下CAP定理，不會的人請轉到我另一篇文章

https://blog.csdn.net/weixin_49100429/article/details/119727069

4.分布式能否兼顧CAP？

在保證磁區容忍性的前提下一致性和可用性無法兼顧，如果要提高系統的可用性就要增加多個結點，如果要保證資料的一致性就要實作每個結點的資料一致，結點越多可用性越好，但是資料一致性越差，所以，在進行分布式系統設計時，同時滿足“一致性”、“可用性”和“磁區容忍性”三者是幾乎不可能的，

CAP有哪些組合方式？
1、CA：放棄磁區容忍性，加強一致性和可用性，關系資料庫按照CA進行設計，
2、AP：放棄一致性，加強可用性和磁區容忍性，追求最終一致性，很多NoSQL資料庫按照AP進行設計，說明：這里放棄一致性是指放棄強一致性，強一致性就是寫入成功立刻要查詢出最新資料，追求最終一致性是指允許暫時的資料不一致，只要最終在用戶接受的時間內資料 一致即可
3、CP：放棄可用性，加強一致性和磁區容忍性，一些強一致性要求的系統按CP進行設計，比如跨行轉賬，一次轉賬請求要等待雙方銀行系統都完成整個事務才算完成，? 說明：由于網路問題的存在CP系統可能會出現待等待超時，如果沒有處理超時問題則整理系統會出現阻塞

5.分布式事務的解決方案有以下幾種

2PC（二階段提交）

兩階段提交協議（2 Phase Commitment Protocol），兩階段提交由協調者和參與者組成，共經過兩個階段和三個操作，部分關系資料庫如Oracle、MySQL支持兩階段提交協議，簡單畫個圖

1）第一階段：準備階段（prepare）
協調者通知參與者準備提交，各參與者反饋事務執行結果，但參與者先不提交事務，
2）第二階段：提交(commit)/回滾(rollback)階段
協調者通知參與者開始提交，各參與者反饋事務提交結果，只要在這兩個階段中執行結果和提交結果有失敗回復，整個事務回滾
2PC的優點：實作強一致性，部分關系資料庫支持（Oracle、MySQL等），
缺點：整個事務的執行需要由協調者在多個節點之間去協調，增加了事務的執行時間，性能低下，

3PC（三階段提交）

與兩階段提交不同的是，三階段提交有兩個改動點，
1）引入超時機制，同時在協調者和參與者中都引入超時機制，

2）在第一階段和第二階段中插入一個準備階段，保證了在最后提交階段之前各參與節點的狀態是一致的，也就是說，除了引入超時機制之外，3PC把2PC的準備階段再次一分為二，這樣三階段提交就有CanCommit、PreCommit、DoCommit三個階段，

階段一：CanCommit
事務詢問 執行者向所有參與者發送CanCommit請求，等待所有參與者的回應
參與者反饋回應 參與者節點若認為自身可以完成事務，回傳Yes；反之，回傳No
階段二：PreCommit
若所有參與者反饋的結果都是Yes回應，那么進行事務預提交
若任意一個參與者反饋的結果是No回應，或者在等待超時之后，那么執行事務中斷
階段三：doCommit
該階段可能存在兩種情況，執行事務的提交和中斷事務
若執行者接受到所有參與的ACK回應，那么執行事務提交
如果有任意一個參與者反饋No回應，或者在等待超時之后，執行中斷事務

TCC(事務補償)

TCC事務補償是基于2PC實作的業務層事務控制方案，它是Try、Confirm和Cancel三個單詞的首字母，含義如下：
1、Try 檢查及預留業務資源完成提交事務前的檢查，并預留好資源，
2、Confirm確定執行業務操作對try階段預留的資源正式執行，
3、Cancel取消執行業務操作對try階段預留的資源釋放，

核心思想：

針對每個操作，都要注冊一個與其對應的確認和補償（撤銷）操作，分為三個階段

簡單來說

1.先來Try一下，不要把業務邏輯完成，先試試看，看各個服務能不能基本正常運轉，能不能先凍結我需要的資源，

2.如果Try都ok，也就是說，底層的資料庫、redis、elasticsearch、MQ都是可以寫入資料的，并且你保留好了需要使用的一些資源（比如凍結了一部分庫存），

3.接著，再執行各個服務的Confirm邏輯，基本上Confirm就可以很大概率保證一個分布式事務的完成了，

4.那如果Try階段某個服務就失敗了，比如說底層的資料庫掛了，或者redis掛了，等等，
此時就自動執行各個服務的Cancel邏輯，把之前的Try邏輯都回滾，所有服務都不要執行任何設計的業務邏輯，保證大家要么一起成功，要么一起失敗，

優點：最終保證資料的一致性，在業務層實作事務控制，靈活性好，

缺點：開發成本高，每個事務操作每個參與者都需要實作try/confirm/cancel三個介面，

什么是冪等性？

冪等性是指同一個操作無論請求多少次，其結果都相同，
冪等操作實作方式有：
1、操作之前在業務方法進行判斷如果執行過了就不再執行，
2、快取所有請求和處理的結果，已經處理的請求則直接回傳結果，
3、在資料庫表中加一個狀態欄位（未處理，已處理），資料操作時判斷未處理時再處理

訊息佇列實作最終一致性

訊息事務其實就是基于訊息中間件的兩階段提交，將本地事務和發訊息放在同一個事務里，保證本地操作和發送訊息同時成功

采用最終一致性原理，
需要保證以下三要素:
1、確認生產者一定要將資料投遞到MQ服務器中（采用MQ訊息確認機制）
2、MQ消費者訊息能夠正確消費訊息，采用手動ACK模式（注意重試冪等性問題）
3、如何保證第一個事務先執行，采用補償機制，在創建一個補單消費者進行監聽，如果訂
單沒有創建成功，進行補單，(如果第一個事務中出錯，補單消費者會在重新執行一次第一個
事務，例如第一個事務是添加訂單表，如果失敗在補單的時候重新生成訂單記錄，由于訂單號
唯一，所以不會重復)

經典案例，以目前流行點外賣的案例，用戶下單后，呼叫訂單服務，讓后訂單服務呼叫派單系
統通知送外賣人員送單，這時候訂單系統與派單系統采用MQ異步通訊，

MQ解決分布式事務一致性