轉載自  https://blog.csdn.net/lizhen1114/article/details/80110317

分散式事物解決方案

分散式事物產生原因:主要產生與在微服務系統中，資料庫的垂直拆分或者是RPC遠端呼叫，

不在同一個資料來源中，而是多個數據源中，每個資料來源的事物都是本地事物，互不影響。

所以當A服務的資料來源的事物發生回滾，不會影響到B服務的資料來源回滾，從而產生分散式事物問題，無法保證分散式通訊資料一致性問題。

分散式事物基本理論:基本遵循CPA理論或者Base理論，採用柔性事物特徵，軟狀態或者最終一致性特點保證分散式事物一致性問題。

分散式事物常見解決方案:

1.2pc兩段提交協議

2.3pc三段提交協議(彌補兩端提交協議缺點)

3.TCC或者GTS(阿里)

4.訊息中介軟體最終一致性

5.傳統專案採用Jta(Java操作分散式事物XA介面)+atomikos 注意不適合於分散式常見、只適合多資料來源情況下。

6.使用LCN解決分散式事物，理念“LCN並不生產事務,LCN只是本地事務的搬運工”。

2PC

2PC，將事務的提交過程分為：準備階段和提交階段。事務的發起者稱協調者，事務的執行者稱參與者。

　　階段1：準備階段

1、協調者向所有參與者傳送事務內容，詢問是否可以提交事務，並等待所有參與者答覆。

2、各參與者執行事務操作，但不提交事務。

3、如參與者執行成功，給協調者反饋YES，即可以提交；如執行失敗，給協調者反饋NO，即不可提交。

　　階段2：提交階段

　　此階段分兩種情況：所有參與者均反饋YES、或任何一個參與者反饋NO。

　　所有參與者均反饋YES時，即提交事務。

　　任何一個參與者反饋NO時，即中斷事務。

　　提交事務：（所有參與者均反饋YES）

1、協調者向所有參與者發出正式提交事務的請求（即Commit請求）。

2、參與者執行Commit請求，並釋放整個事務期間佔用的資源。

3、各參與者向協調者反饋Ack完成的訊息。

4、協調者收到所有參與者反饋的Ack訊息後，即完成事務提交。

中斷事務：（任何一個參與者反饋NO）
1、協調者向所有參與者發出回滾請求（即Rollback請求）。
2、參與者使用階段1中的Undo資訊執行回滾操作，並釋放整個事務期間佔用的資源。
3、各參與者向協調者反饋Ack完成的訊息。
4、協調者收到所有參與者反饋的Ack訊息後，即完成事務中斷。

　　附如下示意圖：

2PC的缺陷

1、同步阻塞：最大的問題即同步阻塞，即：所有參與事務的邏輯均處於阻塞狀態。
2、單點：協調者存在單點問題，如果協調者出現故障，參與者將一直處於鎖定狀態。
3、腦裂：在階段2中，如果只有部分參與者接收並執行了Commit請求，會導致節點資料不一致。
由於2PC存在如上同步阻塞、單點、腦裂問題，因此又出現了2PC的改進方案，即3PC。

3PC

3PC，三階段提交協議，是2PC的改進版本，即將事務的提交過程分為CanCommit、PreCommit、do Commit三個階段來進行處理。

　　階段1：CanCommit

1、協調者向參與者發出CanCommit請求，詢問是否可以提交事務，並等待所有參與者答覆。

2、參與者收到CanCommit請求後，如果認為可以執行事務操作，則反饋YES，否則反饋NO。

　　階段2：PreCommit

　　此階段分兩種情況：

1、所有參與者均反饋YES，即執行事務預提交。

2、任何一個參與者反饋NO，或者等待超時後協調者尚無法收到所有參與者的反饋，即中斷事務。

　　事務預提交：（所有參與者均反饋YES時）

1、協調者向所有參與者發出PreCommit請求，進入準備階段。

2、參與者收到PreCommit請求後，執行事務操作，但不提交事務。

3、各參與者向協調者反饋Ack響應或No響應，並等待最終指令。

　　中斷事務：（任何一個參與者反饋NO，或者等待超時後協調者尚無法收到所有參與者的反饋時）

1、協調者向所有參與者發出abort請求。

2、無論收到協調者發出的abort請求，或者在等待協調者請求過程中出現超時，參與者均會中斷事務。

　　階段3：do Commit

　　此階段也存在兩種情況：

1、所有參與者均反饋Ack響應，即執行真正的事務提交。

