轉載自??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分布式事務框架其本身并不創建事務，而是基于對本地事務的協調從而達到事務一致性的效果。

核心步驟

創建事務組
是指在事務發起方開始執行業務代碼之前先調用TxManager創建事務組對象，然后拿到事務標示GroupId的過程。

添加事務組
添加事務組是指參與方在執行完業務方法以后，將該模塊的事務信息添加通知給TxManager的操作。

關閉事務組
是指在發起方執行完業務代碼以后，將發起方執行結果狀態通知給TxManager的動作。當執行完關閉事務組的方法以后，TxManager將根據事務組信息來通知相應的參與模塊提交或回滾事務。

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

TxClient的代理連接池實現了javax.sql.DataSource接口，并重寫了close方法，事務模塊在提交關閉以后TxClient連接池將執行"假關閉"操作，等待TxManager協調完成事務以后在關閉連接。

?

總結

以上是生活随笔為你收集整理的分布式事物（2PC，3PC，CAP，柔性与刚性事物，LCN）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。