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

分布式事物解決方案

分布式事物產生原因:主要產生與在微服務系統(tǒng)中，數(shù)據(jù)庫的垂直拆分或者是RPC遠程調用，

不在同一個數(shù)據(jù)源中，而是多個數(shù)據(jù)源中，每個數(shù)據(jù)源的事物都是本地事物，互不影響。

所以當A服務的數(shù)據(jù)源的事物發(fā)生回滾，不會影響到B服務的數(shù)據(jù)源回滾，從而產生分布式事物問題，無法保證分布式通訊數(shù)據(jù)一致性問題。

分布式事物基本理論:基本遵循CPA理論或者Base理論，采用柔性事物特征，軟狀態(tài)或者最終一致性特點保證分布式事物一致性問題。

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

1.2pc兩段提交協(xié)議

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

3.TCC或者GTS(阿里)

4.消息中間件最終一致性

5.傳統(tǒng)項目采用Jta(Java操作分布式事物XA接口)+atomikos 注意不適合于分布式常見、只適合多數(shù)據(jù)源情況下。

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

2PC

2PC，將事務的提交過程分為：準備階段和提交階段。事務的發(fā)起者稱協(xié)調者，事務的執(zhí)行者稱參與者。

　　階段1：準備階段

1、協(xié)調者向所有參與者發(fā)送事務內容，詢問是否可以提交事務，并等待所有參與者答復。

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

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

　　階段2：提交階段

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

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

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

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

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

2、參與者執(zhí)行Commit請求，并釋放整個事務期間占用的資源。

3、各參與者向協(xié)調者反饋Ack完成的消息。

4、協(xié)調者收到所有參與者反饋的Ack消息后，即完成事務提交。

中斷事務：（任何一個參與者反饋NO）
1、協(xié)調者向所有參與者發(fā)出回滾請求（即Rollback請求）。
2、參與者使用階段1中的Undo信息執(zhí)行回滾操作，并釋放整個事務期間占用的資源。
3、各參與者向協(xié)調者反饋Ack完成的消息。
4、協(xié)調者收到所有參與者反饋的Ack消息后，即完成事務中斷。

　　附如下示意圖：

2PC的缺陷

1、同步阻塞：最大的問題即同步阻塞，即：所有參與事務的邏輯均處于阻塞狀態(tài)。
2、單點：協(xié)調者存在單點問題，如果協(xié)調者出現(xiàn)故障，參與者將一直處于鎖定狀態(tài)。
3、腦裂：在階段2中，如果只有部分參與者接收并執(zhí)行了Commit請求，會導致節(jié)點數(shù)據(jù)不一致。
由于2PC存在如上同步阻塞、單點、腦裂問題，因此又出現(xiàn)了2PC的改進方案，即3PC。

3PC

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

　　階段1：CanCommit

1、協(xié)調者向參與者發(fā)出CanCommit請求，詢問是否可以提交事務，并等待所有參與者答復。

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

　　階段2：PreCommit

　　此階段分兩種情況：

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

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

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

1、協(xié)調者向所有參與者發(fā)出PreCommit請求，進入準備階段。

2、參與者收到PreCommit請求后，執(zhí)行事務操作，但不提交事務。

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

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

1、協(xié)調者向所有參與者發(fā)出abort請求。

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

　　階段3：do Commit

　　此階段也存在兩種情況：

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

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

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

1、如果協(xié)調者處于工作狀態(tài)，則向所有參與者發(fā)出do Commit請求。

2、參與者收到do Commit請求后，會正式執(zhí)行事務提交，并釋放整個事務期間占用的資源。

3、各參與者向協(xié)調者反饋Ack完成的消息。

4、協(xié)調者收到所有參與者反饋的Ack消息后，即完成事務提交。

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

1、如果協(xié)調者處于工作狀態(tài)，向所有參與者發(fā)出abort請求。

2、參與者使用階段1中的Undo信息執(zhí)行回滾操作，并釋放整個事務期間占用的資源。

3、各參與者向協(xié)調者反饋Ack完成的消息。

4、協(xié)調者收到所有參與者反饋的Ack消息后，即完成事務中斷。

　　注意：進入階段三后，無論協(xié)調者出現(xiàn)問題，或者協(xié)調者與參與者網(wǎng)絡出現(xiàn)問題，都會導致參與者無法接收到協(xié)調者發(fā)出的do Commit請求或abort請求。此時，參與者都會在等待超時之后，繼續(xù)執(zhí)行事務提交。

　　附示意圖如下：

3PC的優(yōu)點和缺陷

優(yōu)點：降低了阻塞范圍，引入了超時機制，在等待超時后協(xié)調者或參與者會中斷事務。

缺陷：腦裂問題依然存在，即在參與者收到PreCommit請求后等待最終指令，如果此時協(xié)調者無法與參與者正常通信，會導致參與者繼續(xù)提交事務，造成數(shù)據(jù)不一致。

?

分布式領域CAP理論

C(一致性), 數(shù)據(jù)一致更新，所有數(shù)據(jù)變動都是同步的

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

P(分區(qū)容忍性) 可靠性（遇到某節(jié)點或網(wǎng)絡分區(qū)故障時，仍然能夠對外提供滿足一致性和可用性的服務。）

定理：任何分布式系統(tǒng)只可同時滿足二點，沒法三者兼顧。

關系數(shù)據(jù)庫的ACID模型擁有 高一致性 + 可用性 很難進行分區(qū)：

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

Consistency一致性. 在事務開始或結束時，數(shù)據(jù)庫應該在一致狀態(tài)。

Isolation隔離層. 事務將假定只有它自己在操作數(shù)據(jù)庫，彼此不知曉。

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

跨數(shù)據(jù)庫兩段提交事務：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架構，因此傳統(tǒng)單機環(huán)境下數(shù)據(jù)庫的ACID事務滿足了分布式環(huán)境下的業(yè)務需要，以上幾種事務類似就是針對分布式環(huán)境下業(yè)務需要設定的。

軟狀態(tài)：狀態(tài)有一段時間可以不同步，異步的。

LCN分布式事務框架

框架介紹

LCN分布式事務框架其本身并不創(chuàng)建事務，而是基于對本地事務的協(xié)調從而達到事務一致性的效果。

核心步驟

創(chuàng)建事務組
是指在事務發(fā)起方開始執(zhí)行業(yè)務代碼之前先調用TxManager創(chuàng)建事務組對象，然后拿到事務標示GroupId的過程。

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

關閉事務組
是指在發(fā)起方執(zhí)行完業(yè)務代碼以后，將發(fā)起方執(zhí)行結果狀態(tài)通知給TxManager的動作。當執(zhí)行完關閉事務組的方法以后，TxManager將根據(jù)事務組信息來通知相應的參與模塊提交或回滾事務。

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

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

?

總結

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

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