2、任何一個參與者反饋NO，或者等待超時後協調者尚無法收到所有參與者的反饋，即中斷事務。

　　提交事務：（所有參與者均反饋Ack響應時）

1、如果協調者處於工作狀態，則向所有參與者發出do Commit請求。

2、參與者收到do Commit請求後，會正式執行事務提交，並釋放整個事務期間佔用的資源。

3、各參與者向協調者反饋Ack完成的訊息。

4、協調者收到所有參與者反饋的Ack訊息後，即完成事務提交。

　　中斷事務：（任何一個參與者反饋NO，或者等待超時後協調者尚無法收到所有參與者的反饋時）

1、如果協調者處於工作狀態，向所有參與者發出abort請求。

2、參與者使用階段1中的Undo資訊執行回滾操作，並釋放整個事務期間佔用的資源。

3、各參與者向協調者反饋Ack完成的訊息。

4、協調者收到所有參與者反饋的Ack訊息後，即完成事務中斷。

　　注意：進入階段三後，無論協調者出現問題，或者協調者與參與者網路出現問題，都會導致參與者無法接收到協調者發出的do Commit請求或abort請求。此時，參與者都會在等待超時之後，繼續執行事務提交。

　　附示意圖如下：

3PC的優點和缺陷

優點：降低了阻塞範圍，引入了超時機制，在等待超時後協調者或參與者會中斷事務。

缺陷：腦裂問題依然存在，即在參與者收到PreCommit請求後等待最終指令，如果此時協調者無法與參與者正常通訊，會導致參與者繼續提交事務，造成資料不一致。

分散式領域CAP理論

C(一致性), 資料一致更新，所有資料變動都是同步的

A(可用性), 好的響應效能（指系統能夠很好的為使用者服務，訪問超時等使用者體驗不好的情況）

P(分割槽容忍性) 可靠性（遇到某節點或網路分割槽故障時，仍然能夠對外提供滿足一致性和可用性的服務。）

定理：任何分散式系統只可同時滿足二點，沒法三者兼顧。

關係資料庫的ACID模型擁有 高一致性 + 可用性 很難進行分割槽：

Atomicity原子性：一個事務中所有操作都必須全部完成，要麼全部不完成。

Consistency一致性. 在事務開始或結束時，資料庫應該在一致狀態。

Isolation隔離層. 事務將假定只有它自己在操作資料庫，彼此不知曉。

Durability. 一旦事務完成，就不能返回。

跨資料庫兩段提交事務：2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸縮模式的，JavaEE中的JTA事務可以支援2PC。因為2PC是反模式，儘量不要使用2PC，使用BASE來回避。

BASE模型反ACID模型，完全不同ACID模型，犧牲高一致性，獲得可用性或可靠性：

BASE思想主要強調基本的可用性，如果你需要High 可用性，也就是純粹的高效能，那麼就要以一致性或容忍性為犧牲，BASE思想的方案在效能上還是有潛力可挖的。、

柔性事務和剛性事務

柔性事務滿足BASE理論（基本可用，最終一致）
剛性事務滿足ACID理論

柔性事務分為兩階段型，補償型，非同步確保型。最大努力通知型幾種。

由於支付寶整個架構是SOA架構，因此傳統單機環境下資料庫的ACID事務滿足了分散式環境下的業務需要，以上幾種事務類似就是針對分散式環境下業務需要設定的。

軟狀態：狀態有一段時間可以不同步，非同步的。

LCN分散式事務框架

框架介紹

LCN分散式事務框架其本身並不建立事務，而是基於對本地事務的協調從而達到事務一致性的效果。

核心步驟

1. 建立事務組
   是指在事務發起方開始執行業務程式碼之前先呼叫TxManager建立事務組物件，然後拿到事務標示GroupId的過程。
2. 新增事務組
   新增事務組是指參與方在執行完業務方法以後，將該模組的事務資訊新增通知給TxManager的操作。
3. 關閉事務組
   是指在發起方執行完業務程式碼以後，將發起方執行結果狀態通知給TxManager的動作。當執行完關閉事務組的方法以後，TxManager將根據事務組資訊來通知相應的參與模組提交或回滾事務。

LCN事務控制原理是由事務模組TxClient下的代理連線池與TxManager的協調配合完成的事務協調控制。

TxClient的代理連線池實現了javax.sql.DataSource介面，並重寫了close方法，事務模組在提交關閉以後TxClient連線池將執行"假關閉"操作，等待TxManager協調完成事務以後在關閉連線。